cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: Real-world recommendations for dynamic XML production?
Date Sun, 30 Jan 2000 19:09:36 GMT
On Sun, 30 Jan 2000, Stefano Mazzocchi wrote:

> Donald Ball wrote:
> > 
> > So, after reading how happy Stefano is to be wrong, I'm still left with
> > the question. I want to create dynamic XML in the middle of document
> > transformation. I have been writing processors to accomplish this, but
> > that's an undesirable long-term strategy for many reasons. I've been
> > trying to port one of my processors to be an XSP taglib instead (with not
> > much success, argh, I feel stupid), but now I'm unsure whether I should
> > continue down that road or if I should write an extension library for
> > Xalan. What shall I do?
> I'd suggest: continue as nothing changed on the XSP track. The hard part
> of taglib programming is coming up with logicsheets... I admit I too
> consider it a black art and it will probably be very hard to do unless
> you understand all details.
> I still don't... :( Ricard is the only one around.... and Donald is
> having problems.... So I don't picture many dealing with creating
> taglibs on their own... unless the process is somewhat simplified but I
> don't know what this means.
> Guys, please understand: we're developing a completely new
> infrastructure for something that is _never_ been addressed before by
> anybody else in the world. The Cocoon project is the only project taking
> care of dynamic XML Generation with such great involvement and new
> ideas. It takes time to settle down to something useful and solid
> enough.

And I think we're almost there. Just need a little more documentation and
examples. :)

> But, still, at this point, implementation details.
> So, real-world reccomendations:
> 1) mix your xsp tags with your content and tell your content writers not
> to touch them. Breaks context separation but it works like a breeze for
> small programming needs.
> 2) if your programming needs are pretty thick and the above doesn't
> work, write placeholder tags such as <database-query/> and write a
> simple stylesheet that applies the xsp tags over. Complete separation is
> performed, but those placeholders could be also external entities and
> such.
> 4) use the available taglibs instead of placeholders and write your
> placeholders in case you're missing something.
> 5) write your taglib

I'd hope that we'll get to the point soon that we have taglibs written for
the most common dynamic XML production needs - probably SQL, LDAP, mail,
and calendar taglibs will cover 50% of this. What else are people
interested in generally?

> I suggest to stay away from 5 until Ricardo write a nice howto about
> that. I admit I'm afraid to touch that part myself (see the taglib
> example on Cocoon disto that is not exactly equal to the other two
> examples)
> Please consider this: XSP defines a semantic on including logic in your
> page. It does not define a way to separate logic from content. Ricardo
> used namespace-driven taglibs to provide a solid way to do that, but you
> won't find them defined in the spec...
> Why? separation of contexts. One thing is defining how a page
> incorporates programmatic logic, another is how to incorporate that
> logic into the page.
> So XSP gives you the tool... XSLT the transformation... use the two as
> you normally do with any other context separation (content/style)
> (structure/markup) (data/content).

Okay, then, now I'm confused again. You were happy to be wrong since XSP
is irrelevant, but we should be using XSP to develop taglibs? In what
sense is XSP irrelevant then?

- donald

View raw message