cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: [C2] state and actions proposal
Date Wed, 31 Jan 2001 14:46:37 GMT
Hi, All!

On Wed, 31 Jan 2001 06:34:29 -0000 Allan Erskine wrote:
>Hi
> 
>I have a proposal for actions in C2.  The proposal is that an action should be definable
in the context of the state that it affects, and the action's possible 
>parameters.  This would necessitate being able to define state entities in the sitemap,
along with the actions that can affect these entities.
> 
>Furthermore, it should be possible to define an action's interface (ie the state it affects,
it's parameters, and what it returns [+to where!]) separately from it's 
>implementation.
> 
>In other words, there should be a construct analogous to classes from OO languages at
sitemap level, along with the ability to access entities of a particular 
>class at pipeline level (xsp level too).
<snip/>
> 
>The class/entity system need only be complex enough to allow C2 to fulfil it's mandate
as an interactive presentation layer, and NO MORE.  The entity 
>management responsibilities would lie as before with whatever RDBMS, CMS, etc

Let the Cocooners team give a proper estimate to this proposal, 
but I would like to remark that it looks to have something to do
with the formation of caching keys, the matter my prev emails
to the list were about.
If we have an action interface clearly defined, the caching key
for it (as a Dinaminc component) may be built on that.(If nothing
wiser is implemented).

=============

  BTW, Cocooners, what's your opinion of my humble review of
  caching issues? (Have I written it in such a bad manner, that no one
  wanted to read it :-)?

  How about the idea that we won't be able to have caching up
  and running unless actions are split into two kinds of components:
  a) those that change sitemap environment and thus may affect/affect
      chice of pipeline components (and thus should be considered Dinamic
      and hav getKey() method)
  b) those that do not affect sitemap environment but have side-effects
      (change DMBS records, etc)

=================

On Wed, 31 Jan 2001 08:58:24 -0500, Berin Loritsch wrote:

>
>Not to put a damper on things, but we have two things at work with
>Actions:
>
>1) They need to be simple--to that end they deal only with request
>   params and such.
>2) The Servlet 2.3 proposal covers (duplicates?) the actions with
>   the Filters.  It would not be surprising to see Actions living
>   as long as they are needed, and replaced by Filters when Servlet
>   2.3 becomes widely available.
>
BTW, it would be intresting to view the Filters (Servlet 2.3 issue) with
a connection to this caching problem

>This is, of course, unless we find a _really_ compelling reason to
>do it all in Cocoon.

I've got a shiver in my back that tells me that we should look closer at
the caching issues... Can they become such kind of stuff?
BTW, In my Humbel lurkers opinion there might be some sault in haveing action interfaces better
defined. Maybe not in the sitemap itself..

Best regards, Tagunov Anthony

P.S.

We could have this Action interface definitions somewhere else, not in the sitemap.. say via
some getInterface() method in the Action interface?


Mime
View raw message