> > Is your callback mechanism a generalization of the <aggregator>
component
> > and a way to hint dynamic parts?
> > If I understood correctly, if a callback returns the same document (same
> > content) as it did once before, then eventually a "smart" XSLT processor
> > (which cached earlier results) would still know that its (the
callback's)
> > portion of the document didn't change and shouldn't be re-processed.
>
>
> That is pretty close.
>
> Let's assume for instance that the XSP markup looks something like this:
>
> <inbox xmlns:xsp="http://apache.org/xsp";
> xmlns:mycom="http://mycom.com/logicsheet/1.0";>
> <mycom:user/>
> <mycom:inbox/>
> </inbox>
How would this work if I slightly modified the piece above:
<mycom:user>
Name: <mycom:lastName/>, </mycom:lastName>
<br/>
email: <mycom:email/>
</mycom:user>
Is that allowed, or instead one'd have to do:
document1.xml
<inbox xmlns:xsp="http://apache.org/xsp";
xmlns:mycom="http://mycom.com/logicsheet/1.0";>
<mycom:user/>
<mycom:inbox/>
</inbox>
document2html.xsl
..
<xsl:template name="userprocess>
Name: <xsl:value-of select="lastName">, <xsl:value-of select="firstName">
...
Then the sitemap pipeline will be like:
<map:generate src="document1.xml"/>
<map:transform type="XInclude"/>
<map:transform src="document2html.xsl"/>
...
Does my question make any sence?
>
> For each session, the user information is completely static. The inbox
> doesn't
> necessarily change that often either. The compiled XML spec needs to mark
> callback events in a special manner so that they are not lost in each
> transformation
> stage. The output can be something like this:
If I am not mistaken, since the call-backs are simply xml elements with
specific name space, then as long as they are preserved as such along with
their namespace references during multiple transformation stages, then it
shouldn't take any extra work to keep them from being lost.
>
> <html>
> <h1><callback:event name="mycom:user"/></h1>
> <h2>Inbox</h2>
> <table>
> <tr>
> <th>Name</th>
> <th>Status</th>
> <th>Date</th>
> </tr>
> <tr>
> <callback:event name="mycom:inbox"/>
> </tr>
> </table>
> </html>
>
> The callback mechanism will resolve the resource name to the proper XSP
> fragment.
At what points of the pipeline will the substitutions happen.
Would one explicitely use XInclude transformers at each point in the
pipeline when callbacks should be called and resolved to xml?
Also at what point does the <callback> element get converted to an actual
XML Source fed by the call-back function.
What is the benefit of the intermediate stage ?
<myspace:user/> -> <callback:event .../> -> XML Source
Could it be just
<myspace:user/> -> XML Source
Keep the good ideas flowing so we can start on the implementation asap.
Ivelin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
