cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [RT] Protocol based sources eliminates almost every generator [was Re: Showstoppers for 2.0 final was RE: [tale+rant] The 2.0 syndrome and [Vote]: Final Release Date]
Date Mon, 26 Nov 2001 14:51:11 GMT
Quoting Berin Loritsch <bloritsch@apache.org>:

> Ugo Cei wrote:
> 
> > Giacomo Pati wrote:
> > 
> >> This is what I have figured lately when talking with Stefano the
> other 
> >> week. If you look at how many Generators we have you end up with only
> 
> >> two important ones:
> >>
> >>    FileGenerator
> >>    ServerPagesGenerator
> >>
> >> All the other (DirectoryGenerator, RequestGenerator, ...) could be 
> >> easily realized by using XSP. We have put all specific handling of 
> >> various sources into the Source abstration. So each data source you'd
> 
> >> like to access (file:, resource:, context:, cocoon:, ldap:, news:, 
> >> imap:, pop:, xmldb:, etc.) could in fact be realized by a Source.
> > 
> > 
> > I'm beginning to get just a little bit confused. So far I have a
> couple 
> > of Cocoon 2 applications that mostly use XSP with ESQL to query a 
> > database. All is running well, but I don't really like the idea of 
> > having pages that depend on the physical structure of the database. 
> > Thus, I started exploring different alternatives and came up with the 
> > idea of having a library of (possibly reusable) Java objects that 
> > represent entities in the database (via EJB or some O-R mapping tool 
> > like Castor or whatever).
> 
> 
> Here is the danger in the Source based "Generators":
> 
> You are muddying the contracts of what a Generator is SUPPOSED to be.
> Are there some things that are better realized as a Source object? 
> Sure.
> The "file:", "context:", and "resource:" pseudo-protocols are natural
> extensions of the Source framework.  Technically, you could have it
> specially
> adapted so that if it points to a directory, it will generate the XML
> representation of the directory.  I don't have a problem with this.

And this is what I wanted to show.

> I *do* have a problem with making it the end all and be all of creating
> XML.  The Generator's responsibility is to convert an XML based Source
> to SAX events.  The Source is the abstraction of where the Generator
> retrieves the information to convert to XML.

So, you think the cocoon:/ protocol is nothing to be implemented as a Source 
(becaus it produces a SAX stream itself)?

> They have two different contracts, and I think muddying the contracts
> is inherently wrong.  For instance, some are talking about removing the
> necessity of XSP by using specialized "protocols" for their XML objects.

I've never said so. XSP is one of those Generators I see stil necessary.

> Something like "user:" and "cart:" would be an example of going too far.

Agreed.

> These are business object extractions.  There is nothing wrong with
> making
> Components that match the particular XMLizable business object you want
> and serializing it.  However, it should NOT be a Source object.
> 
> 
> > The troubles come when I start thinking about how I might feed a (XML)
> 
> > representation of those objects to Cocoon in order to represent them, 
> > say on a web page. As far as I can see, these are the possible
> choices:
> > 
> > - call my objects from an XSP page, specifying element names in XSP
> and
> >   use <xsp:expr>myObject.getSomeField()</xsp:expr> for the values
> > - like the above, but using a taglib for reusability
> 
> 
> +1--this makes it very simple to use the "object" elsewhere
> 
> 
> > - write a Generator
> 
> 
> This is in effect what you are doing when you use XSP.
> 
> 
> > - make my objects implement XMLizable and override toSAX
> > - write a Transformer
> 
> 
> +1--this means that any type of generator can use those tags--not just
>      XSP pages!
> 
> 
> > - write a Source (this I hadn't even figured until I read Giacomo's
> >   mail)

This is nothing I thought of doing.

> 
> 
> -1--this muddies the contracts and makes to confuse newcomers.
> 
> 
> > I'm really overwhelmed by the spectrum of choices and some guidance 
> > would really be helpful at this time :). What do you developers think?
> 
> 
> 
> Go with simplicity.  In my tutorial (in CVS HEAD) I advocate this
> procedure
> when you have dynamic pages:
> 
> 1) Start with plain XSP.  When you have it working, it is your basis for
>     a logicsheet.
> 
> 2) IF you use the "business object" or XML created from the logicsheet
> in
>     multiple places, factor out the common code into a logicsheet.
> 
> 3) When all your XSP is finalized, take the finalized classes, and make
> them
>     first-class generators (i.e. copy the generated source and classes
> to the
>     WEB-INF/classes directory and reference them as specific
> generators).
> 
> 
> 
> 
> -- 
> 
> "Those who would trade liberty for
>   temporary security deserve neither"
>                  - Benjamin Franklin
> 
> 
> ---------------------------------------------------------------------
> 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


Mime
View raw message