From: Joern T. <joe...@go...> - 2010-03-30 21:10:53
|
Sorry - hit the send button by chance... On Tue, Mar 30, 2010 at 10:55 PM, Joern Turner <joe...@go...> wrote: > Andrzej, > > as this is not a XForms list i apologize in advance if going a bit off-topic. > > On Tue, Mar 30, 2010 at 8:19 PM, Andrzej Jan Taramina > <an...@ch...> wrote: >> Figured I would chime in with some observations about XForms, since I've been using it for onwards of 5-6 years now and >> we've done some pretty complex XForms for our healthcare app. >> >> I did some extremely extensive XForms work using Cocoon/Chiba/Chicoon (the whole ServletFilter idea has been around for >> a LONG time guys!), back 5+ years ago, for a pretty fancy document production applications for Charles Schwab. >> >> Recently, in our healthcare app, we've used Orbeon's XForms engine, running in parallel with eXist in the same Tomcat >> container. This allowed us to use an external URL filter to pass stuff back and forth easily between the two >> webapps....the XHTML XForms are all stored in eXist, and when sourced, are dynamically customized using an XQuery and >> then passed to Orbeon for processing. Bit of a complex environment, but works well enough. These XForms are very big >> and very complex, providing complete user and role administration UIs. >> >> So, like I said, I've had some experience with XForms. > Yes, i know and remember ;) > >> >> To sum it up, I'm not a big fan of XForms at the moment. To do any kind of a real-world complex UI becomes horribly >> complex with XForms, and becomes a massive maintenance and debugging nightmare, in our experience. If you want nice >> UI's, then you typically need more control than what your XForm engine of choice will give you. > I understand your concerns very well. > >>>>Warning - off-topic ahead<<< > But ... ;) and of course i am biased as a long-term XForms enthusiast > and implementer (end of warning) > > XForms is meant as am embedded language for handling forms namely it's > good at validations, calculations, managing dependencies between > *data* items (not parts of UI) and to a certain extend logic that is > associated with data. It's also good at handling repeating sections of > data and other form-related tasks. It is a misunderstanding to think about XForms as being a universal language for building UIs. I confess that this is a lesson that has to be learned over years of heavy use and some of the rather frustrating experiences you describe. betterFORM therefore tries not to be just XForms - it's also Dojo. Which offers a lot of the flexibility you want when handling UI logic - and to underline that again that allows you to separate the UI logic from the data logic. I fully agree that it is not healthy to mix both heavily in XForms itself. That really leads to bad maintainability especially if hand-author your forms. > > > >> >> So in the medium term, we plan to replace our admin xforms with pure XQuery apps that generate HTML and AJAX code, both >> of which will be stored in eXist. We've found that this gives us more control over the UI, better user experience, more >> flexibility and WAY more productivity in both the initial build of an app and even more so with ongoing maintenance. It >> also reduces the complexity of the deployment environment substantially, but sticking to the core functionality within >> eXist, not requiring fancy extensions or other server-side webapps. >> >> Due to the complexity and maintainability issues of generating complex UIs and forms, I don't believe that XForms will >> ever become a mainstream technology. It's just too awkward to use. Again i agree to a certain extend and in some areas it's plain ugly. But the standard is actively worked on and the WG is very active to improve things and push limits. What would you say if it looks plain like this instead of having all these scattered markup? <input readonly="string-length(foo)>3" required="true()" calculate="foo + bar" /> That's not a distand vision - we have used this approach in a reasonably large project with big success. Much easier to read and maintain and much easier to re-use pieces of markup. But anyway one big strength of XForms lies in the fact that it's easy to generate - from XML Schema but also from any other data structure description. If you have large quantities of screens it's a real live saver. >> >> So my opinion is that we should move all XForms stuff into external extensions, and get it out of the core eXist SVN >> repository. Same goes for XProc. That would simplify the core greatly....yet still provide pluggable functionality for >> those that want to use these "sideline" XML technologies. Agree - certainly it makes no sense to pack each and every technology into a product. Never been a fan of this. At the same time it should be easy to access these extensions if you like or need them. Joern >> >> My 2 cents worth having done some very complex stuff with XForms for quite a few years. >> >> -- >> Andrzej Taramina >> Chaeron Corporation: Enterprise System Solutions >> http://www.chaeron.com >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Exist-open mailing list >> Exi...@li... >> https://lists.sourceforge.net/lists/listinfo/exist-open >> > |