Thank you for your reply Jeorn. I really like xForms...I hear your point about the client being an issue for a non-server side solution.
Is just the though of all that untapped client processing power sitting almost unused that keeps me thinking. I proposed a client side xForms soluton to a customer but he balked when he heard that it would need a special plugin in the browser (IE6). If IE were to offer a version with xForm support, then I do think it may be he way to go - client side xForm processing... and yes...some of the products I have worked on have required to be able to run in off-line mode so that busy" executives can work while they are flying in a plane. Once again, thank you for your useful reply thx Paul --- Joern Turner <[EMAIL PROTECTED]> wrote: > Hello Paul, > > Paul Joseph <pjoseph_98 <at> yahoo.com> writes: > > > > > maybe a dumb question...but isn't a significant > piece > > of XForm capability (Ex. the ability to work > off-line) > > lost with a Server side XForm implementation...? > you're right - not all features might be available > in a *pure* server-side > implementation but over 90% of the spec will still > be available. > > furthermore how many apps have you seen (especially > in the web-app world) > that really need offline capabilities? > > what i'd like to point out is this: is always > depends on your concrete > requirements in a specific project how you will > answer the question if > XForms is the right answer. XForms itself is defined > independent of > any concrete device(which is its strength). > naturally there will always be > clients that do not support the full feature set - > just think of a > pda or smart phone or even a voice application > (would this make sense > to work offline?). > > besides offline capability is not required by the > spec and not > even mentioned there. > > Chiba (Chicoon) has a different approach; as > server-side transcoding > engine it allows you to generate the code > appropriate for any type > of client. in our proof-of-concept implementation > this happens > to be a dump (script-less) browser and this is > surely constrained > in some aspects. nevertheless you have the option to > generate the > code that accomplishes all these features. in fact > we have > another subproject that implements a full-featured > client-side > XForms engine. it comes as an applet and runs in IE6 > currently. > generally it's also workable in e.g. Firefox. > > let me mention another thing. the fact that one or > the other feature > may not work with a specific implementation or > architecture was often > been used as an argument against XForms. this is > IMHO this a > statement of ignorance; consider the current world > of form-processing > which couldn't be worse. there are no standards, > there's repeating > effort in writing scripting code to do even the > easiest validations > (not to speak of dependency handling). > > XForms is a big step forward. it eliminates the need > for writing > script code and builds on a clearly defined markup > and processing > model. its feature-richness is not even found in > proprietary form > frameworks and in our work we made the experience > that it's extremly > extensible and adaptable for the widest range of > applications. > > please allow a last remark: Chiba (Chicoon) is a > server-side > reference implementation (just to proove its > possible ;) - the actual > processor sitting inside the webapp is independent > of its environment and also > can be used in any other java environment (also > client-side or even distributed). > > sorry if this answer was longer than you expected... > > > > Could Cocoon serve out the XForm XML(?) to the > browser > > which is equipped with a XForm plugin? > sure, any simple httpd demon will do for that. - as > long as you find a > fully-featured client (well, there are some but > these are not open source or > free). - and your application has to define this > client as standard for your > users - not always an option, especially in internet > apps. > > best, > > Joern > > > > > thx > > Paul > > --- Joern Turner <joern.turner <at> web.de> wrote: > > > > > Hello again, > > > > > > for those interested in W3C XForms there's an > online > > > demo of Chicoon under > > > http://81.169.173.189:8080/cocoon/chicoon/index > > > > > > running the Chiba XForms processor in an Cocoon > > > installation. > > > > > > Comments welcome, > > > > > > Joern Turner > > > -Chiba Project Admin- > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > users-unsubscribe <at> cocoon.apache.org > > > For additional commands, e-mail: > > > users-help <at> cocoon.apache.org > > > > > > > > > > ===== > > This communication, including attachments, is for > the exclusive use of > > the addressee and may contain proprietary, > confidential, or privileged > > information. If you are not the intended > recipient, any use, copying, > > disclosure, dissemination, or distribution is > strictly prohibited. If > > you are not the intended recipient, please notify > the sender by return mail > and delete this communication > > and destroy all copies. > > > > > > document.domain = 'gmane.org'; > > document.title = 'Re: Chicoon XForms online demo'; > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > ===== This communication, including attachments, is for the exclusive use of the addressee and may contain proprietary, confidential, or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination, or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender by return mail and delete this communication and destroy all copies. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
