Carsten Ziegeler wrote:
> 
> How would this new component detect if is an xml document
> or an xsp page?

On first access, it would catch the very first startElement()
event.  If it is not:

// raw parameter may vary
startElement("http://apache.org/xsp";, "page", "xsp:page", a);

then execution happens as normal.  If it is, it loads the XSP,
caches the information that it is an XSP page, and fires the
rest of the page through the IncludeXMLConsumer.  All subsequent
requests use the XSP page directly because we have that
information cached.

FileGenerator     ProgramGenerator    IncludeXMLConsumer
-------------     ----------------    ------------------
|
+--| isXSP()             |
|  +-------------------->|
|<-|                     |
|
+--|
|  | startElement()
|  |
|  +--| isXSP()          |
|  |  +----------------->|
|  |  |                  |                    |
|  |  +-------------------------------------->|
|<-+--| (yes)                                 |
|  |
|  | (no)
|  |
|  +--------->startElement()
|<-|
|

> 
> Carsten
> 
> > -----Ursprungliche Nachricht-----
> > Von: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> > Gesendet: Dienstag, 10. Juli 2001 17:24
> > An: [EMAIL PROTECTED]
> > Betreff: [RT] Merging ServerPages and File Generators
> >
> >
> > In my never ending quest to perfect Cocoon, I have a proposal
> > that will make some problems easier to solve.  It is the
> > merging of ServerPagesGenerator and FileGenerator Components.
> > The reason is that the only real difference between them is
> > that the ServerPages Generator compiles an XML file with the
> > root "xsp:page".
> >
> > By merging the two, we use automatic discovery of the type of
> > file we are dealing with, and act accordingly.  I can't tell
> > you the number of times I have either had to declare all pages
> > in a URL space as ServerPages, or do some crazy Sitemap
> > workarounds for a page or two just because I needed XSP in
> > a couple of locations.
> >
> > For example, If I have a general pipeline declaration that
> > works like this:
> >
> > <map:generate src="docs/{1}.xml"/>
> > <map:transform src="stylesheets/1.xsl"/>
> > <map:transform src="stylesheets/2.xsl"/>
> > <map:transform src="stylesheets/3.xsl"/>
> > <map:serialize>
> >
> > Then I would have to add another entry like this:
> >
> > <map:generate type="serverpages" src="docs/{1}.xml"/>
> > <map:transform src="stylesheets/1.xsl"/>
> > <map:transform src="stylesheets/2.xsl"/>
> > <map:transform src="stylesheets/3.xsl"/>
> > <map:serialize>
> >
> > for XSP pages in the same general URL space.  The only
> > difference is the generator type.  So I either use
> > fancy selector logic, an additional matcher entry, or
> > make all my pages in a URL space XSP pages.  It depends
> > on the cost.
> >
> > The merging of ServerPagesGenerator and FileGenerator will
> > allow automatic discovery of the two scenarios without
> > complex logic--easing administration duties.
> >
> > This also eases development as pages are migrated to/from
> > XSP depending on business needs.
> >
> > Another side benefit is that the FileGenerator already has
> > logic that determines if a file has been modified--we can
> > leverage that to determine whether we want our XSP regenerated.
> >
> > Thoughts, Comments?
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

S/MIME Cryptographic Signature

Reply via email to