Re: extending XMLForms for different kinds of models...opinions?

[ivelin]

I also think that the "average user" is a relative term.
All users of Cocoon that I have talked to, have been evaluating it as
another J2EE tool,
instead of an all XML server. Most often in my experience it has been
compared against JSP/Struts.


-=Ivelin=-
- Original Message -
From: "Christopher Oliver" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 1:49 PM
Subject: Re: extending XMLForms for different kinds of models...opinions?


> Just wondering, why isn't the "average cocoon user" reluctant to write
> complex xpath or xslt code as well as Java?
>
> Regards,
>
> Chris
>
> Sylvain Wallez wrote:
>
> > This is a good idea when you need to use the JavaBean for some
> > business logic. But there are many cases where you just want to
> > populate a database after successful validation, and the average
> > Cocoon user quickly becomes reluctant to writing Java code, even for
> > storing data in a database ;-)
> >
> > Sylvain
> >
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]


-
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: extending XMLForms for different kinds of models...opinions?

[ivelin]

Title: RE: extending XMLForms for different kinds of models...opinions?



Jonathan,
 
please elaborate on the multiple models 
requirement.
 
I think that Josema's idea is a significant step 
forward.
It does not prohibit future extensions, so I definitely 
support it, but in the meanwhile I am interested to hear what else can we do in 
the future.
 
 
 
-=Ivelin=-

  - Original Message - 
  From: 
  Jonathan Spaeth 
  To: 'Josema Alonso ' ; 'Cocoon-Users ' 
  Sent: Saturday, February 15, 2003 1:00 
  PM
  Subject: RE: extending XMLForms for 
  different kinds of models...opinions?
  
  As a user of cocoon, I see this as a very advantageous 
  feature.  I am currently using cocoon/xmlform and have been developing 
  with it for about five months now.
  Your suggestion matches some of the thoughts I was having at 
  the start of my project while I was becoming accustomed to using the 
  framework.  I have taken advantage of the javabean architecture in the 
  sense that I can dynamically grab data from different data sources, but I 
  agree in the simple cases an xml model would be well-suited.
  Another suggestion I would have is to allow for multiple 
  models.  The W3C spec for xforms has been designed around multiple 
  models; if a second revision of xmlforms is in the works, I would suggest 
  investigating this feature.
  Jon 
  -Original Message- From: 
  Josema Alonso To: Cocoon-Users Sent: 2/15/03 11:39 AM Subject: Re: extending 
  XMLForms for different kinds of models...opinions? 
  Jeremy, 
  I posted here cause I wanted to know if the users would like 
  that feature to be added. I 
  thought the dev list would be more suitable in case of discussing the way of implementing it. 
  Since I'm not currently subscribed to the dev list, feel free 
  to cc the message there if you want to. 
  Btw, glad you like it. 
  Thanks. 
  - Original Message - From: 
  "Jeremy Quinn" <[EMAIL PROTECTED]> To: 
  <[EMAIL PROTECTED]> Sent: Saturday, 
  February 15, 2003 11:24 AM Subject: Re: extending 
  XMLForms for different kinds of models...opinions? 
  > > On Friday, February 14, 
  2003, at 01:07 PM, Josema Alonso wrote: > 
  > > Dear all, > > 
  > > I need your suggestions and opinions in extending 
  the current XMLForm > > 
  model > > approach. If you use XMLForm or are 
  thinking about using it soon, I'd > > suggest youy to read this message and send some feedback to 
  the list. > > 
  > >  
  > > Would it not be best to 
  discuss this on Cocoon-Dev? > > Very nice idea, BTW! > > regards Jeremy > > > 
  - 
  > 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]> > 
  > 
  - 
  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: extending XMLForms for different kinds of models...opinions?

[ivelin]

Ditto.

-=Ivelin=-
- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 11:41 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?


> Ivelin,
>
> That sounds very very good. I was not sure about all the possibilities
when
> using the SourceResolver. If all of that can be accomplished using the
> SourceResolver, it's more powerful than I expected and we should take the
> "java:" as the only way for Javabeans.
>
>
>
> But...
>
>
>
> Since I started with Cocoon, one of the features I don't like is this kind
> of abruptly changes. If we go for the prefix way, forms currently working
> should be coded again (at least their sitemap snippets).
>
>
>
> I think the best solution would be:
>
> - Go with the "java:" prefix for beans
>
> - Any other prefix -> solved by the SourceResolver
>
> - Implicitly assume java, so no prefix means model bean (only by now)
>
> At a later stage (maybe for 2.1beta), we could change it so the java
models
> should be called only explicitly and all of the other resources would be
> solved by the SourceResolver.
>
>
>
> This way, the transition would be easier to accomplish for users with
> working xmlforms.
>
>  Ivelin, I think we talked about something like this?
>
>
>
> Hope all of you like this approach. I'd like to go ahead and try to patch
> the AbstractXMLFormAction.
>
>
>
>
> Best.
>
>
>
>
> - Original Message -
> From: "ivelin" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Saturday, February 15, 2003 5:53 PM
> Subject: Re: extending XMLForms for different kinds of models...opinions?
>
>
> >
> > This sounds good.
> > As you suggest the "java:" prefix can be used for instantiating
JavaBeans.
> > For all other cases though, I was hoping to reuse the standard
> > SourceResolver.
> > This will immediately allow support for a lot of different sources.
> > Here is a snippet from the Sitemap document.
> > http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
> > (I wish there was one discussing just SourceResolvers.)
> >
> > a.. Use http://foo/bar to merge in xml content via http protocol,
received
> > from machine foo.
> > a.. Use context://servlet-context-path/foo/bar to merge in xml content
> from
> > the servlet context.
> > a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content
> from
> > the current sitemap. The appropriate pipeline is selected matching
> > current-sitemap-pipeline.
> > a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content
from
> > the root sitemap. The appropriate pipeline is selected matching
> > root-sitemap-pipeline.
> > a.. Use resource://class-path-context/foo/bar to merge in xml content
from
> > the classpath.
> > a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml
> content
> > coming from a jar via http connection.
> > a.. Use file:///foo/bar to merge in xml content from the filesystem.
> > a.. Use xmldb:://your.xmldb.host/db/foo/bar to merge
in
> > xml content from a XML:DB compliant database.
> > a.. Depending on your setup you may use nfs:, jndi: protocols, too.
> >
> >
> >
> >
> > -=Ivelin=-
> >
> > - Original Message -
> > From: "Josema Alonso" <[EMAIL PROTECTED]>
> > To: "Cocoon-Users" <[EMAIL PROTECTED]>
> > Sent: Friday, February 14, 2003 7:07 AM
> > Subject: extending XMLForms for different kinds of models...opinions?
> >
> >
> > > Dear all,
> > >
> > > I need your suggestions and opinions in extending the current XMLForm
> > model
> > > approach. If you use XMLForm or are thinking about using it soon, I'd
> > > suggest youy to read this message and send some feedback to the list.
> > >
> > > Some days ago, and with some ideas I exchanged with Ivelin, I made a
> > how-to
> > > that should help users on using XMLForm with Xindice for storing XML
> > models.
> > > It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice)
> and
> > > made its way into the CVS a few days ago.
> > >
> > > In this how-to I explored new ways of storing the form model. This new
> way
> > > the XML model is stored in a file in the system with an empty
structure.
> > > Then it is loaded into a JXPath Container and manipulated from there.
> The
> > > getFormModel() is overriden so you don't need a Bean, but just the
file.
> > >
> > > Ivelin thought this could be a great addition to the framework, so we
> were
> > > discussing how to make this available for the end user.
> > >
> > > We exchanged some ideas and they led us to incorporating some
mechanism
> to
> > > the sitemap. We were thinking about a prefix. This way, passing the
> model
> > > parameter to the form would be like this:
> > > 
> > >
> > > The 'java:' prefix would be used for java models. If you would like to
> use
> > > the pure XML model approach you could do something like:
> > > 
> > >
> > > Of course, one of the approaches could be made the default one so this
> > could
> > > make 

sendmail.xsl logicsheet with attachments

[Frank Ridderbusch]

Sometime back, there has been some discussion about sending attachments
with the sendmail.xsl logicsheet on this list. 

Since I now also wanted this features, I've fiddled with sendmail.xsl
and extended it with a  tags.

Please see 

  http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15005

for details. The attached patch with bugzilla id 4879 is the right one.
Since I was at, I also created some documentation, which could be
integrated with the other documentation of XSP logicsheets.

Please see

 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17090

for details.
-- 
MfG/Regards

Frank Ridderbusch

Since I have taken all the Gates out of my computer, it finally works!!


-
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: extending XMLForms for different kinds of models...opinions?

[Jonathan Spaeth]

Title: RE: extending XMLForms for different kinds of models...opinions?





As a user of cocoon, I see this as a very advantageous feature.  I am currently using cocoon/xmlform and have been developing with it for about five months now.

Your suggestion matches some of the thoughts I was having at the start of my project while I was becoming accustomed to using the framework.  I have taken advantage of the javabean architecture in the sense that I can dynamically grab data from different data sources, but I agree in the simple cases an xml model would be well-suited.

Another suggestion I would have is to allow for multiple models.  The W3C spec for xforms has been designed around multiple models; if a second revision of xmlforms is in the works, I would suggest investigating this feature.

Jon


-Original Message-
From: Josema Alonso
To: Cocoon-Users
Sent: 2/15/03 11:39 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?


Jeremy,


I posted here cause I wanted to know if the users would like that
feature to
be added. I thought the dev list would be more suitable in case of
discussing the way of implementing it.


Since I'm not currently subscribed to the dev list, feel free to cc the
message there if you want to.


Btw, glad you like it.


Thanks.



- Original Message -
From: "Jeremy Quinn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 11:24 AM
Subject: Re: extending XMLForms for different kinds of
models...opinions?



>
> On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote:
>
> > Dear all,
> >
> > I need your suggestions and opinions in extending the current
XMLForm
> > model
> > approach. If you use XMLForm or are thinking about using it soon,
I'd
> > suggest youy to read this message and send some feedback to the
list.
> >
>
> 
>
> Would it not be best to discuss this on Cocoon-Dev?
>
> Very nice idea, BTW!
>
> regards Jeremy
>
>
> -
> 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]>
>
>







-
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: extending XMLForms for different kinds of models...opinions?

[Josema Alonso]

Ivelin,

That sounds very very good. I was not sure about all the possibilities when
using the SourceResolver. If all of that can be accomplished using the
SourceResolver, it's more powerful than I expected and we should take the
"java:" as the only way for Javabeans.



But...



Since I started with Cocoon, one of the features I don't like is this kind
of abruptly changes. If we go for the prefix way, forms currently working
should be coded again (at least their sitemap snippets).



I think the best solution would be:

- Go with the "java:" prefix for beans

- Any other prefix -> solved by the SourceResolver

- Implicitly assume java, so no prefix means model bean (only by now)

At a later stage (maybe for 2.1beta), we could change it so the java models
should be called only explicitly and all of the other resources would be
solved by the SourceResolver.



This way, the transition would be easier to accomplish for users with
working xmlforms.

 Ivelin, I think we talked about something like this?



Hope all of you like this approach. I'd like to go ahead and try to patch
the AbstractXMLFormAction.




Best.




- Original Message -
From: "ivelin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 5:53 PM
Subject: Re: extending XMLForms for different kinds of models...opinions?


>
> This sounds good.
> As you suggest the "java:" prefix can be used for instantiating JavaBeans.
> For all other cases though, I was hoping to reuse the standard
> SourceResolver.
> This will immediately allow support for a lot of different sources.
> Here is a snippet from the Sitemap document.
> http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
> (I wish there was one discussing just SourceResolvers.)
>
> a.. Use http://foo/bar to merge in xml content via http protocol, received
> from machine foo.
> a.. Use context://servlet-context-path/foo/bar to merge in xml content
from
> the servlet context.
> a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content
from
> the current sitemap. The appropriate pipeline is selected matching
> current-sitemap-pipeline.
> a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from
> the root sitemap. The appropriate pipeline is selected matching
> root-sitemap-pipeline.
> a.. Use resource://class-path-context/foo/bar to merge in xml content from
> the classpath.
> a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml
content
> coming from a jar via http connection.
> a.. Use file:///foo/bar to merge in xml content from the filesystem.
> a.. Use xmldb:://your.xmldb.host/db/foo/bar to merge in
> xml content from a XML:DB compliant database.
> a.. Depending on your setup you may use nfs:, jndi: protocols, too.
>
>
>
>
> -=Ivelin=-
>
> - Original Message -
> From: "Josema Alonso" <[EMAIL PROTECTED]>
> To: "Cocoon-Users" <[EMAIL PROTECTED]>
> Sent: Friday, February 14, 2003 7:07 AM
> Subject: extending XMLForms for different kinds of models...opinions?
>
>
> > Dear all,
> >
> > I need your suggestions and opinions in extending the current XMLForm
> model
> > approach. If you use XMLForm or are thinking about using it soon, I'd
> > suggest youy to read this message and send some feedback to the list.
> >
> > Some days ago, and with some ideas I exchanged with Ivelin, I made a
> how-to
> > that should help users on using XMLForm with Xindice for storing XML
> models.
> > It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice)
and
> > made its way into the CVS a few days ago.
> >
> > In this how-to I explored new ways of storing the form model. This new
way
> > the XML model is stored in a file in the system with an empty structure.
> > Then it is loaded into a JXPath Container and manipulated from there.
The
> > getFormModel() is overriden so you don't need a Bean, but just the file.
> >
> > Ivelin thought this could be a great addition to the framework, so we
were
> > discussing how to make this available for the end user.
> >
> > We exchanged some ideas and they led us to incorporating some mechanism
to
> > the sitemap. We were thinking about a prefix. This way, passing the
model
> > parameter to the form would be like this:
> > 
> >
> > The 'java:' prefix would be used for java models. If you would like to
use
> > the pure XML model approach you could do something like:
> > 
> >
> > Of course, one of the approaches could be made the default one so this
> could
> > make life easier for most used models declaring them implicit:
> > 
> >
> > I hope I explained it clearly. Now I need your feedback. I'd like to
know
> if
> > this make sense to you and if so, we should decide which of the two
> > approaches should be the implicit one, so the AbstractXMLFormAction
would
> be
> > modified accordingly.
> > Maybe some of you would prefer to see it implemented but having the java
> > models as the implicit ones, so you won't need to change your working
> > 

Re: extending XMLForms for different kinds of models...opinions?

[Josema Alonso]

Jeremy,

I posted here cause I wanted to know if the users would like that feature to
be added. I thought the dev list would be more suitable in case of
discussing the way of implementing it.

Since I'm not currently subscribed to the dev list, feel free to cc the
message there if you want to.

Btw, glad you like it.

Thanks.


- Original Message -
From: "Jeremy Quinn" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 15, 2003 11:24 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?


>
> On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote:
>
> > Dear all,
> >
> > I need your suggestions and opinions in extending the current XMLForm
> > model
> > approach. If you use XMLForm or are thinking about using it soon, I'd
> > suggest youy to read this message and send some feedback to the list.
> >
>
> 
>
> Would it not be best to discuss this on Cocoon-Dev?
>
> Very nice idea, BTW!
>
> regards Jeremy
>
>
> -
> 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]>
>
>






-
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: extending XMLForms for different kinds of models...opinions?

[ivelin]

This sounds good.
As you suggest the "java:" prefix can be used for instantiating JavaBeans.
For all other cases though, I was hoping to reuse the standard
SourceResolver.
This will immediately allow support for a lot of different sources.
Here is a snippet from the Sitemap document.
http://xml.apache.org/cocoon/userdocs/concepts/sitemap.html
(I wish there was one discussing just SourceResolvers.)

a.. Use http://foo/bar to merge in xml content via http protocol, received
from machine foo.
a.. Use context://servlet-context-path/foo/bar to merge in xml content from
the servlet context.
a.. Use cocoon:/current-sitmap-pipeline/foo/bar to merge in xml content from
the current sitemap. The appropriate pipeline is selected matching
current-sitemap-pipeline.
a.. Use cocoon://root-sitmap-pipeline/foo/bar to merge in xml content from
the root sitemap. The appropriate pipeline is selected matching
root-sitemap-pipeline.
a.. Use resource://class-path-context/foo/bar to merge in xml content from
the classpath.
a.. Use jar:http://www.foo.com/bar/jar.jar!/foo/bar to merge in xml content
coming from a jar via http connection.
a.. Use file:///foo/bar to merge in xml content from the filesystem.
a.. Use xmldb:://your.xmldb.host/db/foo/bar to merge in
xml content from a XML:DB compliant database.
a.. Depending on your setup you may use nfs:, jndi: protocols, too.




-=Ivelin=-

- Original Message -
From: "Josema Alonso" <[EMAIL PROTECTED]>
To: "Cocoon-Users" <[EMAIL PROTECTED]>
Sent: Friday, February 14, 2003 7:07 AM
Subject: extending XMLForms for different kinds of models...opinions?


> Dear all,
>
> I need your suggestions and opinions in extending the current XMLForm
model
> approach. If you use XMLForm or are thinking about using it soon, I'd
> suggest youy to read this message and send some feedback to the list.
>
> Some days ago, and with some ideas I exchanged with Ivelin, I made a
how-to
> that should help users on using XMLForm with Xindice for storing XML
models.
> It is at Wiki (http://wiki.cocoondev.org/Wiki.jsp?page=XMLFormXindice) and
> made its way into the CVS a few days ago.
>
> In this how-to I explored new ways of storing the form model. This new way
> the XML model is stored in a file in the system with an empty structure.
> Then it is loaded into a JXPath Container and manipulated from there. The
> getFormModel() is overriden so you don't need a Bean, but just the file.
>
> Ivelin thought this could be a great addition to the framework, so we were
> discussing how to make this available for the end user.
>
> We exchanged some ideas and they led us to incorporating some mechanism to
> the sitemap. We were thinking about a prefix. This way, passing the model
> parameter to the form would be like this:
> 
>
> The 'java:' prefix would be used for java models. If you would like to use
> the pure XML model approach you could do something like:
> 
>
> Of course, one of the approaches could be made the default one so this
could
> make life easier for most used models declaring them implicit:
> 
>
> I hope I explained it clearly. Now I need your feedback. I'd like to know
if
> this make sense to you and if so, we should decide which of the two
> approaches should be the implicit one, so the AbstractXMLFormAction would
be
> modified accordingly.
> Maybe some of you would prefer to see it implemented but having the java
> models as the implicit ones, so you won't need to change your working
> xmlforms in order to use it in the future 2.1. If you feel that way,
please
> say so.
>
> Best,
> Josema.
>
>
> -
> 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]>


-
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: XMLForm Wizard alternative?

[ivelin]

Kudos Robert.
Several people have asked about this.
Please publish the link on the wiki site.

-=Ivelin=-
- Original Message -
From: "Robert Sösemann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, February 14, 2003 9:12 AM
Subject: Re: XMLForm Wizard alternative?


> That would be great. Could you send the file to this adress
> [EMAIL PROTECTED]
>
> Thanks a lot, Robert
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Friday, February 14, 2003 1:47 PM
> Subject: Re: XMLForm Wizard alternative?
>
>
> Hi there
>
> I do not know if anyone else has done it - but I was so impressed with
> xmlform that I took the 2.1 code and hacked it a bit to compile and run on
> cocoon 2.0.4 - it's working for me - and I can create a source jar file
> and such for creating a cocoon-xmlform-2.0.4.jar file to put into
> WEB-INF/lib for cocoon-2.0.4 users that would like to play around with
> xmlform.
>
> If it has your interest send me a mail.
>
> Regards Jakob
>
> Jakob Dalsgaard
> Udvikler
> e-mail:   [EMAIL PROTECTED]
> Vesterbrogade 149
> 1620 København V
> Tlf.:   70 25 80 30
> Fax.: 70 25 80 31
>
>
>
>
>
>
> "Konstantin Piroumian" <[EMAIL PROTECTED]>
> 12/18/02 01:39 PM
> Please respond to cocoon-users
>
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject:Re: XMLForm Wizard alternative?
>
>
> From: "Robert Sösemann" <[EMAIL PROTECTED]>
>
> > Hy,
> >
> > in our project (CMS) we want to easily generate input fields in a
> > wizard-like interface. It is later used by authors to put different
> types
> of
> > articles into a database.
> >
> > As different types of articles have other information needs, we want to
> > provide the user with form field that represent that needs of the
> specific
> > article. So we need a mechanism to generate steps of our wizard (namely
> page
> > with form fields) from centralized information (great would be the db)
> >
> > As this XMLWizard mechanism is only available from a cocoon beta, we are
> not
> > allowed to use it. Can you imagine an alternative way to solve this?
>
> You can simply use the XMLForm's syntax for form representation and use a
> custom action to generate the next step for you. To customize the forms
> you
> can either use XSP or a special transformer.
>
> Konstantin
>
> >
> > Thanks in advance,
> > Robert
> >
> >
> > -
> > 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]>
> >
> >
>
>
> -
> 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]>
>
>
>
>
>
> -
> 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]>
>
>
>
> -
> 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]>


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

[plug] German book on Apache Frameworks (inl. Cocoon)

[Matthew Langham]

A new German book was released yesterday that focusses on the different
Apache frameworks such as Cocoon, Turbine, Velocity etc. The chapter on
Cocoon contains a detailed description of the portal and authentication
frameworks as they are in Cocoon 2.1-dev.

More information here:

http://radio.weblogs.com/0103021/2003/02/15.html#a738

Enjoy.

Matthew

--
Open Source Group   Cocoon { Consulting, Training, Projects }
=
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  [EMAIL PROTECTED] - http://www.s-und-n.de
-
Cocoon book:
  http://www.amazon.com/exec/obidos/ASIN/0735712352/needacake-20
Weblogs:
  http://radio.weblogs.com/0103021/
  http://www.oreillynet.com/weblogs/author/1014
=



-
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: extending XMLForms for different kinds of models...opinions?

[Jeremy Quinn]

On Friday, February 14, 2003, at 01:07 PM, Josema Alonso wrote:


Dear all,

I need your suggestions and opinions in extending the current XMLForm 
model
approach. If you use XMLForm or are thinking about using it soon, I'd
suggest youy to read this message and send some feedback to the list.




Would it not be best to discuss this on Cocoon-Dev?

Very nice idea, BTW!

regards Jeremy


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

MySQL date conversion with modular database action

[Andre Taube]

Any pointers on how to convert 
a date before it's inserted into MySQL database while using cocoon's Modular 
Database Action?
 
I tried
 

    
It seems this "mode" parameter 
is being ignored.
 
Any 
suggestions?
 
Thank you!