cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Per Kreipke" <>
Subject RE: [Q] Conceptual difficulties
Date Wed, 17 Jul 2002 08:13:12 GMT

Good morning, thanks for your reply.

> > <snip/>
> >
> > - is the Cocoon Source object the same as the Source in
> Excalibur (doesn't
> > seem so, yet they both seem to be used)?
> In 2.0.3 (or from 2.0 to 2.0.4-dev) only the Cocoon source object is used.
> We moved the source resolving to excalibur and starting with 2.1 only the
> excalibur source resolving is used. As this is an incompatible change,
> this will happen when we release 2.1. There are additional wrapper classes
> to maintain as much compatibility as possible.


> > - does the resolver automatically cache the source object if
> possible, and
> > also watch for changes (it doesn't seem as if any of the Source's are
> > caching)?
> >
> The current impl. does no caching - it is possible to implement it.

Hmm. Let me state it differently: many times, the result of loading (an
Action's) configuration is kept in memory and then if the source is
modified, it is reloaded. This is, in effect, an in memory cache (it's not
re-parsed upon every request).

The annoyance I see everywhere is that the same code/checks are repeated in
every Action that wants this behavior (e.g. the Validators, DB actions,
etc). I was hoping there was an easy way to load an XML fragment in memory
and keep it current with respect to the file on disk. But not to reread it
on every access. I'm pretty sure you do some things like this in the
SunShine code.

> > - the sun* code expects config information directly in the
> sitemap instead
> > of a separate file. When using the compiled sitemap, that's a
> > real nuisance.
> > Is there a way around that?
> >
> I assume you mean the sunshine, sunrise etc. code and not something from
> Sun...

Sorry, yes, the SunShine code.

> No, there is no way around it - again with 2.1 the interpreted sitemap
> is used instead and this is no longer a problem. Remember, the sunshine
> components are for the 2.0.3 branch in the scratchpad.

In the docs, there is an example that suggests the application config being
loaded. Snippet:

<handler ...>
   <application ...>
       <load uri="" />

Aside: I like the SunShine concept a lot, and would love to use it instead
of futzing around with building something similar but I can't figure out how
to integrate logic with the sunshine tags since they get handled by a
transformer, not a generator. I'll detail some questions about that in a
separate thread.

> > - when you access the application context in the sun* code, is it
> > accessing
> > a single copy for everyone? Where is it actually stored?
> >
> Yes, each user has his own context. It's therefore stored in the session.

Ok. But some things aren't user specific, they're application specific.
Every user should share a single copy of those settings, no?

I wish they weren't called contexts, it confuses things a bit since that
terminology already exists.

Thanks, Per

To unsubscribe, e-mail:
For additional commands, email:

View raw message