On Thu, 21 Jun 2001, Berin Loritsch wrote:
> > * debugging xsp pages can be very painful. debugging xsp logicsheets can
> > be even more painful.
>
> Now you are being kind. Debugging logicsheets is hell on earth. The
> reason is that it interacts in different environment in unpredictable
> ways sometimes.
okay, yes, you're right. debugging logicsheets is the worst thing in the
world. :)
> Sure thing. ESQL is a logic sheet that mixes information about
> how to retrieve information from a database with the information it
> retrieves. You can abstract your logic to generate the results in
> a logicsheet but we come back to your point about designing logicsheets
> being painful. Most people are going to opt for the easiest road,
> and simply use the ESQL tags in there document. I venture to say the
> average Business analyst isn't going to know where to start when they
> look at a page with ESQL in it. Beyond that, the business oriented
> designer has a higher likelihood of screwing up the page.
okay, i see what you're saying. personally, i almost always use a custom
logicsheet to transform elements in my namespace (e.g. <my:get-clients/>)
into elements in the esql namespace, but i can see where many people
wouldn't bother.
> > if i might comment for a moment here - just about the nicest thing about
> > writing xsp pages is that the api for creating xml is so easy. working
> > with DOM is horrid, and SAX, while great for content receivers, is imho a
> > pretty bad api for content providers.
>
> True, but when you embed objects that have small XML fragments to generate
> a larger XML document, it works better than DOM, and better than creating
> strings.
yeah, but maybe jdom or dom4j would be a better choice? but that's beside
the point.
> There is the include semantics that have replaced the CIncludeSAXConnector
> for embedding pipelines in a template file. It would be something like this:
>
> <root>
> <meta>
> <xinclude:include href="cocoon://foo.xml"/>
> </meta>
> <page>
> <body>
> <xinclude:include href="cocoon://bar.xml"/>
> </body>
> </page>
> </root>
oh, do we have the cocoon: protocol implemented now? oh, note that i still
remain adamantly opposed to using the xinclude namespace if we don't
conform (largely) to the xinclude specification...
> I think this is putting too much information in the sitemap. The
> administrator shouldn't really have input onto the structure of the
> page--just how to access it.
i'd tend to agree, but it's a thought.
> > instead of using xslt passes to transform this document into java source
> > code and then compiling it, we could use the axkit paradigm and just map
> > certain sax events to java methods:
> >
> > public void startElement(...) {
> > if (namespace URI (NOT PREFIX!!!) is registered) {
> > namespaceHandler.invoke(element name, attributes, this);
> > } else {
> > this.underlyingContentHandler.startElement(...);
> > }
> > }
>
> That's what the Transformers do. In fact, the Transformers work
> nicely in that they are easier to write on how they react to
> namespaces. However, a SAX based Transformer is not that easy to
> write.
ah, but the problem with using strictly sitemap transformers to do this,
at least for webapps, is that you don't always know what transformers
you're going to need to use in a given pipeline, and the pipeline is
immutable. so suppose i have a transformer which operates on my namespace
and transform
<my:get-clients/>
into sql transformer elements:
<sql:connection>
...
<sql:execute-query>
<sql:query>select * from client_table order by name</sql:query>
...
</sql:execute-query>
</sql:connection>
for this to work in the current environment, i'd have to known that the
'my' transformer is probably going to need to call the 'sql' transformer
immediately after it. that should not be the concern of the sitemap
maintainer...
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
