cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: [C2] Result of XSP performance Analysis
Date Thu, 15 Feb 2001 20:21:47 GMT
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

> 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.

> 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)

> 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.
> 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?

> 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

Mime
View raw message