Quoting Berin Loritsch <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
