cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Quinn <jer...@media.demon.co.uk>
Subject Re: Discussion of Flow Issues
Date Mon, 17 Mar 2003 20:45:36 GMT

On Monday, March 17, 2003, at 08:02 PM, Stefano Mazzocchi wrote:

> Sylvain Wallez wrote:
>

<snip/>

> So, I would go for
>
>  global -> contains global log methods, no properties

Why log methods? I don't understand what is so special about them, that 
they need to be global?

  cocoon.log.info("blah");
  cocoon.log.error("blah");
  cocoon.log.debug("lkj");

make more sense to me, even if they are longer :)

>  cocoon -> cocoon methods + component management methods

+1

You would use a 'role' identifier to retrieve them?

>  cocoon.request -> access to the request

+1

>  cocoon.response -> access to the response

+0

>  cocoon.context -> access to the context

+1

>
> NOTE:
>
>  1) do we really need the session object? the flow is in fact 
> deprecating the use of sessions for storing stateful data. I would 
> love to *force* people to think into this way by not making the 
> session available to them.

I think that is an interesting idea.
Will cause some confusion, but it is true to the concept of Flow.

> We can always add it later if users really push us for it.
>
>  2) do we need access to the response? setting headers is the only 
> thing that comes to mind, but that is potentially abusable, expecially 
> on things like cache headers and such. maybe we should leave this out 
> as well for now.

I think we need more resolution of the various ongoing discussions 
about cleaning up Cocoon's interaction with all aspects of HTTP headers 
(in-bound and out-bound) before we can decide to take this out of 
Flow's reach.

Ideally, we should be able to take it out.

>
>  3) avalon component management should be done thru the 'cocoon' 
> object because it's cocoon, in fact, that provides those components to 
> you. the fact that they are managed internally by avalon doesn't make 
> any difference for joe-flow-user, nor should.

+1

What management methods do you envisage?
What gets automatically managed?

TBH. I don't understand yet when/why you would access components from 
Flow.

> What do you think?

I am glad this is happening this way :)

regards Jeremy


Mime
View raw message