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
