cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [Q] Conceptual difficulties
Date Wed, 17 Jul 2002 08:31:23 GMT
Per Kreipke wrote:
>
> Carsten,
>
> Good morning, thanks for your reply.
>
Thanks - I try to do my best...

> <snip/>
>
> > > - 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).
>
Yes.

> 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.
>
Hmm, I'm not so sure if the sunShine code does this. But the general pattern
I know is exactly the one you describe above: you get a source object,
load your XML in memory and each time you use it, you first check the source
object if it is still valid - if not, you have to reload it.
I'm currently not aware of a better solution - but perhaps it exists.

>
> > 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="" />
>
>
Ah, ok - it's perhaps a little bit misnamed - it is the configuration for
the application but on a per user base! So each user gets his own set
of configuration for the application for customizing it.

> 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.
>
You make me curious!

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

Yes, I agree with you, but unfortunately the current implementation does it
on a per user base as described above.
But this can be extended of course.

>
> <no-fault-critique>
> I wish they weren't called contexts, it confuses things a bit since that
> terminology already exists.
> </no-fault-critique>
Yes, I agree here, too, that's why they are called SessionContext...
No, seriously, Context is really overloaded but we felt that it is the
right name for this at that time.

Regards
Carsten


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message