Donald Ball wrote:
>
> some other failings include:
>
> * it's difficult and buggy for the xsp engine to track and apply dependent
> logicsheets
This is true.
> * it's difficult to modularize logic into functions. if you do it in java,
> you have to track and pass all necessary internal variables yourself. if
> you do it in xslt, parameter passing is a real bitch, and you have to
> tread carefully to ensure your locally declared variables don't end up
> conflicting with someone else's.
True.
> * 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.
> > How do we come back and reclaim our right to separate MVC+Mgmt?
> > One solution is that we implement SLL (does everyone remember
> > that?) and use SLL for tag libraries. This will allow us to
> > remove code from our model. What do we do when the logicsheet
> > is too low level like ESQL? Don't get me wrong, Donald Ball
> > did a tremendous job with ESQL, but it is still mixing concerns.
>
> well, thank you, but i don't quite see where you're getting at with mixing
> concerns. could you elaborate?
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.
> 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.
All I was saying is that is a solution that I used. When you need to implement
complex business documents with smaller business objects, the XMLizable
approach is the best alternative I have seen yet. It tightly binds an object
to a schema--and the toXML() function is easily written as a wrapper around
the toSAX() function.
This is not to say that it could be expanded upon, and we create a dictionary
to bind objects to XML. For me, that was just too much work when I had a limited
number of objects that were going to be serialized in that manner.
> > With the advent of aggregation, and the ability to embed XML
> > structures via one of the two aggregation methods, we have some
> > very powerfull solutions available to us. I personally don't
> > like the Sitemap aggregation because it takes the construction
> > of the page out of the Graphic Artist's hands. A templating
> > approach is much more flexible, and exciting because it allows
> > the Graphic Artist to use familiar tools, while we create
> > different pieces of the content in the background.
> the sitemap aggregation features, as they exist now, also make it
> difficult to impossible to create a more complex skeletal xml structure to
> include your content in. for instance, i found recently that i wanted to
> do this:
>
> <root>
> <meta>
> ... included content ...
> </meta>
> <page>
> <body>
> ... included content ...
> </body>
> </page>
> </root>
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>
To me, this is more preferable anyway. I would have to doublecheck on how
it is accomplished now that they moved that to the XIncludeTransformer as
opposed to the SAXConnector. It was a solution that I used to good effect
in my last project.
> without using multiple sitemap pipelines, i couldn't find any way to do
> this. so i'm wondering if an alternate approach might be to construct the
> xml skeleton right there in the sitemap if we wanted to:
>
> <map:match pattern="event/add">
> <map:generate type="inline">
> <root>
> <meta>
> <map:include src="plain/meta"/>
> </meta>
> <page>
> <body>
> <map:include src="plain/form"/>
> </body>
> </page>
> </root>
> </map:generate>
> </map:match>
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.
> of course, an alternative is to do the including in an xsp page, but then
> the included content has to be accessible not via a sitemap component, but
> rather via an xsp logicsheet or sax library method.
Hmm, SAX library....
> another alternative would be to consider implementing a simplified dynamic
> page language. instead of allowing arbitrary code to be put in documents,
> we could mandate that only dynamic tags associated with registered
> 'logicsheets' would be allowed. then i could write my example above like
> so:
>
> <root>
> <meta>
> <sitemap:include src="plain/meta"/>
> </meta>
> <page>
> <body>
> <formgen:generate table="event_table"
>schema="context://WEB-INF/etc/tables.xml"/>
> </body>
> </page>
> </root>
See above where I talked about the include tansformer. It should be possible
now.
> 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.
S/MIME Cryptographic Signature
