cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: TODO List so far
Date Tue, 31 Oct 2000 08:05:46 GMT
Hi folks,

I had a few ideas while reading Giacomo's todo list that I wanted to
share. I'm relatively new to Cocoon (3 months) and started to study C2
only 2 weeks ago so forgive me if these ideas are not relevant, and if
not please explain me why.

Giacomo Pati a écrit :
> 
> Hy all
> 
> Here is my todo list I've collected so far.
> 

<snip/>

> - Cache Proposal
>      There has been a discussion many weeks ago about this topic.
>      We need to take up again to come to a conclusion. There has
>      been some thought about that from Russ Burton IIRC.
> 

A problem I think in both C1 (Modifiable) and C2 (Changeable) is that
objects implementing these interfaces have no mean to say they will
*always* change (volatile, no ergodic period). Don't know for C2, but in
C1 (that was discussed recently on the list) the URL of an XSP is
blocked while its content is produced to be put after in the cache. This
is useless, since hasChanged() always returns true (unless you redefine
it in the XSP), and has the additional bad side-effect of blocking
concurrent requests to the same URL ! Also, I don't understand in which
condition the C2 XSPGenerator modifiedSince() method can return false
(it returns true if the XSP creation date is before the current date).

So can a new "isVolatile" method in "Modifiable" be the solution (if
isVolatile, don't even try to cache it) ? What do you think about it ?

Also, for objects that do have an ergodic period, I noticed in C1 that
the cache key is the request URL and browser type. Don't we need a more
generic mechanism based on the object model ? For example, I have some
applications where XSPs can be cached on a per-session or per-user
basis. Since I have no mean to express it, they're always regenerated.
And I think this particular point will arise often with
content-aggregation portal-like pages.

>

<snip/>

> - Moving sitemap component to cocoon.xconf
>      Peter Donald (Avalon) mentioned recently to move the
>      <map:components> section from the sitemap.xmap to the
>      cocoon.xconf file. This indeed would reduce the verbosity of
>      the sitemap but also will introduce some restrictions to the
>      design we have today. One restriction is that the concept of
>      the CodeFactory (direct integration of java code during the
>      sitemap generation stage) will not be possible anymore. Also
>      if someone uses many "custom" components to build up his URI
>      part its not been seen in "his" sitemap and the responsable
>      person of the cocoon.xconf file (usually a sysadmin) will
>      have to be contacted if new sitemap components have to be
>      integrated. Please discuss this as well.
> 

Regarding this point, why not use XInclude for the sitemap and xconf ?
That would allow parts of their contents to be defined elsewhere.

This suggestion comes from personal experience : some of our customers
are big companies where people that are responsible for the installation
and tunig in production environment (sysadmins) know nothing about the
application. And these people like to have a single file that contains
all runtime parameters they have to configure (JDBC info, LDAP server
address, logins, etc). Also, mixing runtime information with structural
information (definition and composition of components) in a single file
can easily lead to application breakage if some structural information
is accidentally changed when setting runtime parameters.

Well, isn't that a kind of separation of concerns ? But the problem is
that the elements that define these concerns heavily depend on the
context : knowledge and responsibilitites of people, application,
customer, etc. So I think using XInclude may be useful to achieve this
separation in a modular fashion.

> So far these are the items I've collected during my break and the ApacheCon. I
> know there might be others issues which are not listed above, so please stand up
> and bring it into this discussion.
> 
> After we have collected all of them we will have to prioritize them and
> categorize them to state which will be suitable for Beta 1.
> 
> Ok, let's start it.
> 

One additional item that was discussed recently : allowing classes
produced from XSP to extend other classes than XSPGenerator. This would
allow XSP to be used as a generic langage for XML generation in
environments where a servlet context is not useful nor available
(database connectors, legacy file transformation, etc) without
reinventing the wheel and rewriting all the complicated java generation
stuff.

Hope you will find these suggestions usefull.

-Sylvain

Mime
View raw message