On Wed, 17 Jul 2002, Per Kreipke wrote: > I feel like a newbie again. > > It seems as if with every new page or problem to solve, I have a large set > of choices about where I can store information. But where I choose to store > something depends on its lifetime, cachability, granularity, etc. > > In a typical servlet model, I understand the difference in lifetime and > scope between contexts (e.g. session, servlet, etc). But in Cocoon I don't.
It's the same in Cocoon as it abstracts the Servlet environment. > I'm having trouble figuring out where to keep application vs. user level > settings in a web applicaton using Cocoon without every user getting a copy > of a global setting, etc. I think most of the confusion centers around the > repeated use of Source objects and Resolvers throughout C2. > > Note: I've looked through a most of the C2 code (esp. sunshine) and still am > fuzzy on some basics. I've also looked through most of the documentation > both online and in the 2.0.3 build on my machine. > > - is the Cocoon Source object the same as the Source in Excalibur (doesn't > seem so, yet they both seem to be used)? This might be a migration issue from the porting of the Source package from Cocoon to Excalibur. > - 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)? > > - that is, is there little cost to requesting an XML file repeatedly? > > - does it depend on which protocol (cocoon:, resource:, file:, context:, > ...)? > > - sitemap components have their own config info, and some have external > config info (e.g. ValidatorAction descriptor files). Are the external config > files automatically cached in memory and kept up to date if they change? > How: by simply using Source and a resolver? Component configuration are usually read in at startup and never again. > - sitemap components are stored in and returned from pools, each potentially > with its own settings, etc. But is the pool a pool of _all_ components > together, separate pools for each component type (e.g. one for generators, > one for matchers), or separate pools for each specific component (e.g. a > pool of CIncludeTransformer's, each with their own default settings)? If a component is Poolable there will be a separate pool for that component (one for FileGenerator, CIncludeTransformer, etc.). > - 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? You need to rewrite the component to have it expect the configuration elsewhere and read it in by itself. > - when you access the application context in the sun* code, is it accessing > a single copy for everyone? Where is it actually stored? I don't know the sun code in depth but generally application context *is* one single copy in the system. > - in summary, how/where would one store an XML snippet as essentially a > singleton object for use by all users? Put it in the Context object. Giacomo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
