cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [C2] Result of XSP performance Analysis
Date Thu, 15 Feb 2001 21:14:33 GMT
Giacomo Pati wrote:
> 
> Berin Loritsch wrote:
> > After reviewing the code last night for the ServerPagesGenerator
> > path I made some notes so that we can see where we need to
> > improve.  Some of the comments are generic and not directly
> > related, but here they are:
> >
> > GENERAL COMMENTS
> > ----------------
> >
> > 1) Every class that uses ComponentManager to get the Cocoon Component
> >    should be made Contextualizable--The same information is in the
> >    Application Context, and therefore we don't need to violate the
> >    Inversion of Control pattern.  Think of the Cocoon object as the
> >    Kernel for Cocoon.
> 
> Agreed

Done

> 
> > 2) Cocoon is NOT a ComponentManager, and should not implement that
> >    interface.  Neither should it include itself as a reachable
> >    Component.
> 
> This is a relict! Cocoon in its first versions WAS the ComponentManager.

Doh!  Fixed.

> 
> > 3) Cocoon does not RECEIVE Configuration objects from an outside
> >    entity, and therefore should not implement the Configurable
> >    interface--UNLESS we are going to make it a proper Component
> >    for inclusion in other contexts than a Web Servlet.
> 
> No I think we already have an different context for Cocoon implemented in the
> Main class (commandline operation)

Even so, the way we tell Cocoon to work is for it to handle it's own configuration.
We just tell it where to find the configuration.

> > ProgramGeneratorImpl
> > --------------------
> >
> > 1) We should make the MemoryStore the one accessed by the Cocoon
> >    ComponentManager using the Role STORE.
> > 2) We should add a FileStore accessible by the Cocoon ComponentManager
> >    with the Role REPOSITORY.

The roles were added, but I haven't gone any further yet.

> > 3) We need to narrow the interfaces for generation to something
> >    other than Object.  ProgramGenerator needs to return a Generator,
> >    MarkupLanguage needs to return a String containing source code,
> >    and ProgrammingLanguage needs to return a Class file.
> > 4) We should extend CocoonComponentSelector to select the proper
> >    XSP instances--thus taking advantage of the Avalon lifecycle
> >    events.
> > 5) The Store interface should allow us to throw an exception--that
> >    way we don't have to do a get() to make sure something has been
> >    properly stored.
> > 6) Default AutoReload to false
> 
> Agreed to all.
> 
> > AbstractMarkupLanguage
> > ----------------------
> >
> > 1) We need to minimize Namespace calling.  It is unnecessary to call
> >    Start and End Namespace Mapping arround _every_ start and end
> >    element event.  We only need to do that where it is called.
> > 2) The Class name generated should be created from NormalizedNames
> >    (In other words the portion that belongs to the context).
> > 3) Any time we encounter a namespace for a logicsheet, we need to
> >    look up the expected prefix (specified in Cocoon.xconf) and use
> >    that prefix--that way the LogicSheets will work independently of
> >    the prefix used to write the page.
> 
> And the prefix will be passed to the LogicSheet as a parameter?

The prefix will be automagically replaced by the one in the config file.
In other words, every SAX Event that has a URI associated with it will
be translated--which only affects compilation.

startElement("http://apache.org/xsp", "page", "foo:page", elem);

gets translated to

startElement("http://apache.org/xsp", "page", "xsp:page", elem);

before it is sent to the ContentHandler.

> 
> > 4) We need to enhance the Reload Detection mechanism--it is too slow.
> > 5) We need to add the ability to turn off reloading.
> > 6) We need to add the ability to precompile a site (i.e. using
> >    generated classnames that are keyed off of the normalized path
> >    instead of the absolute path).
> 
> I do agree and I can manage to get the GENERAL COMMENTS be done now.
> 
> Giacomo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org

Mime
View raw message