RE: AJAX vs. Xforms

> Kidding aside, the debates between client-side to server-side XForms
> processing models is for the most part perhaps a tad destructive from an
> outsider looking in, deciding whether or not to use XForms. If I wasn't
> already bought in, I would have serious doubts betting my ROI on using
> this technology from what is being said within the XForms forum itself
> ... I've said this before and I'm bringing it up again.
> 
> We need to pull together ... Raman makes some very adhesive points about
> XForms processing models. I believe it would behoove everyone if we
> derived usage scenarios with respect to processing models, much like
> what SOAP did. I am a true believer there is not one cure for all.
> 
> We are system architects, which means accessing the requirements to a
> particular problem and choosing the appropriate solution to maximize ROI
> ... In many simple cases it may not involve XForms at all.
> 
> Below are a couple clarifications to comments passed through my email:
> 
> 1. To say client-side XForms processing is broken because email
> addresses are exchanged in the open - I say to the system architect,
> decide what you want to keep behind the firewall and implement it.
> 
> 2. To say server-side XForms processing is broken because it requires to
> many round trips - I say to the system architect, determine the number
> of round trips required and make a system trade-off.
> 
> 3. To say server-side XForms processing is required to increment across
> large datasets on the server is not accurate - Client side processors
> can do this as well.
> 
> 4. ... And there are many more ...
> 
> XForms and resulting XForms processor solutions are additional tools for
> system architects to choose from based on their specific requirements.
> Much of the debate going on I believe is either context based which
> varies significantly or from the purist view point that if it can't
> solve everything it has no value.
> 
> I suggest we derive usage scenarios to help guide the online form
> industry looking at us leading this effort. This will present a
> constructive approach to what fits where. For example, FormsPlayer(sorry
> Mark) is an easy target because plug-ins are easy to talk negative
> about. But in reality, there are many markets in which this would be
> okay because many companies and business partners use uSoft-only
> solutions.
> 
> So one, I would like to here if defining usage scenarios is a good idea
> or not. And two, if it is a good idea, how do we move forward.
> 
> Very respectfully,
> Gary  
>  

I agree,
	I'm only raising these issues in order that they remain in peoples minds, so that perhaps good consistent 
resolutions will come about.
I think its fascinating that Mark has achieved dynamic recursive controls despite the w3c's best efforts to make them 
impossible with Xforms
 ;-). I had to resort to XSL and still couldn't dynamically alter the UI of a running form.

>"The examples combine XHTML, XForms, SVG and XBL to produce controls
>recursively"

I like Xforms, and have committed to using them for serious commercial use. I think they could become something 
that should at least be considered for any project over the alternatives, and hopefully should result in a cleaner, faster, 
more reliable, more transportable implementation and result than other available technologies can offer.
Using AJAX with a severside implementation could give a pretty reasonable solution to the serverside/clientside issue 
(except that AJAX seems problematic with ie pre v6 and other older browser tech) , doing stuff that improves the UI 
experience and anything it can without giving up valuable secrets clientside, and restricting serverside activity to that 
which requires secrets or one way processing (submission of payment or something - you wouldn't want multiple 
submissions to be a possibility for a given invoice etc and keeping track serverside is probably easier than clientside)

anyway - Its good to see some activity on this list - its been pretty slow for a while prior to this thread.


anyway -

Received on Tuesday, 8 November 2005 08:11:14 UTC