cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stev...@outerthought.org
Subject [WIKI-UPDATE] FinishingFlow Wed Jun 25 18:00:03 2003
Date Wed, 25 Jun 2003 16:00:03 GMT
Page: http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow , version: 6 on Wed Jun 25 15:56:51
2003 by ReinhardPoetz

- Here you find a summary of open design, implementation and documentation issues of the Cocoon
control flow. I know we have Bugzilla but I think it is easier to follow the open issues and
the discussion as a whole if we use Wiki!. 
+ Here you find a summary of open design, implementation and documentation issues of the Cocoon
control flow. I added some comments in order to give an overview of the current discussion.
If somebody feels that I haven't citied correctly feel free to correct me!
+ 
+ I know we have Bugzilla but I think it is easier to follow the open issues and the discussion
as a whole if we use Wiki!. 
+ ----
+ 
- __cocoon.environment.getURIPrefix()__
? ^^                                 --

+ !cocoon.environment.getURIPrefix()
? ^

- __continuations__
? ^^             --

+ !continuations
? ^

- __modules support__
? ^^               --

+ !modules support
? ^

- __script load support__
? ^^                   --

+ !script load support
? ^

- __callAction__
? ^^          --

+ !callAction
? ^

- __allow actions to wrap call function elements in sitemap__
? ^^                                                       --

+ !allow actions to wrap call function elements in sitemap
? ^

- 
+ ----
- __Component loading__\\
? ^^                 ----

+ !Component loading
? ^

+ 
+ (SM) ''I see two different types of components in Cocoon today: 
+ #general components (example: SaxParser) 
+ #sitemap components (example: FOPSerializer) 
+ I think the flow should have access only to the first family.''
+ 
+ 
+ !Release of statefull components
+ 
+ (SW) ''Ithink there are only two reliable ways to manage stateful components:\\
+ #__raise an error__ if there are some unreleased stateful components when 
+ a continuation is created.\\
+ #__tie releasing__ of a component to the __death of the continuation__ to 
+ which it belongs.
+ 
+ Solution 1/ solves the problem by suppressing its cause. Although it 
+ seems very strict, we can also consider that application state should be 
+ kept by script variables and and not state of components. This is 
+ similar to your remark about EJB statefull session beans : keep state in 
+ the webapp an not in the container.
+ 
+ Solution 2/ can answer transparently to your "function" policy. If the 
+ whole continuation tree is invalidated at function completion on one of 
+ the branches, all components looked up since the function started are 
+ automatically released.
+ 
+ Although solution 2 seems nice, I still find it dangerous to allow 
+ heavyweight resources to float around between requests. This is an open 
+ door to many memory and performance problems if this feature is abused. 
+ Also, it strongly prevents session serialization and thus the use of 
+ flowscript on failsafe servers. So I would go for solution 1, which 
+ enforces careful state management.''
+ 
+ 
+ (SM/RR) ... ''So, it would be best to let the flow writer take care of everything and provide
a dispose() hook to the FOM, potentially deprecatable once we idenfity how to do transparent
component garbage collection in a continuation-driven environment and stateful components
that are not aware of this. Still, the mix between continuations-based state handling and
other forms of state handling (say, transparent EJB transactionality, for example) will very
likely become the single focus of future research in this community.'' see [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105588661921571&w=2]
+ 
+ !Event handling
+ function handlingcocoon.addEventListener(); function cocoon.removeEventListener()
- __Release of statefull components__
- *...
- *...
- __Event handling__\\
- function handlingcocoon.addEventListener(); function cocoon.removeEventListener()
- *...
- *...
- 
- __ClassCastExceptions (FOM_Request != Request)__
? ^^                                            --

+ !ClassCastExceptions (FOM_Request != Request)
? ^

- __Calling internal only pipelines__\\
? ^^                               ----

+ !Calling internal only pipelines
? ^

- __Continuations expiration__
? ^^                        --

+ !Continuations expiration
? ^

- __Passing input module parameters to the flow__
? ^^                                           --

+ !Passing input module parameters to the flow
? ^

- __Syncing Rhino__
? ^^             --

+ !Syncing Rhino
? ^

+ ----
+ ----
- __move JXTemplateGenerator from scratchpad to main trunk__
? ^^                                                      --

+ !move JXTemplateGenerator from scratchpad to main trunk
? ^

- __move JXForms from scratchpad to main trunk__
? ^^                                          --

+ !move JXForms from scratchpad to main trunk
? ^

- __move Petstore from scratchpad to main trunk__
? ^^                                           --

+ !move Petstore from scratchpad to main trunk
? ^




Mime
View raw message