RE: XMLForms Versus Traditional HTML forms.

2003-01-29 Thread Geoff Howard 
not a problem - i figured you were in anger management counseling to deal
with that last screw up of mine ... ;)

Geoff

> -Original Message-
> From: Christian Haul [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 29, 2003 3:31 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XMLForms Versus Traditional HTML forms.
>
>
> On 29.Jan.2003 -- 12:29 AM, Geoff Howard wrote:
> > 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.
>
> *blush*
>
> > 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.
>
> Sorry, that I haven't gotten back to you on this but I have been
> banging my head with some other stuff. Anyway, I'm almost done with it
> and your sample will show up shortly in CVS.
>
>   Chris.
> --
> C h r i s t i a n   H a u l
> [EMAIL PROTECTED]
> fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08
>
> -
> 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]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-29 Thread Christian Haul 
On 29.Jan.2003 -- 12:29 AM, Geoff Howard wrote:
> 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.

*blush*

> 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.

Sorry, that I haven't gotten back to you on this but I have been
banging my head with some other stuff. Anyway, I'm almost done with it
and your sample will show up shortly in CVS.

Chris.
-- 
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Geoff Howard 
oh, I assumed you couldn't find the xmlform samples only - if not, have you
switched up by mistake with the stripped down war I sent?

I see to remember seeing some messages on doing the dynamic binding you are
talking about - may want to do a quick search of the dev list archive and
then start a conversation over there.

Geoff

> -Original Message-
> From: Niclas Hedhman [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, January 29, 2003 12:26 AM
> To: [EMAIL PROTECTED]
> Subject: Re: XMLForms Versus Traditional HTML forms.
>
>
> On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
> > Hmm .. I cant seem to even find the samples on my cocoon
> installation. Are
> > they not in the current binary distribution ?
>
> Provided you have dropped the cocoon.war into
> $TOMCAT_HOME/webapps, you should
> find samples in;
>
> $TOMCAT_HOME/webapps/cocoon/samples/
>
>
> Niclas
>
> > -- Robert
> >
> > - Original Message -
> > From: "Kirchhoff, Lars" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 29, 2003 5:09 AM
> > Subject: AW: XMLForms Versus Traditional HTML forms.
> >
> >
> > But why you need then cocoon for? If you just use traditional html
> > isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
> > just use jsp or something similar?
> >
> > The main advantage of cocoon and xmlform for me is still to create
> > a xml document, which then can be transformed through the pipeline
> > in nearly every possible format. This means creating applications or
> > websites, which can serve multiple devices.
> >
> > Especially for xmlforms  there is a strong seperation of concerns,
> > which in the first moment and for small application is a bit to
> > much, but helps to divide the programming of the actual dataflow and
> > business logic from the presentation layer and keeps the code
> > manageable. I don't like to mix up any program code with tags from
> > either xml or html. That's why I use and tried xmlform and don't
> > feel comfortable with xsp.
> >
> > Of course you can transform the xmlform tags to html form tags,
> > as long as there are not to many browser out, which are
> > understanding xforms, which are still in draft.
> >
> > BTW does anybody know an reference implementation of an xforms
> > browser?
> >
> > regards
> > Lars
> >
> > > -Ursprüngliche Nachricht-
> > > Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
> > > Gesendet: Mittwoch, 29. Januar 2003 11:50
> > > An: [EMAIL PROTECTED]
> > > Betreff: Re: XMLForms Versus Traditional HTML forms.
> > >
> > >
> > > Well actually I already have some generators running to fetch
> > > data from the
> > > database. I have put that data in manually. Now I want to do
> > > it dynamically.
> > > Simplicity wise I should use "conventional" forms, but I am
> > > not sure if that
> > > is the "right" way to do it.
> > >
> > > -- Robert
> > >
> > > - Original Message -
> > > From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Wednesday, January 29, 2003 4:39 AM
> > > Subject: Re: XMLForms Versus Traditional HTML forms.
> > >
> > > On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> > > > Greetings. I would like to know what people favor using.
> > > >
> > > > By my, admittedly limited, knowledge, the traditional HTML
> > >
> > > forms will still
> > >
> > > > work with cocoon as the request will still have access to the data.
> > > > Alternatively if I use XMLForms, I'm not sure how much
> > >
> > > learning effort Id
> > >
> > > > have to invest. I read the XMLForm tutorial at
> > >
> > > http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
> >
> > m-wizard-3.ht
> >
> > >ml and am still a but unclear how I define how the form will
> be rendered.
> > > Does the user have control over that at all? If I use HTML
> forms then I
> > > would be imbedding a form into an XSL transform which would
> print out the
> > > form for the user.
> >
> > Slightly beyond my experience (I also use 'conventional'
> approach), but I
> > see
> > it as;
> &g

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
Yeah .. well I meant the XMLForms samples. And I still haven't found those.
The other samples I found easily.

-- Robert

- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 6:25 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
> Hmm .. I cant seem to even find the samples on my cocoon installation. Are
> they not in the current binary distribution ?

Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you
should
find samples in;

$TOMCAT_HOME/webapps/cocoon/samples/


Niclas

> -- Robert
>
> - Original Message -
> From: "Kirchhoff, Lars" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 29, 2003 5:09 AM
> Subject: AW: XMLForms Versus Traditional HTML forms.
>
>
> But why you need then cocoon for? If you just use traditional html
> isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
> just use jsp or something similar?
>
> The main advantage of cocoon and xmlform for me is still to create
> a xml document, which then can be transformed through the pipeline
> in nearly every possible format. This means creating applications or
> websites, which can serve multiple devices.
>
> Especially for xmlforms  there is a strong seperation of concerns,
> which in the first moment and for small application is a bit to
> much, but helps to divide the programming of the actual dataflow and
> business logic from the presentation layer and keeps the code
> manageable. I don't like to mix up any program code with tags from
> either xml or html. That's why I use and tried xmlform and don't
> feel comfortable with xsp.
>
> Of course you can transform the xmlform tags to html form tags,
> as long as there are not to many browser out, which are
> understanding xforms, which are still in draft.
>
> BTW does anybody know an reference implementation of an xforms
> browser?
>
> regards
> Lars
>
> > -----Ursprüngliche Nachricht-
> > Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
> > Gesendet: Mittwoch, 29. Januar 2003 11:50
> > An: [EMAIL PROTECTED]
> > Betreff: Re: XMLForms Versus Traditional HTML forms.
> >
> >
> > Well actually I already have some generators running to fetch
> > data from the
> > database. I have put that data in manually. Now I want to do
> > it dynamically.
> > Simplicity wise I should use "conventional" forms, but I am
> > not sure if that
> > is the "right" way to do it.
> >
> > -- Robert
> >
> > - Original Message -
> > From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 29, 2003 4:39 AM
> > Subject: Re: XMLForms Versus Traditional HTML forms.
> >
> > On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> > > Greetings. I would like to know what people favor using.
> > >
> > > By my, admittedly limited, knowledge, the traditional HTML
> >
> > forms will still
> >
> > > work with cocoon as the request will still have access to the data.
> > > Alternatively if I use XMLForms, I'm not sure how much
> >
> > learning effort Id
> >
> > > have to invest. I read the XMLForm tutorial at
> >
> > http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
>
> m-wizard-3.ht
>
> >ml and am still a but unclear how I define how the form will be rendered.
> > Does the user have control over that at all? If I use HTML forms then I
> > would be imbedding a form into an XSL transform which would print out the
> > form for the user.
>
> Slightly beyond my experience (I also use 'conventional' approach), but I
> see
> it as;
>
> 1. The XMLForm generator creates a XML document of the POST request.
> 2. You can aggregate that with other XML documents, static or dynamic.
> 3. Feed that to the transformer(s).
> 4. Output
>
> Meaning, the main advantage would be that you can do a fair amount of logic
> on
> the posted request in XSL (XSL is Turing complete, right?), without writing
> any Java/XSP code. For some people (those who know XSL better than Java)
> that
> is more power with less hazzle.
>
> Niclas
>
> -
> 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: <

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Niclas Hedhman 
On Wednesday 29 January 2003 13:11, Robert Simmons wrote:
> Hmm .. I cant seem to even find the samples on my cocoon installation. Are
> they not in the current binary distribution ?

Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you should 
find samples in;

$TOMCAT_HOME/webapps/cocoon/samples/


Niclas

> -- Robert
>
> - Original Message -
> From: "Kirchhoff, Lars" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 29, 2003 5:09 AM
> Subject: AW: XMLForms Versus Traditional HTML forms.
>
>
> But why you need then cocoon for? If you just use traditional html
> isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
> just use jsp or something similar?
>
> The main advantage of cocoon and xmlform for me is still to create
> a xml document, which then can be transformed through the pipeline
> in nearly every possible format. This means creating applications or
> websites, which can serve multiple devices.
>
> Especially for xmlforms  there is a strong seperation of concerns,
> which in the first moment and for small application is a bit to
> much, but helps to divide the programming of the actual dataflow and
> business logic from the presentation layer and keeps the code
> manageable. I don't like to mix up any program code with tags from
> either xml or html. That's why I use and tried xmlform and don't
> feel comfortable with xsp.
>
> Of course you can transform the xmlform tags to html form tags,
> as long as there are not to many browser out, which are
> understanding xforms, which are still in draft.
>
> BTW does anybody know an reference implementation of an xforms
> browser?
>
> regards
> Lars
>
> > -----Ursprüngliche Nachricht-----
> > Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
> > Gesendet: Mittwoch, 29. Januar 2003 11:50
> > An: [EMAIL PROTECTED]
> > Betreff: Re: XMLForms Versus Traditional HTML forms.
> >
> >
> > Well actually I already have some generators running to fetch
> > data from the
> > database. I have put that data in manually. Now I want to do
> > it dynamically.
> > Simplicity wise I should use "conventional" forms, but I am
> > not sure if that
> > is the "right" way to do it.
> >
> > -- Robert
> >
> > - Original Message -
> > From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Wednesday, January 29, 2003 4:39 AM
> > Subject: Re: XMLForms Versus Traditional HTML forms.
> >
> > On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> > > Greetings. I would like to know what people favor using.
> > >
> > > By my, admittedly limited, knowledge, the traditional HTML
> >
> > forms will still
> >
> > > work with cocoon as the request will still have access to the data.
> > > Alternatively if I use XMLForms, I'm not sure how much
> >
> > learning effort Id
> >
> > > have to invest. I read the XMLForm tutorial at
> >
> > http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
>
> m-wizard-3.ht
>
> >ml and am still a but unclear how I define how the form will be rendered.
> > Does the user have control over that at all? If I use HTML forms then I
> > would be imbedding a form into an XSL transform which would print out the
> > form for the user.
>
> Slightly beyond my experience (I also use 'conventional' approach), but I
> see
> it as;
>
> 1. The XMLForm generator creates a XML document of the POST request.
> 2. You can aggregate that with other XML documents, static or dynamic.
> 3. Feed that to the transformer(s).
> 4. Output
>
> Meaning, the main advantage would be that you can do a fair amount of logic
> on
> the posted request in XSL (XSL is Turing complete, right?), without writing
> any Java/XSP code. For some people (those who know XSL better than Java)
> that
> is more power with less hazzle.
>
> Niclas
>
> -
> 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 uns

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
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:



Registration


  



Name:




age
New age



 
  Change Age
 

  

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]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Niclas Hedhman 
On Wednesday 29 January 2003 13:01, Robert Simmons wrote:
> 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"

You need to bring this to cocoon-dev mailing list, I think...

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

RE: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Geoff Howard 
> 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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
Hmm .. I cant seem to even find the samples on my cocoon installation. Are
they not in the current binary distribution ?

-- Robert

- Original Message -
From: "Kirchhoff, Lars" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


> -Ursprüngliche Nachricht-
> Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 29. Januar 2003 11:50
> An: [EMAIL PROTECTED]
> Betreff: Re: XMLForms Versus Traditional HTML forms.
>
>
> Well actually I already have some generators running to fetch
> data from the
> database. I have put that data in manually. Now I want to do
> it dynamically.
> Simplicity wise I should use "conventional" forms, but I am
> not sure if that
> is the "right" way to do it.
>
> -- Robert
>
> - Original Message -
> From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 29, 2003 4:39 AM
> Subject: Re: XMLForms Versus Traditional HTML forms.
>
>
> On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> > Greetings. I would like to know what people favor using.
> >
> > By my, admittedly limited, knowledge, the traditional HTML
> forms will still
> > work with cocoon as the request will still have access to the data.
> > Alternatively if I use XMLForms, I'm not sure how much
> learning effort Id
> > have to invest. I read the XMLForm tutorial at
> >
> http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
>ml and am still a but unclear how I define how the form will be rendered.
> Does the user have control over that at all? If I use HTML forms then I
> would be imbedding a form into an XSL transform which would print out the
> form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
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]>


-
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]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
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]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
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]>

RE: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Geoff Howard 
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]>

RE: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Geoff Howard 
> -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. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
Lets not lump cocoon to "XMLForms or no XMLForms." Nor should we pick out any
other one feature of cocoon and say that if you don't use this feature you
shouldn't use cocoon. Nor should we say something like "if you aren't going
pure XML XSL XSP that you shouldn't use cocoon. Cocoon is a toolkit and you
should pick those tools appropriate to your use. I chose cocoon over JSP
because I get the multi format content and clear separation of logic and
presentation. To me, a form is presentation.

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.

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".

-- Robert

- Original Message -
From: "Kirchhoff, Lars" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 5:09 AM
Subject: AW: XMLForms Versus Traditional HTML forms.


But why you need then cocoon for? If you just use traditional html
isn't cocoon a bit to much? i'm just curios? Wouldn't it then better
just use jsp or something similar?

The main advantage of cocoon and xmlform for me is still to create
a xml document, which then can be transformed through the pipeline
in nearly every possible format. This means creating applications or
websites, which can serve multiple devices.

Especially for xmlforms  there is a strong seperation of concerns,
which in the first moment and for small application is a bit to
much, but helps to divide the programming of the actual dataflow and
business logic from the presentation layer and keeps the code
manageable. I don't like to mix up any program code with tags from
either xml or html. That's why I use and tried xmlform and don't
feel comfortable with xsp.

Of course you can transform the xmlform tags to html form tags,
as long as there are not to many browser out, which are
understanding xforms, which are still in draft.

BTW does anybody know an reference implementation of an xforms
browser?

regards
Lars


> -Ursprüngliche Nachricht-
> Von: Robert Simmons [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 29. Januar 2003 11:50
> An: [EMAIL PROTECTED]
> Betreff: Re: XMLForms Versus Traditional HTML forms.
>
>
> Well actually I already have some generators running to fetch
> data from the
> database. I have put that data in manually. Now I want to do
> it dynamically.
> Simplicity wise I should use "conventional" forms, but I am
> not sure if that
> is the "right" way to do it.
>
> -- Robert
>
> - Original Message -
> From: "Niclas Hedhman" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, January 29, 2003 4:39 AM
> Subject: Re: XMLForms Versus Traditional HTML forms.
>
>
> On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> > Greetings. I would like to know what people favor using.
> >
> > By my, admittedly limited, knowledge, the traditional HTML
> forms will still
> > work with cocoon as the request will still have access to the data.
> > Alternatively if I use XMLForms, I'm not sure how much
> learning effort Id
> > have to invest. I read the XMLForm tutorial at
> >
> http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor
m-wizard-3.ht
>ml and am still a but unclear how I define how the form will be rendered.
> Does the user have control over that at all? If I use HTML forms then I
> would be imbedding a form into an XSL transform which would print out the
> form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I
see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java)
that
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. <http://xml.apache.org/c

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Robert Simmons 
Well actually I already have some generators running to fetch data from the
database. I have put that data in manually. Now I want to do it dynamically.
Simplicity wise I should use "conventional" forms, but I am not sure if that
is the "right" way to do it.

-- Robert

- Original Message -
From: "Niclas Hedhman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, January 29, 2003 4:39 AM
Subject: Re: XMLForms Versus Traditional HTML forms.


On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> Greetings. I would like to know what people favor using.
>
> By my, admittedly limited, knowledge, the traditional HTML forms will still
> work with cocoon as the request will still have access to the data.
> Alternatively if I use XMLForms, I'm not sure how much learning effort Id
> have to invest. I read the XMLForm tutorial at
> http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht
>ml and am still a but unclear how I define how the form will be rendered.
> Does the user have control over that at all? If I use HTML forms then I
> would be imbedding a form into an XSL transform which would print out the
> form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I see
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic
on
the posted request in XSL (XSL is Turing complete, right?), without writing
any Java/XSP code. For some people (those who know XSL better than Java) that
is more power with less hazzle.

Niclas

-
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]>

Re: XMLForms Versus Traditional HTML forms.

2003-01-28 Thread Niclas Hedhman 
On Wednesday 29 January 2003 11:16, Robert Simmons wrote:
> Greetings. I would like to know what people favor using.
>
> By my, admittedly limited, knowledge, the traditional HTML forms will still
> work with cocoon as the request will still have access to the data.
> Alternatively if I use XMLForms, I'm not sure how much learning effort Id
> have to invest. I read the XMLForm tutorial at
> http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlform-wizard-3.ht
>ml and am still a but unclear how I define how the form will be rendered.
> Does the user have control over that at all? If I use HTML forms then I
> would be imbedding a form into an XSL transform which would print out the
> form for the user.

Slightly beyond my experience (I also use 'conventional' approach), but I see 
it as;

1. The XMLForm generator creates a XML document of the POST request.
2. You can aggregate that with other XML documents, static or dynamic.
3. Feed that to the transformer(s).
4. Output

Meaning, the main advantage would be that you can do a fair amount of logic on 
the posted request in XSL (XSL is Turing complete, right?), without writing 
any Java/XSP code. For some people (those who know XSL better than Java) that 
is more power with less hazzle.

Niclas

-
Please check that your question  has not already been answered in the
FAQ before posting. 

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail:   <[EMAIL PROTECTED]>