Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 30077 invoked by uid 500); 24 Jul 2003 13:27:36 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 30035 invoked from network); 24 Jul 2003 13:27:36 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 24 Jul 2003 13:27:36 -0000 Received: (qmail 12039 invoked by uid 50); 24 Jul 2003 13:30:10 -0000 Date: 24 Jul 2003 13:30:10 -0000 Message-ID: <20030724133010.12038.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: dev@cocoon.apache.org Cc: Subject: DO NOT REPLY [Bug 21853] New: - [patch][woody] Making WoodyTemplateTransformer Flow-aware. X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21853 [patch][woody] Making WoodyTemplateTransformer Flow-aware. Summary: [patch][woody] Making WoodyTemplateTransformer Flow- aware. Product: Cocoon 2 Version: Current CVS 2.1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: general components AssignedTo: dev@cocoon.apache.org ReportedBy: mpo@apache.org This patch allows 1/ to have the form/@action dynamically set to a jxpath evalutaion of the form #{$continuation/id} 2/ to look for the form instance in the flow context model -- This introduces a jxpath context member in the template transformer that is used for evaluating #{--jxpath-expression--} in the text of a wt:form-template tag Typical usage is in updating your existing woody-templates to hold this tag: -- This also lowers the required 'form-attribute' parameter to be an optional parameter. If it is not set then the flow-context-object will be considered being a java.util.Map that holds the form instance under the 'woody-form' key -- Finally this holds some comments/suggestion about how we could extend this even one step further to actually support multiple woody-forms on one page. We could allow for multiple wt:form-template tags on one page that each declare themselves the form-lookup key in the flow-context-object-HashMap using their own specific @location="#{/woody-form}" -marc=