You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by ivelin <iv...@apache.org> on 2003/02/15 17:53:59 UTC
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 driver here>://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" <jo...@simbiosystems.com>
To: "Cocoon-Users" <co...@xml.apache.org>
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:
> <map:parameter name="xmlform-model" value="java:MyBean"/>
>
> 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:
> <map:parameter name="xmlform-model" value="xml:MyDocument"/>
>
> 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:
> <map:parameter name="xmlform-model" value="MyModel"/>
>
> 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. <http://xml.apache.org/cocoon/faq/index.html>
>
> To unsubscribe, e-mail: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
Ditto.
-=Ivelin=-
----- Original Message -----
From: "Josema Alonso" <jo...@simbiosystems.com>
To: <co...@xml.apache.org>
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" <iv...@apache.org>
> To: <co...@xml.apache.org>
> Cc: <co...@xml.apache.org>
> 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 driver here>://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" <jo...@simbiosystems.com>
> > To: "Cocoon-Users" <co...@xml.apache.org>
> > 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:
> > > <map:parameter name="xmlform-model" value="java:MyBean"/>
> > >
> > > 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:
> > > <map:parameter name="xmlform-model" value="xml:MyDocument"/>
> > >
> > > 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:
> > > <map:parameter name="xmlform-model" value="MyModel"/>
> > >
> > > 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. <http://xml.apache.org/cocoon/faq/index.html>
> > >
> > > To unsubscribe, e-mail: <co...@xml.apache.org>
> > > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
> > ---------------------------------------------------------------------
> > 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: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
Ditto.
-=Ivelin=-
----- Original Message -----
From: "Josema Alonso" <jo...@simbiosystems.com>
To: <co...@xml.apache.org>
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" <iv...@apache.org>
> To: <co...@xml.apache.org>
> Cc: <co...@xml.apache.org>
> 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 driver here>://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" <jo...@simbiosystems.com>
> > To: "Cocoon-Users" <co...@xml.apache.org>
> > 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:
> > > <map:parameter name="xmlform-model" value="java:MyBean"/>
> > >
> > > 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:
> > > <map:parameter name="xmlform-model" value="xml:MyDocument"/>
> > >
> > > 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:
> > > <map:parameter name="xmlform-model" value="MyModel"/>
> > >
> > > 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. <http://xml.apache.org/cocoon/faq/index.html>
> > >
> > > To unsubscribe, e-mail: <co...@xml.apache.org>
> > > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
> > ---------------------------------------------------------------------
> > 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: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
> >
> >
>
>
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: extending XMLForms for different kinds of models...opinions?
Posted by Josema Alonso <jo...@simbiosystems.com>.
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" <iv...@apache.org>
To: <co...@xml.apache.org>
Cc: <co...@xml.apache.org>
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 driver here>://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" <jo...@simbiosystems.com>
> To: "Cocoon-Users" <co...@xml.apache.org>
> 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:
> > <map:parameter name="xmlform-model" value="java:MyBean"/>
> >
> > 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:
> > <map:parameter name="xmlform-model" value="xml:MyDocument"/>
> >
> > 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:
> > <map:parameter name="xmlform-model" value="MyModel"/>
> >
> > 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. <http://xml.apache.org/cocoon/faq/index.html>
> >
> > To unsubscribe, e-mail: <co...@xml.apache.org>
> > For additional commands, e-mail: <co...@xml.apache.org>
>
>
> ---------------------------------------------------------------------
> 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: <co...@xml.apache.org>
> For additional commands, e-mail: <co...@xml.apache.org>
>
>
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: extending XMLForms for different kinds of models...opinions?
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Sunday 16 February 2003 03:49, Christopher Oliver wrote:
> Just wondering, why isn't the "average cocoon user" reluctant to write
> complex xpath or xslt code as well as Java?
People, there is NO "average Cocoon user". Please refer to the SoC diagram at
http://xml.apache.org/cocoon/introduction.html
where Management, Logic, Content and Style is separated.
Only Logic is "programming oriented" and this group can possibly also be
divided into several sub-groups of preference, such as
Java, XSP and XSLT, maybe others such as PHP, Python and Perl as well.
Niclas
> 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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christopher Oliver wrote:
> Just wondering, why isn't the "average cocoon user" reluctant to write
> complex xpath or xslt code as well as Java?
Because Cocoon makes it so easy to write very powerful things with
simple xpath and xslt, that having to go back to a compiler and
deploying classes is a very heavy process compared to the
save-and-reload-in-browser cycle allowed by XSLT and the sitemap and
other scripting languages.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: cocoon usability
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stefano Mazzocchi wrote:
> Christopher Oliver wrote:
>
>> Just wondering, why isn't the "average cocoon user" reluctant to
>> write complex xpath or xslt code as well as Java?
>
>
> This is a damn good question.
>
> I think Cocoon is starting to suffer from 'over-RAD-ness', meaning
> that people love the fact that they can have something to show their
> bosses real quick (RAD stands for Rapid Application Development, if
> you don't know the acronim), then they continue to work on those
> hacky-shaped RAD mock-ups and create the whole web application from them.
Showing to the boss is not the main point, because the boss knows it can
take time to build an application correctly. The main point is when
Cocoon allows you to show to a potential customer _something working_
when competitors show only paper.
I know you love (as I do) clean architectures and clean separation of
concerns, but there are some users, that come from the scripted web
world (php, asp, etc.) that have very, very bad engineering habits. I've
met such people not later than this week, and conviced them to use
Cocoon by showing its abilities to cleanly separate content,
presentation et al. They were astounded by the power of the sitemap and
Cocoon's builtin components. But these people don't know well Java, to
say the least ("I know C++, so I can write some Java").
Now there was a question : "I use xxx (don't remember the name) in PHP
to populate my database. I just give it my database URL and it produces
some web pages to edit its content. How can I do that with Cocoon ?"
Errm, you have to write forms, validation rules, store a JavaBean in SQL
using an O/R tool, or use ESQL in XSP... Well, not that easy !
Cocoon has the power to be an efficient RAD tool while enforcing good
structuration of the application. I'd like it to provide the few missing
pieces that will allow it to attract those very numerous people that
assemble applications like Lego blocks. If we don't provide the good
blocks, they will continue with Megablocks (a bad Lego clone, FYI). If
we provide them, they will stay here and will slowly discover what
Cocoon provides to write well-structured large applications.
> Cocoon users tend to think lego-ish so much that they'd rather spend
> time finding strange and creative ways of mixing the current existing
> components gluing the pieces with hard-core XSLT, rather then spending
> a few lines of code to write their own.
Lego is the current trend of software engineering, as it has been for
years in the electronics world : on one side there are component
writers, and on the other side, there are components assemblers. And the
time is not far where assemblers will no more be able to write
components, as existing components offer so high-level abstractions and
so much power than going back to the elementary transitor or Java class
is very difficult and provides so low-level functionnality that people
don't think it's worth it.
The Cocoon documentation (or lack thereof) is a good example of this
comparison with electronics : component documentation is no more in the
Javadoc, but in separate files that are classified by component type.
Isn't this close to a component catalog from Texas Instruments or Intel
? The difficulties we have to write it also show that we, component
writers, have not yet fully understood what the expectations of
component assemblers are.
> The reason, IMO, is the fast try/fail cycle of sitemap+XSLT compared
> to custom java code.
Yep. This is one of the main reasons. Having to compile and deploy a
sitemap or an XSLT before using it would certainly have ruined Cocoon's
abilities for success.
> XSP improves the speed of the try/fail cycle, but since some major
> cocoon developers/evangelists dislike XSPs, users get the same
> impression and run away from them and jump into those pre-build
> half-baked components we ship.
Who dislikes XSP ? And why ? Transition from Cocoon 1 to Cocoon 2 has
reduced XSP's importance both because it's now a generator (and cannot
drive the pipeline construction) and because we have much more
components than in C1, but it's still useful.
> I expect flowscript to bring some balance back on this.
Certainly. But we also have to link it with other Cocoon components such
as validation engines (e.g. XMLForm) to make it more accessible.
> Also, one of the compliments I receive from cocoon users is that
> cocoon forces you to think at what you're doing.
>
> Unfortunately, this thinking stops at how to compose the existing
> components, rather than thinking at how to componentize your web
> application and *then* look for prebuilt components that do what you
> need.
>
> I expect blocks to build some balance back on this.
Can you elaborate on this, as I don't see what blocks will change in
this area ?
> There is a lot of work to do and I'm not happy about the overall
> usability of what we have right now.
>
> But I think that better build system + flow + block + refactored
> documentation will do it.
>
> Let's get back working.
And there's a lot to do !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
cocoon usability
Posted by Stefano Mazzocchi <st...@apache.org>.
Christopher Oliver wrote:
> Just wondering, why isn't the "average cocoon user" reluctant to write
> complex xpath or xslt code as well as Java?
This is a damn good question.
I think Cocoon is starting to suffer from 'over-RAD-ness', meaning that
people love the fact that they can have something to show their bosses
real quick (RAD stands for Rapid Application Development, if you don't
know the acronim), then they continue to work on those hacky-shaped RAD
mock-ups and create the whole web application from them.
Cocoon users tend to think lego-ish so much that they'd rather spend
time finding strange and creative ways of mixing the current existing
components gluing the pieces with hard-core XSLT, rather then spending a
few lines of code to write their own.
The reason, IMO, is the fast try/fail cycle of sitemap+XSLT compared to
custom java code.
XSP improves the speed of the try/fail cycle, but since some major
cocoon developers/evangelists dislike XSPs, users get the same
impression and run away from them and jump into those pre-build
half-baked components we ship.
I expect flowscript to bring some balance back on this.
Also, one of the compliments I receive from cocoon users is that cocoon
forces you to think at what you're doing.
Unfortunately, this thinking stops at how to compose the existing
components, rather than thinking at how to componentize your web
application and *then* look for prebuilt components that do what you need.
I expect blocks to build some balance back on this.
There is a lot of work to do and I'm not happy about the overall
usability of what we have right now.
But I think that better build system + flow + block + refactored
documentation will do it.
Let's get back working.
--
Stefano Mazzocchi <st...@apache.org>
Pluralitas non est ponenda sine necessitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
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" <re...@verizon.net>
To: <co...@xml.apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
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" <re...@verizon.net>
To: <co...@xml.apache.org>
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
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: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: extending XMLForms for different kinds of models...opinions?
Posted by Christopher Oliver <re...@verizon.net>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Antonio Gallardo <ag...@agsoftware.dnsalias.com>.
Sylvain Wallez dijo:
> Ugo Cei wrote:
>
>> 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
>>
>>
>> I'm wondering how writing *very* simple Java code (mostly classes with
>> a handful of private data fields with getters and setters, and even
>> this step can largely be automated using Hibernate), is worse than
>> writing SQL code, forever tieing your presentation layer to the
>> implementation of your storage layer.
>
>
> Read my answer to Oliver. Note that I'm not trying to push bad software
> engineering practices, as I've been advocating separation of domains for
> a very, very long time. I'm just reporting what I've seen several
> times.
>
> Cocoon allows to "forget" the underlying Java code by the power of its
> architecture and the available components. And sometimes it hurts when
> you have to go back to "raw" Java code for something as simple as
> populating a few values in a DB.
I agree in this point....
First, I think the use of beans is OK. The question here is how to make
the "glue" between Beans and XMLForm in an easy way to everybody. The SQL
approach is not good. It tie your application to a concrete Database
Implementation (please read PostgreSQL, MySQL, etc.).
I think we need to find an easy way to create the Beans from the XMLForm
or another XML document.
I builded my first Cocoon webapp using the traditional cycle suggested for
Cocoon 2.0x. When I was writing the code I felt like something is missing,
because the FormValidator files are a very repetitive task. Always I write
almost the same code again and again. There was a lack of datatype, etc.
For example: The constrains for a email field is always the same regarless
is this is a email field for a customer table or a email field for a user
table or a provider table. I hope you can get my point.
Then I started thinking that maybe the answer is a little away from
Cocoon... Maybe an IA application that can be smart enough to build the
Database based on all the XMLForm you create. Then it will create the SQL
implementation for the Database you need to do.
Maybe this is a crazy idea, but I saw some software implementation that
use this approach. What about this? :-)
Of course all will be described in a XMLForm.
I hope it will help.
Best Regards,
Antonio Gallardo.
>
> An important point to notice also, is that Cocoon can be used
> efficiently by people that have a very low Java knowledge but know very
> well how to manipulate XML data and assemble smart pipelines.
Yes, It must be automatic. :-)
>
> Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Ugo Cei wrote:
> 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
>
>
> I'm wondering how writing *very* simple Java code (mostly classes with
> a handful of private data fields with getters and setters, and even
> this step can largely be automated using Hibernate), is worse than
> writing SQL code, forever tieing your presentation layer to the
> implementation of your storage layer.
Read my answer to Oliver. Note that I'm not trying to push bad software
engineering practices, as I've been advocating separation of domains for
a very, very long time. I'm just reporting what I've seen several times.
Cocoon allows to "forget" the underlying Java code by the power of its
architecture and the available components. And sometimes it hurts when
you have to go back to "raw" Java code for something as simple as
populating a few values in a DB.
An important point to notice also, is that Cocoon can be used
efficiently by people that have a very low Java knowledge but know very
well how to manipulate XML data and assemble smart pipelines.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Ugo Cei <u....@cbim.it>.
Jakob Praher wrote:
> In my experience, using a simple Bean Object as the form model and then
> using this model to fill in a DataObject is the better approach than
> direct binding the data object to the form, as you can't always do a 1:1
> mapping between all the fields.
This is a good point. In my application, I could directly use the
DataObject most of the times, but in a few cases I had to wrap it in a
"helper" object. Case in point: in a user registration form, you have to
enter the password twice, but your data object is going to have just one
password attribute and it's probably encrypted.
Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
I've been happily using Castor XML for a few years now.
Castor JDO has never been considered too much of a choice for large
projects,
but now as you say that the community is rallying around again, I will take
a peek.
-=Ivelin=-
----- Original Message -----
From: "Jakob Praher" <jp...@yahoo.de>
To: <co...@xml.apache.org>
Sent: Sunday, February 16, 2003 7:06 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?
> hi all,
>
> Am Son, 2003-02-16 um 10.32 schrieb Ugo Cei:
> > ivelin wrote:
> > > Ugo, can you can share experience with Hibernate vs. Jakarta OJB,
Cayenne
> > > or another Open Source O/R tool.
> > >
> > > There is a reasonably objective comparison here
> > > http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
> > > but I would like to hear more from a usability, flexibility and
performance
> > > perspective.
> >
>
> I am working with Castor/JDO which is insofar good, as it can be easily
> integreated with javax.transaction environemnts.
>
> Querying is done using a subset of ODMG OQL.
> I have used it in a number of projects sofar.
> I have also done a kind of xpath to oql mapping, for efficient xml
> extraction via the cocoon:/ protocol.
>
> Minor issue is for instance some extra overhead for wrapping the result
> in java.util.Collection classes.
>
> I think the community is reestablishing, since they have done 2 minor
> releases already this year - which I think looks promising.
>
> You can also use the xml package to do marshal the object to xml, but
> care must be taken, as it currently uses SAX1 (DocumentHandler), which
> must be wrapped with the namespace feature turned on.
>
> Also check out the xdoclet tags (which I have modified a little bit for
> my purpose) for castor, which are handy for mapping generation.
>
> In my experience, using a simple Bean Object as the form model and then
> using this model to fill in a DataObject is the better approach than
> direct binding the data object to the form, as you can't always do a 1:1
> mapping between all the fields.
>
>
> just my 2 cents
>
> -- Jakob
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Jakob Praher <jp...@yahoo.de>.
hi all,
Am Son, 2003-02-16 um 10.32 schrieb Ugo Cei:
> ivelin wrote:
> > Ugo, can you can share experience with Hibernate vs. Jakarta OJB, Cayenne
> > or another Open Source O/R tool.
> >
> > There is a reasonably objective comparison here
> > http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
> > but I would like to hear more from a usability, flexibility and performance
> > perspective.
>
I am working with Castor/JDO which is insofar good, as it can be easily
integreated with javax.transaction environemnts.
Querying is done using a subset of ODMG OQL.
I have used it in a number of projects sofar.
I have also done a kind of xpath to oql mapping, for efficient xml
extraction via the cocoon:/ protocol.
Minor issue is for instance some extra overhead for wrapping the result
in java.util.Collection classes.
I think the community is reestablishing, since they have done 2 minor
releases already this year - which I think looks promising.
You can also use the xml package to do marshal the object to xml, but
care must be taken, as it currently uses SAX1 (DocumentHandler), which
must be wrapped with the namespace feature turned on.
Also check out the xdoclet tags (which I have modified a little bit for
my purpose) for castor, which are handy for mapping generation.
In my experience, using a simple Bean Object as the form model and then
using this model to fill in a DataObject is the better approach than
direct binding the data object to the form, as you can't always do a 1:1
mapping between all the fields.
just my 2 cents
-- Jakob
> I cannot really do a comparison here. Hibernate is the first O/R mapping
> tool I've used (after a few home-made attempts) and I haven't tried
> either OJB or Cayenne or anything else.
>
> Apart from what I've already said, I like Hibernate also because:
>
> 1. It follows the principles outlined in Scott Ambler's papers ([1] and
> [2]), which I heppen to mostly agree with.
> 2. It has a lively community behind itself and is being very actively
> developed.
>
> I think usability is great and is immensely helped by good docs. I
> cannot comment much on flexibility, I have just one application
> developed with Hibernate and it was designed in a top-down fashion (i.e.
> design your ojbects first, than derive the DB structure from them),
> which is IMHO the best, if you can afford to get DBAs to do what you ask
> ;-). But Hibernate purports to support all styles of design (top-down,
> bottom-up, middle-out, meet-in-the-middle, see [3]), so flexibility
> should be guaranteed.
>
> With respect to performance, I haven't any data and in my application we
> haven't done any benchmarking or optimization yet. I have the feeling
> that it is executing a little too many queries behind the scenes, but
> that by tweaking Hibernate's settings (eager vs. lazy loading, caching)
> we could get very good performance without mucking with the code.
>
> Biggest problem so far (mostly with some of my co-workers, who have a
> good SQL background) is that sometimes you get a feeling of loss of
> control. Not being able to control what SQL statements you application
> is executing can be intimitading to some. Not to me, I always loathed
> SQL ;-), but sometimes, when the thing does not work as you expect it to
> (and most of the times this is due to your misreading of the docs), you
> wonder whether the Law of Leaky Abstractions [4] is going to apply.
>
> Ugo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
Thanks for the comments.
I will read up some more and decide whether it may work for a huge
meet-in-the-middle project.
-=Ivelin=-
----- Original Message -----
From: "Ugo Cei" <u....@cbim.it>
To: <co...@xml.apache.org>
Sent: Sunday, February 16, 2003 3:32 AM
Subject: Re: extending XMLForms for different kinds of models...opinions?
> ivelin wrote:
> > Ugo, can you can share experience with Hibernate vs. Jakarta OJB,
Cayenne
> > or another Open Source O/R tool.
> >
> > There is a reasonably objective comparison here
> > http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
> > but I would like to hear more from a usability, flexibility and
performance
> > perspective.
>
> I cannot really do a comparison here. Hibernate is the first O/R mapping
> tool I've used (after a few home-made attempts) and I haven't tried
> either OJB or Cayenne or anything else.
>
> Apart from what I've already said, I like Hibernate also because:
>
> 1. It follows the principles outlined in Scott Ambler's papers ([1] and
> [2]), which I heppen to mostly agree with.
> 2. It has a lively community behind itself and is being very actively
> developed.
>
> I think usability is great and is immensely helped by good docs. I
> cannot comment much on flexibility, I have just one application
> developed with Hibernate and it was designed in a top-down fashion (i.e.
> design your ojbects first, than derive the DB structure from them),
> which is IMHO the best, if you can afford to get DBAs to do what you ask
> ;-). But Hibernate purports to support all styles of design (top-down,
> bottom-up, middle-out, meet-in-the-middle, see [3]), so flexibility
> should be guaranteed.
>
> With respect to performance, I haven't any data and in my application we
> haven't done any benchmarking or optimization yet. I have the feeling
> that it is executing a little too many queries behind the scenes, but
> that by tweaking Hibernate's settings (eager vs. lazy loading, caching)
> we could get very good performance without mucking with the code.
>
> Biggest problem so far (mostly with some of my co-workers, who have a
> good SQL background) is that sometimes you get a feeling of loss of
> control. Not being able to control what SQL statements you application
> is executing can be intimitading to some. Not to me, I always loathed
> SQL ;-), but sometimes, when the thing does not work as you expect it to
> (and most of the times this is due to your misreading of the docs), you
> wonder whether the Law of Leaky Abstractions [4] is going to apply.
>
> Ugo
>
> --
> Ugo Cei - http://www.beblogging.com/blog/
>
> [1]: http://www.ambysoft.com/mappingObjects.html
> [2]: http://www.agiledata.org/essays/mappingObjects.html
> [3]: http://www.rollerweblogger.org/page/roller/20021013
> [4]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Ugo Cei <u....@cbim.it>.
ivelin wrote:
> Ugo, can you can share experience with Hibernate vs. Jakarta OJB, Cayenne
> or another Open Source O/R tool.
>
> There is a reasonably objective comparison here
> http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
> but I would like to hear more from a usability, flexibility and performance
> perspective.
I cannot really do a comparison here. Hibernate is the first O/R mapping
tool I've used (after a few home-made attempts) and I haven't tried
either OJB or Cayenne or anything else.
Apart from what I've already said, I like Hibernate also because:
1. It follows the principles outlined in Scott Ambler's papers ([1] and
[2]), which I heppen to mostly agree with.
2. It has a lively community behind itself and is being very actively
developed.
I think usability is great and is immensely helped by good docs. I
cannot comment much on flexibility, I have just one application
developed with Hibernate and it was designed in a top-down fashion (i.e.
design your ojbects first, than derive the DB structure from them),
which is IMHO the best, if you can afford to get DBAs to do what you ask
;-). But Hibernate purports to support all styles of design (top-down,
bottom-up, middle-out, meet-in-the-middle, see [3]), so flexibility
should be guaranteed.
With respect to performance, I haven't any data and in my application we
haven't done any benchmarking or optimization yet. I have the feeling
that it is executing a little too many queries behind the scenes, but
that by tweaking Hibernate's settings (eager vs. lazy loading, caching)
we could get very good performance without mucking with the code.
Biggest problem so far (mostly with some of my co-workers, who have a
good SQL background) is that sometimes you get a feeling of loss of
control. Not being able to control what SQL statements you application
is executing can be intimitading to some. Not to me, I always loathed
SQL ;-), but sometimes, when the thing does not work as you expect it to
(and most of the times this is due to your misreading of the docs), you
wonder whether the Law of Leaky Abstractions [4] is going to apply.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
[1]: http://www.ambysoft.com/mappingObjects.html
[2]: http://www.agiledata.org/essays/mappingObjects.html
[3]: http://www.rollerweblogger.org/page/roller/20021013
[4]: http://www.joelonsoftware.com/articles/LeakyAbstractions.html
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by ivelin <iv...@apache.org>.
Ugo, can you can share experience with Hibernate vs. Jakarta OJB, Cayenne
or another Open Source O/R tool.
There is a reasonably objective comparison here
http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
but I would like to hear more from a usability, flexibility and performance
perspective.
-=Ivelin=-
----- Original Message -----
From: "Ugo Cei" <u....@cbim.it>
To: <co...@xml.apache.org>
Sent: Saturday, February 15, 2003 2:41 PM
Subject: Re: extending XMLForms for different kinds of models...opinions?
> 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
>
> I'm wondering how writing *very* simple Java code (mostly classes with a
> handful of private data fields with getters and setters, and even this
> step can largely be automated using Hibernate), is worse than writing
> SQL code, forever tieing your presentation layer to the implementation
> of your storage layer.
>
> I've been using Hibernate for about a month in a business application
> and have concluded what follows:
>
> a) Hibernate is a great product, rock solid and very well documented
> b) using Java Beans as the Model in MVC beats writing SQL DML statements
> hands down
> c) using an object cache, connection and statement pooling, and
> fine-tuning your loading policies (eager vs. lazy) could give a big
> performance boost to any web application (and no, I haven't any
> benchmarks about this, it's just a gut feeling).
>
> Only "problem" with Hibernate so far: it's LGPL. But you can always go
> with Jakarta OJB if you're picky about licenses.
>
> Ugo
>
> --
> Ugo Cei - http://www.beblogging.com/blog/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Ugo Cei <u....@cbim.it>.
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
I'm wondering how writing *very* simple Java code (mostly classes with a
handful of private data fields with getters and setters, and even this
step can largely be automated using Hibernate), is worse than writing
SQL code, forever tieing your presentation layer to the implementation
of your storage layer.
I've been using Hibernate for about a month in a business application
and have concluded what follows:
a) Hibernate is a great product, rock solid and very well documented
b) using Java Beans as the Model in MVC beats writing SQL DML statements
hands down
c) using an object cache, connection and statement pooling, and
fine-tuning your loading policies (eager vs. lazy) could give a big
performance boost to any web application (and no, I haven't any
benchmarks about this, it's just a gut feeling).
Only "problem" with Hibernate so far: it's LGPL. But you can always go
with Jakarta OJB if you're picky about licenses.
Ugo
--
Ugo Cei - http://www.beblogging.com/blog/
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Bernhard Huber wrote:
>> <snip/>
>> Mmmmh. I think the SourceResolver should be _one_ of the possible
>> models, and not the default one if something else than "java" is
>> used. What would be a real killer feature is a SQL model : no more
>> java coding to edit/update your database from XMLForm (I must say
>> having to write extensive JavaBean code refrained me to use it up to
>> now).
>
>
>
> tought about using hibernate, or castor for that kind of stuff.
> having a java object bean storing and retriving it via some kind of
> O/R tools was my idea.
> bernhard
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
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Bernhard Huber <be...@a1.net>.
> <snip/>
> Mmmmh. I think the SourceResolver should be _one_ of the possible
> models, and not the default one if something else than "java" is used.
> What would be a real killer feature is a SQL model : no more java
> coding to edit/update your database from XMLForm (I must say having to
> write extensive JavaBean code refrained me to use it up to now).
tought about using hibernate, or castor for that kind of stuff.
having a java object bean storing and retriving it via some kind of O/R
tools was my idea.
bernhard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 17.Feb.2003 -- 11:11 AM, Sylvain Wallez wrote:
>
>
>>Wow, looks cool, but the "configuration road" starts looking like a
>>"configurration maze"...
>>
>>
>
>Well, yes :-(
>
>But if there is enough interest, the actions could receive support for
>passing the form id dynamically so that steps b) and c) would not be
>needed anymore. E.g. I'm thinking about passing a prefix and modifying
>the xmlform module so that the form id is the root of the path -> /4711/table/name
>and
>
> <map:act type="db-add">
> <map:parameter name="prefix" value="4711"/>
> <map:act>
>
>That would allow referencing form values from anywhere like
>
> <map:transform type="xslt" src="skins/{xmlform:/4711/skin}.xsl"/>
>
>as well :-)
>
>
Wow, looks cool again ! But all this is a little bit dark to me. I
definitely have to dig there, as there's a lot of cool stuff that I
don't know about...
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 17.Feb.2003 -- 11:11 AM, Sylvain Wallez wrote:
> Wow, looks cool, but the "configuration road" starts looking like a
> "configurration maze"...
Well, yes :-(
But if there is enough interest, the actions could receive support for
passing the form id dynamically so that steps b) and c) would not be
needed anymore. E.g. I'm thinking about passing a prefix and modifying
the xmlform module so that the form id is the root of the path -> /4711/table/name
and
<map:act type="db-add">
<map:parameter name="prefix" value="4711"/>
<map:act>
That would allow referencing form values from anywhere like
<map:transform type="xslt" src="skins/{xmlform:/4711/skin}.xsl"/>
as well :-)
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 15.Feb.2003 -- 07:02 PM, Sylvain Wallez wrote:
>
>
>>What would be a real killer feature is a SQL model : no more java coding
>>to edit/update your database from XMLForm (I must say having to write
>>extensive JavaBean code refrained me to use it up to now).
>>
>>
>
>I believe both operation models are valid. If you want to go down the
>configuration road, there is something you might want to try with
>recent snapshots:
>
>a) use the xmlform approach from Josema and use a DOM as your form model
>b) add for every xmlform id a new input module, say for form id "4711":
>
> <component-instance logger="core.modules.input" name="xmlform-4711"
> class="org.apache.cocoon.components.modules.input.XMLFormModule">
> <xmlform-id>4711</xmlform-id>
> </component-instance>
>
>c) modify your database action configuration, add:
> <path-separator>/</path-separator>
> <input>xmlform-4711</input>
>
>Now, all you need is that your form model corresponds (i.e. is a super
>set) to the database model: The database action will look up values
>now as "table/value" (instead of "table.value") from the xmlform with
>id 4711.
>
>Steps b) and c) are only required if one doesn't want to write <mode/>
>elements into the database.xml.
>
>Note that I have not tested this but it should work in theory.
>
>
Wow, looks cool, but the "configuration road" starts looking like a
"configurration maze"...
Anyway, thanks for the hint !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 15.Feb.2003 -- 07:02 PM, Sylvain Wallez wrote:
> What would be a real killer feature is a SQL model : no more java coding
> to edit/update your database from XMLForm (I must say having to write
> extensive JavaBean code refrained me to use it up to now).
I believe both operation models are valid. If you want to go down the
configuration road, there is something you might want to try with
recent snapshots:
a) use the xmlform approach from Josema and use a DOM as your form model
b) add for every xmlform id a new input module, say for form id "4711":
<component-instance logger="core.modules.input" name="xmlform-4711"
class="org.apache.cocoon.components.modules.input.XMLFormModule">
<xmlform-id>4711</xmlform-id>
</component-instance>
c) modify your database action configuration, add:
<path-separator>/</path-separator>
<input>xmlform-4711</input>
Now, all you need is that your form model corresponds (i.e. is a super
set) to the database model: The database action will look up values
now as "table/value" (instead of "table.value") from the xmlform with
id 4711.
Steps b) and c) are only required if one doesn't want to write <mode/>
elements into the database.xml.
Note that I have not tested this but it should work in theory.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: extending XMLForms for different kinds of models...opinions?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
ivelin wrote:
>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.
>
<snip-other-examples/>
Mmmmh. I think the SourceResolver should be _one_ of the possible
models, and not the default one if something else than "java" is used.
What would be a real killer feature is a SQL model : no more java coding
to edit/update your database from XMLForm (I must say having to write
extensive JavaBean code refrained me to use it up to now).
Also, doesn't this "XMLForm model" concept match the Input and
OutputModules ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org