You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/02/15 19:24:58 UTC
[C2] Result of XSP performance Analysis
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.
2) Cocoon is NOT a ComponentManager, and should not implement that
interface. Neither should it include itself as a reachable
Component.
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.
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
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.
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).
Re: [C2] Result of XSP performance Analysis
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: [C2] Result of XSP performance Analysis
Posted by Giacomo Pati <gi...@apache.org>.
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