Well, if you want my advice stay away from entity beans. They are evil in the extreme. As for forms being in draft, that bothers me. I do, however, have allot of actions I need to write and some common method of outputting the forms automatically based on the command being run would be interesting to me. I might take a hybrid approach here.
What Id like to have happen is that a user decides to execute a command which hits a generator with the name of the command and any initialization parameters. Then the generator spits out a document containing the structure of needed information from the form. Then the style sheets take over and render the forms and then the user can submit them. To do this I might just borrow the XML form namespace and have the generator spit out valid XML form documents. Just thinking out loud. -- Robert ----- Original Message ----- From: "Geoff Howard" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 29, 2003 5:59 AM 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]>
