Torsten Curdt wrote:
> Sorry, for the late follow up guys. I am in bed with a bad cold...
>
> First off: I like say some more words on XForms topic...
>
> Please guys!! Be aware of the fact that XForms is heavily client centric!
> I'm not quite sure (any longer) if a server implementation is really that
> easy to come up with, intended or possible at all.
>
> It makes me also a bit upset hearing people saying "That's not XForms
> complient" but on the other hand saying "Struts is great". (Don't mean
> anyone specificly) AFACS it does not need a W3C spec to build a good form
> handling framework that people associate with attributes like "elegance".
> AFAIK Struts does not conform to any W3C spec either. Of course it would
> be even better if we could make if conform such a spec but last commits to
> exFormular are almost a year from now. I doubt this will change in the
> near future. And my company wants a form handling sollution for cocoon
> *now* and not in in 3 years. Otherwise they want me to build a homegrown
> one again. I am happy they support my current cocoon-only work...
I second Torten's comments. XForms cannot cleanly be implemented on the
server side. There are things like XForm events that cannot work
correctly. We *need* a client plugin to process XForms based work which
is sad.
I have been back and forth with the XForms expert group, and noone has
been able to convince the W3C workgroup that XForms needs to be friendly
to the server as well. On the contrary, they have been resolute on
making it a client standard--while trying to pay lip service to the
server folks. There are several people who have tried to get them to
see the light, and have been meet with statements ranging from "you
don't get it" to them completely missing the point of the argument--or
completely ignoring it.
It is not a pleasant standard to work with, and I am saddened by that.
> <snip/>
>
>>>>what do mean by "object model of the form"? I actually don't
>>>>want to have
>>>>always beans behind my forms. Is this what you are at?
>>>
>>>Yes, that was the idea. Anyway, we need to know, as you've said, what to
>>>expect from the current request. There are two possibilities: create a
>>>separate description (say, phases) or use the form description itself. If we
>>>create an object model of the form (not only UI, but also bindings) then we
>>>can simply iterate through form fields, validate according values from
>>>request against a schema, then we can validate request against binding
>>>contraints.
>>
>
> First of all: not everyone (e.g. our company) wants beans in the
> background. We have done this in our last project but found it not that
> comfortable... (you need people who can program java, you need always to
> compile on changes - same reasons why we moved away from the compiled
> sitemap to the interpreted one - thanx Sylvain :)
Again, I agree. Beans are high maintenance for, what is in this case,
little advantage. I spent a week coming up with a bean framework for
a webapp, and had little progress on the webapp. It is sad, but that
is what happened. SOmetimes it is enough to have a maleable model and
let the form framework take care of the rest.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
