You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Geoff Howard <gh...@crosswalk.com> on 2002/06/06 17:45:54 UTC
Best Practice for shared information lookup? Modules?
Wasn't sure what to call this.
I have a need to make some shared information available to components. I'd
want the information cached in memory to cut down on the overhead of reading
it from the filesystem or database. I'll need it within custom generators
for now, but it'd be a plus to generalize this to others such as actions and
great if the same info could be called in the sitemap. Because of this I'm
thinking that some component would be best and may already exist. I've read
up on the new module stuff but can't tell whether it's meant for this use or
not.
Example:
We have subsites organized into page-layouts by a separate cms system. Each
subsite has a default "front page" page-layout id and there are many places
I need to look this up for fallback behavior.
The information rarely changes, but is stored in the database for use by the
cms and thus the lookup operation is too expensive to just read it each
time. I thought about using a cached pipeline to hold the information as
xml but that makes accessing it from within other components difficult.
I thought of defining a singleton class with public
getSubsiteID(page-layoutID) methods, etc. but thought there was a more
"cocoon" way of doing this that would make the availibilty more general.
Geoff Howard
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Migration troubles 2-1dev to 2.01
Posted by Montier Patrick <pa...@easance.com>.
Hi everybody,
I just upgrade my cocoon release from 2-1dev to 2.01.
All works except form validation.
Is the syntax of descriptors files has changed ?
Thank you
Patrick
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Best Practice for shared information lookup? Modules?
Posted by Peter Royal <pr...@apache.org>.
On Thursday 06 June 2002 11:45 am, Geoff Howard wrote:
> I thought of defining a singleton class with public
> getSubsiteID(page-layoutID) methods, etc. but thought there was a more
> "cocoon" way of doing this that would make the availibilty more general.
There is, create a new component!
Define a role (interface) and your generators/actions can then implement
Composable and you can then do componentManager.lookup() to retrieve the
component.
Add your custom component to cocoon.xconf ala:
<component-instance class="your.class" role="your.role"/>
-pete
--
peter royal -> proyal@apache.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Best Practice for shared information lookup? Modules?
Posted by Christian Haul <ha...@informatik.tu-darmstadt.de>.
Geoff Howard wrote:
> Wasn't sure what to call this.
>
> I have a need to make some shared information available to components. I'd
It depends where you need this information and what kind of information
it is.
If it is simple (small), needed by the sitemap, existing sitemap
components or sitemap components that are general in nature apart from
the value's source (e.g. request parameters, request attributes &c), go
for an input module.
If it is complex (large), needed mainly by other (custom) components, go
for a component.
If you don't know, implement the InputModule interface and provide
additional access methods as well :-) It's not really an either or
situation. Afterall, you need a component to implement the InputModule
interface. And I hope, that it's really simple to implement to it. It's
just the standardized access methods that set InputModules apart.
Chris.
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Re: Best Practice for shared information lookup? Modules?
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Geoff Howard wrote:
>Wasn't sure what to call this.
>
>I have a need to make some shared information available to components. I'd
>want the information cached in memory to cut down on the overhead of reading
>it from the filesystem or database. I'll need it within custom generators
>for now, but it'd be a plus to generalize this to others such as actions and
>great if the same info could be called in the sitemap. Because of this I'm
>thinking that some component would be best and may already exist. I've read
>up on the new module stuff but can't tell whether it's meant for this use or
>not.
>
Yes, a module (more precisely an InputModule) can be used for this. And
the sitemap feature you're talking about has been voted last week on
cocoon-dev, and I'm starting its implementation (for version 2.1) : if
your module is named "layout" in cocoon.xconf, you will be able to write
e.g. <map:transform src="{layout:foo}/page.xsl"/>
>Example:
>We have subsites organized into page-layouts by a separate cms system. Each
>subsite has a default "front page" page-layout id and there are many places
>I need to look this up for fallback behavior.
>
>The information rarely changes, but is stored in the database for use by the
>cms and thus the lookup operation is too expensive to just read it each
>time. I thought about using a cached pipeline to hold the information as
>xml but that makes accessing it from within other components difficult.
>
>
If the information rarely change, you could have your module
implementation cache the result.
>I thought of defining a singleton class with public
>getSubsiteID(page-layoutID) methods, etc. but thought there was a more
>"cocoon" way of doing this that would make the availibilty more general.
>
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>