Theoretically, but if you were trying to deliver an action driven system, this would be difficult. You would have to validate inside the pipeline and that would be problematic for a number of reasons. You would have to write some sort of custom validator. The problem here is that configuration is being done at the sitemap level and that is resource intensive. IT would be much more efficient if you could drop in a set of beans, have a Java class read them via introspection and then generate forms based upon the needs of that command. Then you would have a command driven architecture that would be quickly adaptable. all you have to do is drop in another command (a bean object) and viola, a new form gets spit out the far end. I will screw with this and see if I can get it to work. Call it "reflexive form generation" =)
-- Robert ----- Original Message ----- From: "Geoff Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 6:06 AM Subject: RE: XMLForms Versus Traditional HTML forms. > also there's supposed to be support for validation, error handling, and > persistence across calls, right? > > > -----Original Message----- > > From: Geoff Howard [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, January 28, 2003 11:59 PM > > To: [EMAIL PROTECTED] > > Subject: RE: XMLForms Versus Traditional HTML forms. > > > > > > > -----Original Message----- > > > From: Robert Simmons [mailto:[EMAIL PROTECTED]] > > > > > > As for multi-content, I could easily write a transform that > > > converts things > > > to WML based forms. Its a matter of taste. Its also a matter of > > > necessity. I > > > have already spent too long working on the presentation layer to > > > my project > > > and I don't care to invest another month. I am not merely a > > learner but a > > > professional with tight deadlines. I'm not sure its worth the > > > extra effort. > > > But the "not sure" is why I posted the question. If I was sure, > > I wouldn't > > > have posted. > > > > One potential upside is the fact that XMLForms uses beans for the > > datamodel > > (I think). that being the case, I have assumed there'd be a way to let > > ejb's fill that role (which based on past discussions I assume > > you're using > > here) and you'd get the binding to/from the form for free as you > > can in jsp. > > > > > > > > Another thing is if it is in draft than that would be one reason > > > for me to do > > > it the old way. Real business applications require something that > > > works. That > > > isn't always the same thing as something that is "cool". > > > > I've not used xmlform yet because of the draft status and the time to > > learn - same issues you raise. Looks quite promising though, > > especially if > > the bean hunch pans out. > > > > > > > > --------------------------------------------------------------------- > > Please check that your question has not already been answered in the > > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > > For additional commands, e-mail: <[EMAIL PROTECTED]> > > > > > > > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> > > To unsubscribe, e-mail: <[EMAIL PROTECTED]> > For additional commands, e-mail: <[EMAIL PROTECTED]> > --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
