Return-Path: Delivered-To: apmail-xml-cocoon-docs-archive@xml.apache.org Received: (qmail 82120 invoked by uid 500); 23 Jun 2003 09:59:52 -0000 Mailing-List: contact cocoon-docs-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-docs@xml.apache.org Delivered-To: mailing list cocoon-docs@xml.apache.org Received: (qmail 82106 invoked from network); 23 Jun 2003 09:59:50 -0000 Received: from dobit2.ugent.be (HELO dobit2.rug.ac.be) (157.193.42.8) by daedalus.apache.org with SMTP; 23 Jun 2003 09:59:50 -0000 Received: from allserv.UGent.be (allserv.ugent.be [157.193.40.42]) by dobit2.rug.ac.be (8.12.8/8.12.8) with ESMTP id h5NA033v014823 for ; Mon, 23 Jun 2003 12:00:03 +0200 (MEST) Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.ugent.be [157.193.121.51]) by allserv.UGent.be (8.12.8/8.12.8) with ESMTP id h5NA030M023090 for ; Mon, 23 Jun 2003 12:00:03 +0200 (MEST) Received: from otsrv1.iic.rug.ac.be (localhost [127.0.0.1]) by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h5NA03x08393 for ; Mon, 23 Jun 2003 12:00:03 +0200 Date: Mon, 23 Jun 2003 12:00:03 +0200 Message-Id: <200306231000.h5NA03x08393@otsrv1.iic.rug.ac.be> From: stevenn@outerthought.org To: cocoon-docs@xml.apache.org Subject: [WIKI-UPDATE] FinishingFlow Mon Jun 23 12:00:03 2003 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Page: http://wiki.cocoondev.org/Wiki.jsp?page=FinishingFlow , version: 1 on Mon Jun 23 09:47:06 2003 by ReinhardPoetz New page created: + !!!UNDER CONSTRUCTION + (RP) + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + \\ + + 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!. + + This is a working document - I'll keep it up-to-date + + !!FOM design + + __cocoon.environment.getURIPrefix()__ + *(RP) How do we provide the getURIPrefix() method? Should it be part of the cocoon object or do we want to provide an environment object that only has this method implemented? + + __continuations__ + *... + *... + + __modules__ + *... + *... + + __script load support__ + *... + *... + + __callAction__ + *... + *... + + !!Flow/FOM implementation + + __getComponent(id)__ + *... + + __cocoon.addEventListener()__ + *... + *... + + __cocoon.removeEventListener()__ + *... + *... + + __release of statefull components__ + *... + *... + + __ClassCastExceptions (FOM_Request != Request)__ + *(RP) to be tested! is this a problem? + + __sendPage( "sendInternalOnlyPipelineHere", {} )__ + *a show stopper! [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105396234901954&w=2] + + __recheck if Continuations expiration works correctly__ + *Some time ago there has been a mail that continuations expiration would not work correctly. We should check this. + + \\ + \\ + \\ + !!Flow documentation + What do we need for a release? + + \\ + \\ + \\ + !!Flow/FOM related + + __move JXTemplateGenerator from scratchpad__ + *(RP) Generally I think it is mature and ready for prime time. + *(RP) Review caching and importing in JXTemplateGenerator: If is used it doesn't work correctly. Caching is implemented using a instance variable. Shouldn't it use the store? + + __move JXForms from scratchpad__ + *(RP) Do JXForms replace the current implementation of XMLForms? Here is a mail from Ivelin [http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105390872728027&w=2]. Do we need a vote? AFAIK XMLForms have never been released but they are widely used. At least we need a migration guide! + + __move Petstore from scratchpad__ + *(RP) ... but only if database connection layer is rewritten +