Ugo Cei wrote:
Oleg Dulin wrote:
Now, I understand it is difficult to come up with a way to define a scripted flow of web pages w/o actually writing some sort of a script. Can this be XML ? Does Cocoon Forms support using XML for flow script instead of JavaScript ?
I sincerely hope it never does. XML isn't worth "a pile of fetid dingo kidney" (TM) as a scripting language ;-).
Yes, easy solution with minimal code such that someone with XMLSpy can configure and minimal developer involvement is needed.
Do you really think that any moron can script logic in XML using XMLSpy? Why not in Javascript, then?
Anyway, if "RequestGenerator, FormValidatorAction, XSLT, XSLT extensions in Java and very very very minimal XSP actions" satisfy your needs, just use them. Nobody is taking them away from you. But if you want to stay on top of the current trends, as Bertrand said, then Cocoon Forms (Woody) is the way to go.
As far as W3C XForms is concerned, as Stefano said at the GetTogether (paraphrasing): we are fond of standards, but we are not afraid to invent our own when the existing ones do not fit. Many of us don't think XForms is a good standard for server-side form processing. Besides, can you really find lots of developers familiar with it? Will you be able in the future? Learning the Woody markup can be done in a few hours, so it's not that big deal, isn't it?
i think there already have been lots of discussions on this topic but could you nevertheless summarize why XForms is not a good solution for the server-side? - ok, it defines things in terms of DOM and i understand and respect the history of Cocoon and its preferral for SAX based processing. but IMO this might get problematic if it narrows your perception for possible solutions.
are there other arguments beside that?
and, how many programmer will you find that are familiar with Woody? How far will this knowledge take you? - don't get this wrong; i don't want to argue against Woody at all! i'm not familiar with it but there may be the danger of re-inventing wheels or exploring dead-ends that others already detected. - that applies to both: Woody and XForms.
btw, even if XForms was started with a strong client-side approach there's a growing part of the community that believes in server-side processing. but even this view is still implementation centric; its simply not relevant where the XForms processor lives, if on the server, the client or even distributed between them.
it would be nice if experiences made by Woody would once be submitted to the XForms working group and give it a chance to consider these.
form processing can get a terrible complex beast when starting with interdependent validations and calculations, typing and stuff that users might want and many good efforts crashed or died silently cause they tried to tame the beast all alone. an open-minded exchange of ideas between these concepts would help both to improve instead of making it a side by side race. (that's why i'm reading this list)
Joern
Just my 0.02€.
Ugo
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
