The current architecture of the Sitemap management system
needs a little work.  The ComponentManagement infrastructure
has a hierarchical nature to it.  This enables a natural
security by design, so that components that have no business
getting a reference to each other can't.  When we have
a hierarchical structure of sitemaps, it only follows that
the ComponentManager match the hierarchy.

Why is this so important?  It enables us to specify components
(like actions) that are only accessible from a certain sub-sitemap.
No other peer or parent will be able to access that component.

In my move to migrate Cocoon 2 to the latest and greatest
Excalibur release (which incorporates the original hierarchical
ComponentManager was always part of the Avalon vision), sub-sitemaps
are broken.  The reason being is that the sitemaps are not being
heirarchicaly built.  There are two ways around this: multiple
GeneratorSelector/ProgramGenerator instances for each sitemap,
and changing the SitemapManager paradigm.

The multiple instances of GeneratorSelector/ProgramGenerator would
function only to force the hierarchical ComponentManager infrastructure.
It is extremely hacky, and I don't like it.

The other approach, is to move SitemapComponents to be Contained by
the Sitemap--not the ComponentManager as is being done now.  This
paradigm shift does not apply to the root Components, as they are
well managed as they are now.  The main thing is that according
to the design of the current ProgramGenerator/GeneratorSelector,
the parent ComponentManager cannot be controlled.

There is yet one more way we can get this to work.  We would need
to add a method to GeneratorSelector ("addGenerator") that took a
ComponentManager as an argument, and the same with the ProgramGenerator.

The last alternative is to have the ProgramGenerator not return
a Component, but a class.  It would be up to the ProgramGenerator's
clients to decide how to handle instantiating the Component.  That
would probably be the best way to go.

No that I have properly confused everyone, I will do my best to
answer questions....

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to