Most of our Lotus Notes developers do not have XPages experiance. They are used to doing old style forms development.
We are designing a new Lotus Notes database application that is required to be used in disconnected (offline) mode.
Why would we use XPages in this application instead of using old forms based application? (Keep in mind the existing skill set, learning curve and disconnected feature requirements).
As David said there are many enhancements in Notes 8.5.3 which make the disconnected XPages experience much better. With the latest Upgrade Pack 1 you can even install a supported version of the extension library which allows very rich applications to be deployed. 8.5.3 UP1 works on non windows clients also.
Newbs
I really don't think there is any reason to consider using XPages for an application which will be used, even in part, off-line. Off-line support is just not there (8.5.1 and earlier, at least). And XPage applications are generally less coupled to the Notes client - meaning, you would have a harder time doing things like scripting replications, updating the notes.ini file, etc.
I do highly recommend use of XPages for any web-centric applications, as the development model id a vast improvement over Domino forms and pages. But for a disconnect app, I think you have a lot to lose and not much to gain.
Not sure this is still a relevant question based on timing, but as of Notes 8.5.1 XPages in The Notes Client was available. There are some quirks with it but it's much better in 8.5.3.
The big key really is... if the app is going to be local - use local data. Don't try to have a local app that hits server side data.
My 2 cents.
Your question has a number of discussion threads, but I'll try be as concise as possible. I am going to be presumptuous here and say, what you're really asking is "Should I try and do XPages for offline apps ?"
Currently, XPages offline capability is not supported, but there is some recent discussion and widgets leading in that direction that would indicate it is possible, however it is not a vendor supported solution.
Even if you could work offline, there is a learning curve and "keyboard mashing" exercise in working it out. If you're Notes client fleet is pre-release 8. I would recommend you stay with "old forms" development. I am not sure how much the Evolution Transformer by GBS would help you here. It's just been release after an extensive beta. This may take some short term pain out of the equation if constrained by time and money to deploy an offline Xpages application based on the discussion link above.
Each company that has invested in inhouse developed applications has a unique situation depending on business demands, budget, plain ol'tenaciousness etc. The Notes client is un-surpassed for economical application development effort for both connected and offline compatibility of apps. Weigh up your determining factors and the decision becomes easier to make.
The XPages learning curve in my guestimate is easily 3-6 months of re-tooling. It's faster if you have a mentor leading you through it.
Related
We are a small software Development company (<10) mainly in custom made Desktop Database applications. We have developed few Web Applications mainly used in VPN for centralized Query and reports with Flex 4.6, Spring, myBatis, Jasper Reports and Firebird. None of these is hosted on Publicly accessed web server but on VPN accessible cluster of 2/3 Load balanced Linux Tomcat servers.
Flex has been donated to Apache and Future development is geared towards (flaconJS) cross compilation to Java script, then a thought came forward "why not consider matured JS spitting Framework like GWT ?". We studied about GWT, GXT, smartGWT, vaadin, ZK. After reading many xxx vs yyy posts we have shortlisted GWT and GXT for our future data intensive web applications which may be hosted on Real world web servers. Considering our prospective client base we are considering to have GWT/similar for front end using REST calls to backend in either PHP or Spring/java depending on nature of project. We are also expecting requirements of Android Mobile applications augmenting already deployed projects.
Many of the POSTs which we have studied are from 2007 - 2012. Since then many things have changed so We feel that fresh opinions be sought before finalizing the decision. Our capabilities are, Java for 8 to 10 years, PHP never, HTML/CSS/JS never, Flex/spring/mybatis 8 to 10 years, RPC most of the time and REST for a recent project, Database applications in delphi > 15 yrs.
Clients Like Desktop Feel, very much fond of grids, modal popup data entry forms, tabbed views, menu navigation, expects use of ENTER even in Browser based forms, likes to preview reports before print/export etc. etc. We have shortlisted GWT/GXT based on these requirements, GXT demo application ticks most of the boxes. BTW we can afford to spend ample time for learning since we are planning for future development projects.
Please help us by sharing experience, suggestions, alternatives etc. etc. Your comments on this subject are valuable to us. We open to any other viable alternative so feel free to suggest it.
Thanks and warm regards.
Raja Patil
We have developed a small web application for a client. We decided on the Dojo framework to develop the app (requirements included were full i18n and a11y). Originally, the web app we developed was to be a "prototype", but we made the prototype production quality anyway, just in case. It turns out that the app we developed (or a variant of it) is going to production (many months hence), but it's so awesome that the enterprise architecture group is a little afraid.
508c compliant is a concern, as is security for this group. I now need to justify the use of Dojo to this architecture group, explicitly making the case that Dojo does not pose a security risk and that Dojo will not hurt accessibility (and that Dojo is there to help meet core requirements).
Note: the web app currently requires JavaScript to be turned on and a stylesheet to work. We use a relatively minor subset of Dojo: of course, dojo core, and dijit.form.Form, ValidationTextBox and a few others. We do use dojox.grid.DataGrid (but no drag N drop or editable cells, which are not fully a11y).
I have done some research of my own, of course, but I any information or advice you have would be most helpful.
Regards,
LES2
I'm not sure how to answer this question except to point out that you'd be in good company using Dojo. Several large corporations, deeply concerned about security issues have contributed to the toolkit and use it in their own products. Audits have been done on the toolkit, including one recently which did expose a problem which was quickly patched -- in fact, the CDN feature of Dojo, if you use it, means you can pick up patches like this automatically. Other than that, I'm not sure what proof to offer. A toolkit is secure until someone finds a security hole! Also, there are plenty of things you can do with Dojo, or the underlying HTML/JS technology, which are not secure. You need to follow best practices. One example is with JSON. There are a couple of methods to handle JSON. The base one is fast, works on older browsers, but is known not to be secure. It is meant to be used only with trusted data sources, and typically with the same domain policy, that's what you'll be doing. There are alternatives in dojox.secure which you might want to look at, depending on what you're doing, you may be able to provide an extra level of security to your application.
For performance, you can look at the various benchmarks like taskspeed, which focus largely on the dojo.query DOM traversal functionality common to most toolkits. Of course, YMMV depending on your usage of Dojo, but there's healthy competition between the toolkits and continuous improvement with each release.
For accessibility, all Dijit widgets were reviewed and considered to be 508c compliant. There is more precise documentation on Dojo/Dijit a11y requirements. Not all dojox widgets pass this requirement.
HTH
Let me introduce myself a bit.
I have 7 years of C++ (most MFC) experience, 1 year C#.NET and 2 years Java experience.
I know little about web application, what I did and am doing is Windows desktop applications.
I start to do some (minor) (freelance) side projects in the past half year and uses C# mostly as it's more "rapid" than MFC. But seems there's more web projects in this market than desktop projects. And I do not feel good as long as I do not know web development.
So, should I touch the new web filed for me or just stay focus in desktop application but learn more e.g Python, or Frameworks/Libraries such as Qt or Boost?
My gut feeling is that more and more people/companies are moving their projects to the web. My company, for example, has added numerous web applications since I have been there. Another prime example of this is Microsoft (yes, even them) providing a web-based version of Office, their flagship product.
There will always be a need for desktop applications, but I see more web-based projects in the future. It's always good to learn something new, anyway.
EDIT: Oh, and you don't lose anything by being aware of "desktop-based" processes. You may be doing more server-side programming, even if it is web-based. So, in other words, it doesn't hurt to continue expanding your knowledge in that arena, as well.
There will most likely still be a market for desktop applications for many years to come. However, web development seems to have taken over a large share of the development market from what I can see. I would recommend definitely getting familiar with web development as it definitely can't hurt to increase the number of skills you have even if you never stop writing desktop apps.
Since you have experience with C# you might want to consider doing some ASP.NET work. Or if you feel the need to learn a new technology then maybe consider a framework like Ruby on Rails.
I'd really suggest looking into web development - like you said, there are many more web application projects - and you already know C#.NET and Java, and both of those languages have really good API's / frameworks for web development. ASP.NET for C# and Java Servlets/JSPs.
I'd first suggest learning some really basic HTML to learn how pages are rendered, then try to make dynamic versions using the language of your choice. Then I'd learn some other web technologies like CSS/Javascript/some Javascript libraries - then I'd start looking at frameworks that build on top of the basics in the language of your choice.
Oh, and some further suggestions - there are web frameworks that are component-based rather than request-based - you may be tempted to learn these as a shortcut to web development since most claim that developing in them is similar to desktop development. I really wouldn't suggest this - as in practice you really do need to know how the web works at a lower level to develop custom components, include things that the framework doesn't do, or to debug them when things go wrong even when using these frameworks. If you jump right in you can get lost/confused pretty quickly.
Microsoft Office 2010 will have an online version. To me this is a watershed moment for Web applications. Office apps are an important litmus test as once you can do Office on the Web (which has been the case with Google Documents for some time but Office has important symbolic meaning) you can do most things that most users care about.
Desktop apps won't die but I definitely think they're going to take more and more of a backseat.
I'd highly suggest you read How Microsoft Lost the API War if you haven't already. One of the things that's particularly amazing about this post is that it was written in 2004.
I honestly believe that with maybe the exception of OSs and browsers, everything will be a web app within the next 10 years. Having said that, let me clarify that by everything I mean everything that a) involves a UI of some kind and b) can be guaranteed secure.
User-interfaced apps will always at some point need a backend, which will at some level require code that is not being interfaced by humans and not being executed via HTTP. I am always reminding myself that things like 'cat' in Unix are actually programs that the OS is calling, not just a function built into the OS. MySQL won't be a web app (as far as I know), but app that powers web apps. We may get to a point where these apps are fully developed via a web interface, written, audited, uploaded and called all via a browser, but at some level its still running behind the scenes.
On that second point, about guaranteed security, I can very easily imagine a large corporation or government office running 95 percent of their daily routines via web apps, but mandating that certain high-security operations be done on a machine directly interfaced with some sort of mainframe, after passing through the cool doors with the retinal scans and what not. Or simply because they can't risk moving certain mission-critical apps over to the web, from fear of it breaking our losing data in the process.
But with those two things aside, I honestly believe everything will be web-based. With the advancement of Web Services and XML in general, it will be possible to not only access and interact with our data, but to plug our custom apps into another app and extend that interaction further and in any environment we want.
It's like that Apple ad "There's an app for that." Except once people get the real picture, it won't be an app written for your iPhone, but a URL. "There's a site for that."
I recommend learning the Lift framework. It's as easy to use as Rails, and it's based on a statically-typed language for the JVM, Scala. From the perspective of your background, Scala should be middling to easy to learn, and you'll be more likely to be comfortable with it than with a dynamic language.
In my opinion, you have a good chance of picking it up quickly, learn a lot about good practices in web development, and even expanding your programming horizons a bit.
What open source toolkit does fatwire compare to and are there some particular advantages to fatwire?
How hard is fatwire to export out of and move to a free alternative?
How stable is it as a platform to write java extensions on?
From a development persepective, FatWire can be unfriendly. Having worked on a number of sites using this application it can easy bloat, and become difficult to maintain.
From a user perspective there has been alot of effort in the UI and this has led to a highly functional tool.
From a client perspective all clients bar 1 (a large news agency) were happy with the end result. FatWire can slow when using complex logic to generate menus or breadcumbs for example or when you have a large amount of content. This is the main reason the one client was unhappy. The FatWire site regularily struggled under the load. It sometimes seen as a solution to all web needs.
As such FatWire succeeds in serving Static Content & Semi Dynamic content, but can flounder when forced to do fully dynamic sites (from my experience).
From the original press release:
FatWire Software announced the rollout
of FirstSite, which is a set of tools
and best practices that helps
companies using FatWire Content Server
get their first Web site or
application running quickly while
providing a foundation for future
expansion. FirstSite includes a
collection of standard templates and
site components that are common to
most sites, combined with
documentation, training, a rich
developer community, and best
practices methodology. FatWire and its
solution partners are using FirstSite
as the basis for developing
content-centric applications for
specific vertical markets. With only
minor, cosmetic alterations,
developers can use the code in
FirstSite to implement a first site,
while simultaneously learning how to
utilize Content Server's capabilities,
such as dynamic content delivery,
personalization, caching, and product
catalogs.
Firstsite is not a product, unless this has changed since 2004 (unfortunately I cannot look, since their developer site is down). Fatwire's Content Server does not compare to any Open Source CMS that I know. It's scope goes much further. I will answer your questions one by one:
Advantages - There are many (or nobody would buy it, and it is not cheap)
On the delivery side: scalability, fine-grained cache control, stateless servlet architecture, ....
On the back office side: virtually no limit to asset types, dynamic content attributes, find-grained security and access control, ...
On the development side: Intelligently architected API with good coding productivity, tag library, ...
Openness
You cannot easily expect to migrate content between any two CMS products, open source or not. While there are ways to extract contant from the database in XML and other forms, using product tools, or simply at the database level, I don't think that this can be an argument for or against using a particular CMS. Ever tried to migrate from Drupal to Joomla?
Stable
I worked on several Fatwire implementations from 2000 to 2004 (back then it was OpenMarket Content Server, then Divine Content Server). It was stable enough for the Washington Post, the New York Times, and the S&P sites, and I would expect stability not to be an issue today.
Fatwire is really unique concept from developer point of view. It builds everything on a very abstract, extremely flexible clever asset modeling framework which is stored in relational database.
Application logic is based on "templates" which actually are pieces of JSP code. This JSP code is not like conventional Java, but tags instead. It takes very long from a developer to learn these tags and Fatwire asset api. Expect even months before skilled develpers start to be productive.
Almost nothing useable samples ships along the product. There is advertized "FirstSite" but it is way too simple for the purpose this product is used normally (huge complex sites). So pretty much everything has to be built from scratch.
Cache control is advertized to be one powerful feature. Yes it is, but we had extremely long learning curve and it never worked exactly like one assumed.
Wysiwyg editing has been missed from this product even it is advertized. At least during 2009 it had serious conceptual problems which practically prevented using it in live environments. But it was cool feature for demos and marketing of course. Today it might be fixed.
As a summary and if I were a customer with limited budget, I'd select any open source alternative instead. Mostly because development costs with Fatwire are high due the uniqueness of the product, lack of good documentation and extremely long learing curve. Of course the product price tag is also thing to consider.
And to answer to questions: you have to start from scratch if you move from Fatwire 6.0 to any open source alternative. And it is stable to build Java extensions on.
Fatwire stores content in relation database and file system. Depending on what type of content (structured/unstructured), Fatwire can be evaluated.
I've been developing web apps for over a decade now, all the way from CGI to ASP.Net and Struts+Spring+Hibernate. The prevalent architectural style seems to be server-assisted MVC, e.g. Struts, Ruby on Rails, etc. Recent developments lead me to ask if these are on the decline.
Adobe's AIR and Flex
Microsoft's WPF and Silverlight
Google's Chrome and Gears
SOFEA and SOUI
All of this leads me to believe that we're starting to come full-circle after a 15-year distraction kicked-off by the invention of the web. Over this period of time, we've been so fascinated by all the web has to offer that we didn't notice that the usability (and the developer experience) of web apps pretty much sucked in comparison to desktop apps. It seems we're now saying "Screw this! We love the web's benefits but we also want better usability, offline capabilities, and better integration with the desktop!".
All of the above mentioned developments seem to be moving us in this direction of putting the presentation logic back where it used to be: the client. Don't get me wrong, I don't think server-assisted MVC frameworks are going away anytime soon, but I do think they are on the decline and RIAs and RDAs are on the rise.
So, what do you think? Are server-assisted MVC frameworks near their peak?
I agree, to a point - we are becoming are more client-centric, but I think this is because the clients are actually advancing in a standardized way.
We started out with everything on the client - because thats all there was. Then it was client-server, which separated the two, then gradually the client bit was thinned out and pushed back to the server, for one reason:
clients sucked (win95, macos<10, unix X11), and deployment was a nightmare. Deploying a browser was trivial.
Thats changing tho. Air is an easy install, as is .NET 3.5. Air apps are easy to deploy (click here - say yes!) as is a WPF Click-once app. The network is now a defacto part of the environment, not something special that had to be added. A database is something you can embed into a silverlight app (SQL Server Compact Edition), or an iphone (SqLite), not something you have to have a big server for.
and everything has auto-updating, which makes the post-install story a lot better.
I dont think they are on the decline - I think the logic has just been pushed out again, and it'll be pulled back in the future, only to be pushed back out etc.
Silverlight/Air/Flash etc are all very powerful, but HTML + Javascript, which is the basis of the server MVC frameworks, has come forward massively, esp if you ignore the b'stard that is IE6.
Regardless, I'll still be writing the backend for RIA's in a server-assisted MVC framework, even if they are throwing out JSON, not HTML. So while they are no longer the be-all, they are far from dead (or peaking)
Lets clarify something!
MVC is only a design pattern for the seperation of concerns. There is no really relation to server side frameworks.
There is no technical Web 1.0 or Web 2.0 ... JavaScript and Flash were there for years. It's only about social networking, tagging etc.
The server side frameworks are not dead at all. I agree with Nic Wise in case of the bad client architectures/rendering. Can you print a HTML page (every time in the same way)? No, you can't, because every browser(-engine) has it's own representation your HTML description. Only because JavaScript/Flash... are restrictions for a lot of people/companies, the server side processing will stay there for a long time.
Developing "Run anywhere" JavaScript has been a burden for a long time! Nowadays we have Frameworks like JQuery which do this job for you. I've written my own homepage in JavaScript, using EJS (Embedded JavaScript) for the templates/mvc. The old bloated JSP/PHP pages have shown, that differing the business logic from the design is a really good thing.
A bad problem of every web application is to decide, where you save the state of the application! If you choose a bad way, you are not able to scale. Client centric frameworks with service oriented backends allow you to scale very good.
I have been working a little bit with SOFEA/SOUI. If you have an ready framework stack for the most common problems, you'll love it.
Air and Flex are nice, but they bring in a lot of restrictions (Flash/JS...).
Google's Chrome and Gears need you to install Google software at your computer. Who has Gears around here? Gears hasn't established as a wide distributed standard.
If you have experience with Hibernate/Spring and Struts, you sould try Grails! It is nice to develop GWT/FLEX&AIR/SOFEA&SOUI backends and also for the good old server side HTML rendering.
I like SOFEA/SOUI because it isn't such invasive, it offers an investment protection (SOA services) and high rate of reusability. It's also a nice way to move the load from your server to the clients.