If there is any overlap, I'm not aware of it. Cocoon is XML centric and not
Java centric. What I'm thinking of is a way to drive XML with Java. So if you
had a bean like ...
public class ChangeAge extends Command {
private int age;
private String name;
// getter and setters.
}
Than a java class would spit out the following:
<xf:form id="ChangeAge" view="" action="ChangeAge.html">
<xf:caption>Registration</xf:caption>
<error>
<xf:violations class="error"/>
</error>
<xf:textbox ref="/name">
<xf:caption>Name:</xf:caption>
<xf:violations class="error"/>
</xf:textbox>
<xf:textbox ref="/age">
<xf:caption>age</xf:caption>
<xf:help>New age</xf:help>
<xf:violations class="error"/>
</xf:textbox>
<xf:submit id="submit" class="button">
<xf:caption>Change Age</xf:caption>
</xf:submit>
</xf:form>
And then the user could use XSLT to dynamically transform the form into what
they wanted. The problem is that the sitemap could no longer be effectively
used to configure individual actions because they would largely depend upon
what actions exist in the object model of the beans. But I do have a few
ideas. ;)
-- Robert
----- Original Message -----
From: "Geoff Howard" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 6:29 AM
Subject: RE: XMLForms Versus Traditional HTML forms.
> > As for forms being in draft, that bothers me.
>
> Don't rely on my word here - that is my memory of what I learned (and
> someone just said that tonight, too right?) looking into xmlform again
about
> 2-3 months ago, so things may have moved on.
>
> > 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.
>
> I have recently been converted to the "modular database actions" which may
> provide some inspiration and groundwork for actions hitting session beans
> (assuming that's what you meant). One xml config file with db table
> structure and a few other tidbits handles my insert, update and deletes
(for
> simple cases) with no coding. I think they're in 2.0.4 but not positive.
> Modular in this case refers to the use of "input modules". Christian Haul
> on the list appears to be the author/resident guru on both.
>
> As a side note, I recently worked with Chris to make some trivial
> modifications that allow multipart form file uploads to populate db blobs
> automatically.
>
> >
> > 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.
>
> This sounds great - is there no overlap with the current stuff?
>
> Geoff
>
>
>
> ---------------------------------------------------------------------
> 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]>
