You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marcin Okraszewski <ok...@o2.pl> on 2004/02/01 20:13:43 UTC
An idea - transformer logicsheets.
Hi,
As I wrote my post with subject "Which XSLT is used for XSP
logicsheets???" to the users group I got an idea about XSP
transformation to Java.
Why logicsheets are only XSLT ??? Why don't we use the concept of
transformers from Cocoon? That would be very useful in some cases!!
Regards,
Marcin Okraszewski
Re: An idea - transformer logicsheets.
Posted by Antonio Gallardo <ag...@agssa.net>.
Steve Krulewitz dijo:
> Stefano Mazzocchi wrote:
>> We are slowly deprecating server pages in favor of more MVC+ approaches
>> (that is: flows control + business objects + view templates)
>>
>> In Cocoon 2.2, XSP will probably move to their own block and removed
>> from the core (this means they will still be supported, but not
>> considered core technology and not advocated as "the way").
>
> I still find the esql taglib to be a very useful and easy way to go from
> SQL query to an XML document. If xsp is deprecated, the only other
> way to easily do this is the SQLTransformer, but it is lacking many of
> the features that the esql taglib has.
Yep. ESQL is the best thing in XSP. In my own experience, ESQL is good for
very small DB webapp. When you are beyond small webapp, the ESQL code
start to be complex and some features are really complex or dificult to
solve. We have some XSP pages with ESQL that currently we would don't want
to review or change because of the complexity. We made applications of
both types (original and modular DB actions + ESQL using XSP).
Please note, I am talking based on my own experience. It is not the
official position of Apache Cocoon:
This is why we started to find another way to interact with DB in Cocoon.
While we tried to find a better solution, we noted the efforts in Flow and
Woody development. We started to follow Flow in the list early last year
and then in the mid of the last year Woody comes to scene. The combination
of both gives us the idea it would fill the Controller (Flow) and the View
(Woody) of MVC. Then of course the gap was on the Model. What to use on
the Model? Well, some people recommended Hibernate and OJB. After
reviewing both of them we choosed OJB, because it was easier to us and is
Apache licensed that means the integration with Cocoon will be easier.
To me OJB is the succesor of ESQL. We are currently developing 2
applications with OJB+(Woody+JXTemplate)+Flow (MVC) and we are very happy
with the results. It is really amazing, finally we can talk seriously
about a true SoC.
Our current development of the model for us is:
1-Design the DB using Druid - http://druid.sf.net
2-Generate with Druid: SQL script schema, Java JDO Beans, OJB O/RMap and
HTML documentation of the Database. Build a JAR file with JDO Beans.
3-Build some handler in Java for Woody forms. This handlers allow mainly
the basic operations with database by manipulating the Java Beans.
Step 1 is as fast as you can model your database in a graphical interface.
It is really very easy. Druid can generate scripts for many DB including
PostgreSQL, MySQL, generic SQL, Oracle, and others.
Step 2 takes maybe 5 minuts or less! :-D
Step 3 takes a little more. We are trying to find some commons aspects to
find a way that allow some kind of automatization of these step. The main
problem here is because the Handlers manipulates the beans that Woody show
to the user. In that sense every Handler directly depends on the Woody
forms or in the results we need to show in a JXTemplate.
We are thinking in this issue while we are currently programming this step
by hand. Anyway this is far more manageable than the XSP approach. I think
in the archives are mails of the steps we did while we tried to find the
current approach.
> Maybe adding support for iterating through ResultSets in a JXTemplate
> might make this easier to do from flow? Or is this already possible?
Hmm..., but the problem is that AFAIK, JXTemplate is part of the View in
MVC. This is why I am not sure if it would be a good idea to insert DB
support at JXTemplate level.
Best Regards,
Antonio Gallardo
Re: USQL [was: Future of XSP and ESQL]
Posted by Torsten Curdt <tc...@vafer.org>.
>>First, let's collect what we like about the two components
>
>
> It would be very cool if we could provide something that helps with flow
> applications.
> I like the combination of OR-Mapping/CForms/Flow but this
> is for many beginners overkill. They shouldn't be forced to write Java
> code e.g. in order to implement a simple register form.
...I see no reason why you could not use a possible
new USQL for easy flow stuff.
But first we need to find out what we like about
one or the other.
Why do *you* e.g. use ESQL rather the SQLTransformer
or the other way round? Or why do *you* use the
DatabaseActions...
Things like that
--
Torsten
RE: XML-Relational Mapping (Was: USQL)
Posted by Reinhard Poetz <re...@apache.org>.
From: Daniel Fagerstrom
> Brian McCallister wrote:
>
> > it seems to me the embedded Xindice option should work pretty
> > painlessly for most simple persistence needs. If it is hard to use,
> > the better option may be to look at how to make it easier
> to use. If
> > an XML -> rdmbs automapper and schema generator is needed
> it seems a
> > lot like reinventing a new backend for an xml database.
> >
> > -Brian
>
> I agree, for many persistance needs an XML db, or even
> storing XML files
> in the file system is the best alternative.
>
> For the projects I work in however, and I think this
> situation is rather
> common, we already have a lot of customer data from other
> data sources
> in a relational data base. And we need to combine this data with user
> input data in different ways. In this kind of context the
> easiest way is
> to store the user input in the db as well and using SQL to
> combine data.
Yes, I agree with this.
And many companies only have one database system and all applications
*have to* use it as backend layer.
--
Reinhard
Re: XML-Relational Mapping (Was: USQL)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Brian McCallister wrote:
> it seems to me the embedded Xindice option should work pretty
> painlessly for most simple persistence needs. If it is hard to use,
> the better option may be to look at how to make it easier to use. If
> an XML -> rdmbs automapper and schema generator is needed it seems a
> lot like reinventing a new backend for an xml database.
>
> -Brian
I agree, for many persistance needs an XML db, or even storing XML files
in the file system is the best alternative.
For the projects I work in however, and I think this situation is rather
common, we already have a lot of customer data from other data sources
in a relational data base. And we need to combine this data with user
input data in different ways. In this kind of context the easiest way is
to store the user input in the db as well and using SQL to combine data.
/Daniel
Re: XML-Relational Mapping (Was: USQL)
Posted by Brian McCallister <mc...@forthillcompany.com>.
it seems to me the embedded Xindice option should work pretty
painlessly for most simple persistence needs. If it is hard to use, the
better option may be to look at how to make it easier to use. If an XML
-> rdmbs automapper and schema generator is needed it seems a lot like
reinventing a new backend for an xml database.
-Brian
On Feb 24, 2004, at 10:21 PM, roy huang wrote:
> It sounds good.I think many application just use very simple
> database,I saw application just use one or two table for data storage
> only.
> If we(beginners ;)) can just using mapping to combine xml and database
> for select/add/update/delete,life is much easier with cocoon.
> +1
>
> Roy Huang
> ----- Original Message -----
> From: "Daniel Fagerstrom" <da...@nada.kth.se>
> To: <de...@cocoon.apache.org>
> Sent: Tuesday, February 24, 2004 9:06 PM
> Subject: XML-Relational Mapping (Was: USQL)
>
>
>> Reinhard Poetz wrote:
>> ...
>>
>>> It would be very cool if we could provide something that helps with
>>> flow
>>> applications. I like the combination of OR-Mapping/CForms/Flow but
>>> this
>>> is for many beginners overkill. They shouldn't be forced to write
>>> Java
>>> code e.g. in order to implement a simple register form.
>>>
>>> --
>>> Reinhard
>>>
>> I think it is overkill for many non beginners as well ;)
>>
>> I am currently looking at XML-DBMS 2.0,
>> http://www.rpbourret.com/xmldbms/index.htm, which is an XML/relational
>> mapping tool. The main idea is that you describe the mapping between
>> XML
>> and the relational db in a mapping file, then you can use the mapping
>> tool to both store the XML document in the db and retrive XML from the
>> db. The detailed storing strategy - using overwrite or update etc can
>> be
>> fine tuned in another configuration file. And the retrieving behaviour
>> can fine tuned with a filter file.
>>
>> XML-DBMS is intended for data centric rather than document centric
>> applications and provide a rather flexible mapping between one XML
>> document and a number of tables. It also contains a tool for
>> generating
>> maping files from DTD:s and, IIUC, from db meta data. It can also
>> generate create table statements from the maping file.
>>
>> I think XML_DBMS look rather promissing, and I have not found any
>> other
>> packages that dom direct XML relational mapping, all other seem to
>> require Java objects in the middle. Anyone that know about any
>> simmilar
>> packages?
>>
>> Possible drawbacks are that the community is very small, and that the
>> packaging is not that good: no ant script. The documentation is good
>> however, Ronald Bourret, the main author have written a number of
>> articles about XML mappings.
>>
>> The licence is: "XML-DBMS, along with its source code, is freely
>> available for use in both commercial and non-commercial settings. It
>> is
>> not copyrighted and has *absolutely no warranty*. Use it as you will."
>>
>> Given that XML-DBMS holds what it promise, I will try to build an
>> block
>> around it. My idea is to use XML-DBMS from flowscripts, so the best
>> way
>> to integrate it would probably be to write some component, like
>> pipelineUtil around XML-DBMS. An SQLToXMLTransformer
>> XMLToSQLTransformer
>> pair would also be a possibility.
>>
>> Others interested in such a block? Opinions?
>>
>> /Daniel
>>
>>
Re: XML-Relational Mapping (Was: USQL)
Posted by roy huang <li...@hotmail.com>.
It sounds good.I think many application just use very simple database,I saw application just use one or two table for data storage only.
If we(beginners ;)) can just using mapping to combine xml and database for select/add/update/delete,life is much easier with cocoon.
+1
Roy Huang
----- Original Message -----
From: "Daniel Fagerstrom" <da...@nada.kth.se>
To: <de...@cocoon.apache.org>
Sent: Tuesday, February 24, 2004 9:06 PM
Subject: XML-Relational Mapping (Was: USQL)
> Reinhard Poetz wrote:
> ...
>
> >It would be very cool if we could provide something that helps with flow
> >applications. I like the combination of OR-Mapping/CForms/Flow but this
> >is for many beginners overkill. They shouldn't be forced to write Java
> >code e.g. in order to implement a simple register form.
> >
> >--
> >Reinhard
> >
> I think it is overkill for many non beginners as well ;)
>
> I am currently looking at XML-DBMS 2.0,
> http://www.rpbourret.com/xmldbms/index.htm, which is an XML/relational
> mapping tool. The main idea is that you describe the mapping between XML
> and the relational db in a mapping file, then you can use the mapping
> tool to both store the XML document in the db and retrive XML from the
> db. The detailed storing strategy - using overwrite or update etc can be
> fine tuned in another configuration file. And the retrieving behaviour
> can fine tuned with a filter file.
>
> XML-DBMS is intended for data centric rather than document centric
> applications and provide a rather flexible mapping between one XML
> document and a number of tables. It also contains a tool for generating
> maping files from DTD:s and, IIUC, from db meta data. It can also
> generate create table statements from the maping file.
>
> I think XML_DBMS look rather promissing, and I have not found any other
> packages that dom direct XML relational mapping, all other seem to
> require Java objects in the middle. Anyone that know about any simmilar
> packages?
>
> Possible drawbacks are that the community is very small, and that the
> packaging is not that good: no ant script. The documentation is good
> however, Ronald Bourret, the main author have written a number of
> articles about XML mappings.
>
> The licence is: "XML-DBMS, along with its source code, is freely
> available for use in both commercial and non-commercial settings. It is
> not copyrighted and has *absolutely no warranty*. Use it as you will."
>
> Given that XML-DBMS holds what it promise, I will try to build an block
> around it. My idea is to use XML-DBMS from flowscripts, so the best way
> to integrate it would probably be to write some component, like
> pipelineUtil around XML-DBMS. An SQLToXMLTransformer XMLToSQLTransformer
> pair would also be a possibility.
>
> Others interested in such a block? Opinions?
>
> /Daniel
>
>
>
RE: XML-Relational Mapping (Was: USQL)
Posted by Reinhard Poetz <re...@apache.org>.
From: Daniel Fagerstrom
> Reinhard Poetz wrote:
> ...
>
> >It would be very cool if we could provide something that helps with
> >flow applications. I like the combination of
> OR-Mapping/CForms/Flow but
> >this is for many beginners overkill. They shouldn't be
> forced to write
> >Java code e.g. in order to implement a simple register form.
> >
> >--
> >Reinhard
> >
> I think it is overkill for many non beginners as well ;)
>
> I am currently looking at XML-DBMS 2.0,
> http://www.rpbourret.com/xmldbms/index.htm, which is an
> XML/relational
> mapping tool. The main idea is that you describe the mapping
> between XML
> and the relational db in a mapping file, then you can use the mapping
> tool to both store the XML document in the db and retrive XML
> from the
> db. The detailed storing strategy - using overwrite or update
> etc can be
> fine tuned in another configuration file. And the retrieving
> behaviour
> can fine tuned with a filter file.
>
> XML-DBMS is intended for data centric rather than document centric
> applications and provide a rather flexible mapping between one XML
> document and a number of tables. It also contains a tool for
> generating
> maping files from DTD:s and, IIUC, from db meta data. It can also
> generate create table statements from the maping file.
>
> I think XML_DBMS look rather promissing, and I have not found
> any other
> packages that dom direct XML relational mapping, all other seem to
> require Java objects in the middle. Anyone that know about
> any simmilar
> packages?
>
> Possible drawbacks are that the community is very small, and that the
> packaging is not that good: no ant script. The documentation is good
> however, Ronald Bourret, the main author have written a number of
> articles about XML mappings.
>
> The licence is: "XML-DBMS, along with its source code, is freely
> available for use in both commercial and non-commercial
> settings. It is
> not copyrighted and has *absolutely no warranty*. Use it as you will."
>
> Given that XML-DBMS holds what it promise, I will try to
> build an block
> around it. My idea is to use XML-DBMS from flowscripts, so
> the best way
> to integrate it would probably be to write some component, like
> pipelineUtil around XML-DBMS. An SQLToXMLTransformer
> XMLToSQLTransformer
> pair would also be a possibility.
>
> Others interested in such a block? Opinions?
I'm not sure. Please see my mail "Connecting databases with Cocoon" and
then we should find szenarios where your solutions fit (one example I
can think of is mentioned in this mail).
--
Reinhard
>
> /Daniel
>
XML-Relational Mapping (Was: USQL)
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Reinhard Poetz wrote:
...
>It would be very cool if we could provide something that helps with flow
>applications. I like the combination of OR-Mapping/CForms/Flow but this
>is for many beginners overkill. They shouldn't be forced to write Java
>code e.g. in order to implement a simple register form.
>
>--
>Reinhard
>
I think it is overkill for many non beginners as well ;)
I am currently looking at XML-DBMS 2.0,
http://www.rpbourret.com/xmldbms/index.htm, which is an XML/relational
mapping tool. The main idea is that you describe the mapping between XML
and the relational db in a mapping file, then you can use the mapping
tool to both store the XML document in the db and retrive XML from the
db. The detailed storing strategy - using overwrite or update etc can be
fine tuned in another configuration file. And the retrieving behaviour
can fine tuned with a filter file.
XML-DBMS is intended for data centric rather than document centric
applications and provide a rather flexible mapping between one XML
document and a number of tables. It also contains a tool for generating
maping files from DTD:s and, IIUC, from db meta data. It can also
generate create table statements from the maping file.
I think XML_DBMS look rather promissing, and I have not found any other
packages that dom direct XML relational mapping, all other seem to
require Java objects in the middle. Anyone that know about any simmilar
packages?
Possible drawbacks are that the community is very small, and that the
packaging is not that good: no ant script. The documentation is good
however, Ronald Bourret, the main author have written a number of
articles about XML mappings.
The licence is: "XML-DBMS, along with its source code, is freely
available for use in both commercial and non-commercial settings. It is
not copyrighted and has *absolutely no warranty*. Use it as you will."
Given that XML-DBMS holds what it promise, I will try to build an block
around it. My idea is to use XML-DBMS from flowscripts, so the best way
to integrate it would probably be to write some component, like
pipelineUtil around XML-DBMS. An SQLToXMLTransformer XMLToSQLTransformer
pair would also be a possibility.
Others interested in such a block? Opinions?
/Daniel
RE: USQL [was: Future of XSP and ESQL]
Posted by Reinhard Poetz <re...@apache.org>.
> -----Original Message-----
> From: Torsten Curdt [mailto:tcurdt@vafer.org]
> Sent: Tuesday, February 24, 2004 12:52 AM
> To: dev@cocoon.apache.org
> Subject: USQL [was: Future of XSP and ESQL]
>
>
> <snip/>
>
> >> My idea is to come up with an unified syntax. Taking the
> best out of
> >> the SQLTransformer and the ESQL logicsheet. Then come up
> with an ESQL
> >> transformer and a logicsheet using the same code base (as much as
> >> possible). For an easy migration we could provide an ant task that
> >> applies a migration stylesheet.
> >>
> >> I just hope it's worth the effort since everyone
> >> seems to be going the OJB way...
> >>
> >> We could start a wiki page to collect the best
> >> out of both world and come up with the new syntax...
> >>
> >> WDYT?
> >
> >
> > Sounds like a good plan to me.
>
> I like to invite everyone to start the discussion for a
> unified version of ESQL and the SQLTransformer
>
>
http://wiki.cocoondev.org/Wiki.jsp?page=UnifiedSQLTransformerAndLogicshe
et
>
> First, let's collect what we like about the two components
It would be very cool if we could provide something that helps with flow
applications. I like the combination of OR-Mapping/CForms/Flow but this
is for many beginners overkill. They shouldn't be forced to write Java
code e.g. in order to implement a simple register form.
--
Reinhard
USQL [was: Future of XSP and ESQL]
Posted by Torsten Curdt <tc...@vafer.org>.
<snip/>
>> My idea is to come up with an unified syntax. Taking the
>> best out of the SQLTransformer and the ESQL logicsheet.
>> Then come up with an ESQL transformer and a logicsheet
>> using the same code base (as much as possible). For
>> an easy migration we could provide an ant task that
>> applies a migration stylesheet.
>>
>> I just hope it's worth the effort since everyone
>> seems to be going the OJB way...
>>
>> We could start a wiki page to collect the best
>> out of both world and come up with the new syntax...
>>
>> WDYT?
>
>
> Sounds like a good plan to me.
I like to invite everyone to start the discussion for a
unified version of ESQL and the SQLTransformer
http://wiki.cocoondev.org/Wiki.jsp?page=UnifiedSQLTransformerAndLogicsheet
First, let's collect what we like about the two components
cheers
--
Torsten
Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 2 Feb 2004, at 04:37, Torsten Curdt wrote:
>>> But not being the database guy around here, I'm not the one to talk
>>> about these things so I'll be glad if somebody else wants to come
>>> forward.
>>>
>>> One thing is for sure: XSP is showing its age and we should move
>>> forward... but without loosing its value.
>>
>> Why not pull the ESQL stuff out and provide a stripped down
>> ESQLTransformer?
>
> Something like that sits on my TODO list for ages now.
> Rrrr! *itch* As soon as I have some spare time... (please
> don't laugh)
>
> Be sure we won't simply deprecate ESQL!
>
> My idea is to come up with an unified syntax. Taking the
> best out of the SQLTransformer and the ESQL logicsheet.
> Then come up with an ESQL transformer and a logicsheet
> using the same code base (as much as possible). For
> an easy migration we could provide an ant task that
> applies a migration stylesheet.
>
> I just hope it's worth the effort since everyone
> seems to be going the OJB way...
>
> We could start a wiki page to collect the best
> out of both world and come up with the new syntax...
>
> WDYT?
Sounds like a good plan to me.
I personally don't think that we should mandate the use of OJB (or any
object-relational tool) instead of pipeline SQL expansion because they
are used (and useful) in very different contexts.
I think that for pure publishing and where data interaction is low,
pipeline SQL expansion makes still perfect sense and I think this
covers up to 50% of all database-driven web sites.
But we need to inform our users of the risk of getting stuck with a
paradigm that doesn't scale for massive and complex business logic and
flow control. That's where flow + cforms + object-relational shines.
Of course, if we could wikify the two approaches with some sort of
examples, it would be delightful.
Sort of "suggested practices in using a relational database with
cocoon" guide.
--
Stefano.
Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le Lundi, 2 fév 2004, à 11:45 Europe/Zurich, Guido Casper a écrit :
> Torsten Curdt wrote:
>
>> ...I just hope it's worth the effort since everyone
>> seems to be going the OJB way...
>
> It _is_ worth it IMHO since there is more to databases (like reporting
> applications) than persisting Java objects (otherwise we all would
> probably be using object databases) and there are use cases where
> collecting data within the "view layer" makes great sense.
+1, there are many publishing applications which use fairly simple
read-only SQL queries and for which anything more than direct SQL is
overkill.
Merging the SQL Transformer and ESQL into something more "modern" is
certainly worth the effort!
-Bertrand
Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Guido Casper <gc...@s-und-n.de>.
Torsten Curdt wrote:
> My idea is to come up with an unified syntax. Taking the
> best out of the SQLTransformer and the ESQL logicsheet.
> Then come up with an ESQL transformer and a logicsheet
> using the same code base (as much as possible). For
> an easy migration we could provide an ant task that
> applies a migration stylesheet.
>
> I just hope it's worth the effort since everyone
> seems to be going the OJB way...
It _is_ worth it IMHO since there is more to databases (like reporting
applications) than persisting Java objects (otherwise we all would
probably be using object databases) and there are use cases where
collecting data within the "view layer" makes great sense.
Guido
Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Torsten Curdt <tc...@vafer.org>.
>> But not being the database guy around here, I'm not the one to talk
>> about these things so I'll be glad if somebody else wants to come
>> forward.
>>
>> One thing is for sure: XSP is showing its age and we should move
>> forward... but without loosing its value.
>
> Why not pull the ESQL stuff out and provide a stripped down
> ESQLTransformer?
Something like that sits on my TODO list for ages now.
Rrrr! *itch* As soon as I have some spare time... (please
don't laugh)
Be sure we won't simply deprecate ESQL!
My idea is to come up with an unified syntax. Taking the
best out of the SQLTransformer and the ESQL logicsheet.
Then come up with an ESQL transformer and a logicsheet
using the same code base (as much as possible). For
an easy migration we could provide an ant task that
applies a migration stylesheet.
I just hope it's worth the effort since everyone
seems to be going the OJB way...
We could start a wiki page to collect the best
out of both world and come up with the new syntax...
WDYT?
--
Torsten
Re: Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Ryan Hoegg <rh...@isisnetworks.net>.
Stefano Mazzocchi wrote:
>
> On 1 Feb 2004, at 19:27, Steve Krulewitz wrote:
>
>> I still find the esql taglib to be a very useful and easy way to go
>> from SQL query to an XML document. If xsp is deprecated, the only
>> other way to easily do this is the SQLTransformer, but it is lacking
>> many of the features that the esql taglib has.
>>
>> Maybe adding support for iterating through ResultSets in a JXTemplate
>> might make this easier to do from flow? Or is this already possible?
>
>
> I think that the ESQL logicsheet is the only really valuable and
> unique thing that we have in XSP, so, yeah, I totally understand your
> concern.
>
> At the same time, I'm more and more convinced that database access
> should happen at the view level, but should be something that should
> happen at the 'control' level.
>
> This also goes hand in hand with the approach of isolating the sql
> statements and wrap them around objects. But I also understand that
> many people out there like SQL and find it really productive and they
> won't move to one database to another, so they see no reason to go the
> extra mile of providing decoupling abstractions for their data model.
>
> Chris introduced some database connection features in flowscript at
> one point, but I still think that's going too far and might yield the
> wrong impression that you should use flowscript for your core business
> logic (and database access should definately be part of that).
>
> At the same time, it strikes me that ESQL was meant to be used with
> the modular database actions and input modules... it streams for a
> unification in some avalon component that can do database and
> resultset manipulation in an easy and predictable way.
>
> But not being the database guy around here, I'm not the one to talk
> about these things so I'll be glad if somebody else wants to come
> forward.
>
> One thing is for sure: XSP is showing its age and we should move
> forward... but without loosing its value.
>
> --
> Stefano.
Why not pull the ESQL stuff out and provide a stripped down ESQLTransformer?
--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/
Future of XSP and ESQL [was Re: An idea - transformer logicsheets.]
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Feb 2004, at 19:27, Steve Krulewitz wrote:
> Stefano Mazzocchi wrote:
>> We are slowly deprecating server pages in favor of more MVC+
>> approaches (that is: flows control + business objects + view
>> templates)
>> In Cocoon 2.2, XSP will probably move to their own block and removed
>> from the core (this means they will still be supported, but not
>> considered core technology and not advocated as "the way").
>
> I still find the esql taglib to be a very useful and easy way to go
> from SQL query to an XML document. If xsp is deprecated, the only
> other way to easily do this is the SQLTransformer, but it is lacking
> many of the features that the esql taglib has.
>
> Maybe adding support for iterating through ResultSets in a JXTemplate
> might make this easier to do from flow? Or is this already possible?
I think that the ESQL logicsheet is the only really valuable and unique
thing that we have in XSP, so, yeah, I totally understand your concern.
At the same time, I'm more and more convinced that database access
should happen at the view level, but should be something that should
happen at the 'control' level.
This also goes hand in hand with the approach of isolating the sql
statements and wrap them around objects. But I also understand that
many people out there like SQL and find it really productive and they
won't move to one database to another, so they see no reason to go the
extra mile of providing decoupling abstractions for their data model.
Chris introduced some database connection features in flowscript at one
point, but I still think that's going too far and might yield the wrong
impression that you should use flowscript for your core business logic
(and database access should definately be part of that).
At the same time, it strikes me that ESQL was meant to be used with the
modular database actions and input modules... it streams for a
unification in some avalon component that can do database and resultset
manipulation in an easy and predictable way.
But not being the database guy around here, I'm not the one to talk
about these things so I'll be glad if somebody else wants to come
forward.
One thing is for sure: XSP is showing its age and we should move
forward... but without loosing its value.
--
Stefano.
Re: An idea - transformer logicsheets.
Posted by Steve Krulewitz <sh...@mm.st>.
Stefano Mazzocchi wrote:
> We are slowly deprecating server pages in favor of more MVC+ approaches
> (that is: flows control + business objects + view templates)
>
> In Cocoon 2.2, XSP will probably move to their own block and removed
> from the core (this means they will still be supported, but not
> considered core technology and not advocated as "the way").
I still find the esql taglib to be a very useful and easy way to go from
SQL query to an XML document. If xsp is deprecated, the only other
way to easily do this is the SQLTransformer, but it is lacking many of
the features that the esql taglib has.
Maybe adding support for iterating through ResultSets in a JXTemplate
might make this easier to do from flow? Or is this already possible?
cheers,
-steve
Re: An idea - transformer logicsheets.
Posted by Antonio Gallardo <ag...@agssa.net>.
Stefano Mazzocchi dijo:
>
> But we are moving away from dynamically generated java code because we
> think this is an anti-pattern: appears very appealing at first, but
> then it turns out to be a painful nightmare for debugging down the
> road.
>
> We are slowly deprecating server pages in favor of more MVC+ approaches
> (that is: flows control + business objects + view templates)
>
> In Cocoon 2.2, XSP will probably move to their own block and removed
> from the core (this means they will still be supported, but not
> considered core technology and not advocated as "the way").
>
> I see no point in investing in making XSP even more complex than what
> they already are.
I am glad, it is nice to finally see a "official" position ;-DDD
+1
Best Regards,
Antonio Gallardo
Re: An idea - transformer logicsheets.
Posted by Stefano Mazzocchi <st...@apache.org>.
On 1 Feb 2004, at 14:13, Marcin Okraszewski wrote:
> Hi,
> As I wrote my post with subject "Which XSLT is used for XSP
> logicsheets???" to the users group I got an idea about XSP
> transformation to Java.
>
> Why logicsheets are only XSLT ??? Why don't we use the concept of
> transformers from Cocoon? That would be very useful in some cases!!
This has been discussed a long time ago but it was concieved as
flexibility syndrome, therefore rejected.
With the introduction of the compiling classloader, we could even have
classes associated with cocoon:// URI and we wouldn't need the concept
of XSP anymore since it would all be transparent, even if you would
have to drive the XSP pipeline yourself and this would be painful for
some given the high number of transforming steps required to go thru
the logicsheet evaluation stages.
But we are moving away from dynamically generated java code because we
think this is an anti-pattern: appears very appealing at first, but
then it turns out to be a painful nightmare for debugging down the
road.
We are slowly deprecating server pages in favor of more MVC+ approaches
(that is: flows control + business objects + view templates)
In Cocoon 2.2, XSP will probably move to their own block and removed
from the core (this means they will still be supported, but not
considered core technology and not advocated as "the way").
I see no point in investing in making XSP even more complex than what
they already are.
--
Stefano.