> -----Original Message-----
> From: Ivelin Ivanov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, March 18, 2002 11:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [RT] CallBack Style XML Handlers
>
>
> > > 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
You can do whatever you like, but the compilation would
Transform those sections into callbacks. The CallBackHandler
would insert the relevant snippet
>
> ..
> <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?
Actually, once the compiled XML is generated, the XInclude transformer
Layer is not needed at all.
It is automatically executed as needed
> > 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.
The trick is with cached elements that have dynamic elements.
Instead of using several cache entries for whole copies of
An entire page,we have one entry for the page, which dynamically
Includes the other elements as needed. This allows us to have
Different periodicities for *parts* of a page--without cluttering
The cache with unnecessary copies of the same resource.
>
>
> >
> > <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
My next step will be to work with the compressed/compiled XML,
That will encode those events.
>
>
>
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
