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.
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.
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.
Something like "user:" and "cart:" would be an example of going too far.
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)
-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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
