From ywilliamson@example.org Fri Aug 01 07:43:13 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 68937 invoked by uid 500); 1 Aug 2003 07:43:12 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 68917 invoked from network); 1 Aug 2003 07:43:11 -0000 Received: from unknown (HELO mail.cbim.it) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 07:43:11 -0000 Received: from cuprouter.cbim.it (cuprouter.cbim.it [83.161.120.155]) by mail.cbim.it (8.11.6/8.11.0) with ESMTP id h7186iG16592 for <ywilliamson@example.org>; Fri, 1 Aug 2003 10:06:44 +0200 Received: from cbim.it (caterina.cbim.it [83.161.120.155]) by cuprouter.cbim.it (8.9.3/8.9.3) with ESMTP id JAA27961 for <ywilliamson@example.org>; Fri, 1 Aug 2003 09:43:55 +0200 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 09:45:14 +0200 From: Ugo Cei <ywilliamson@example.org> Organization: C.B.I.M. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Garbage or The Quest for the Perfect Template Language References: <ywilliamson@example.org> <ywilliamson@example.org> In-Reply-To: <ywilliamson@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Christopher Oliver wrote: > Ugo Cei wrote: > >> These days I'm banging my head against the limitations of template >> languages. I've tried XSP and it's not in any way limited, but it has >> its share of problems (difficult to debug and offers too many ways to >> shoot oneself in the foot), JXTemplate{Transformer,Generator} (no way to >> call methods on context objects, no decent arithmetic) > > > What exactly is the problem with the arithmetic in Jexl and/or JXPath? > What problem did you encounter calling methods? You should be able to > with do that with both Jexl and JXPath. > > Regards, > > Chris I'll try to come up with an example but I seem to remember having problems doing even a simple counter. And WRT calling Java methods, I must admit I didn't even try it. Since it's not documented I thought it wasn't even implemented ;-). Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: 523.542.2966 - E-mail: ywilliamson@example.org From ywilliamson@example.org Fri Aug 01 07:44:34 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 70768 invoked by uid 500); 1 Aug 2003 07:44:31 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 70742 invoked from network); 1 Aug 2003 07:44:30 -0000 Received: from dobit2.ugent.be (HELO dobit2.rug.ac.be) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 07:44:30 -0000 Received: from allserv.UGent.be (allserv.ugent.be [83.161.120.155]) by dobit2.rug.ac.be (8.12.8/8.12.8) with ESMTP id h717icbs023472; Fri, 1 Aug 2003 09:44:38 +0200 (MEST) Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.ugent.be [83.161.120.155]) by allserv.UGent.be (8.12.8/8.12.8) with ESMTP id h717ibJx024795; Fri, 1 Aug 2003 09:44:37 +0200 (MEST) Received: from outerthought.org (host104 [83.161.120.155]) by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h717ibx24765; Fri, 1 Aug 2003 09:44:37 +0200 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 09:44:37 +0200 From: Steven Noels <ywilliamson@example.org> Organization: Outerthought User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org, ywilliamson@example.org Subject: Apache newsletter in progress Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N fyi: Tetsuya Kitahata is in the process of preparing the first all-Apache newsletter, and his late work on the Jakarta newsletter sure makes it warrant some attention. I added a little statement as to how the Cocoon project is faring on the draft Wiki version: http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheNewsletterDrafts/Issue1 If there's anything completely wrong or stuff you really want to be added, please LMK. Cheers, </Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ ywilliamson@example.org ywilliamson@example.org From ywilliamson@example.org Fri Aug 01 07:49:12 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 74136 invoked by uid 500); 1 Aug 2003 07:49:12 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 74118 invoked from network); 1 Aug 2003 07:49:11 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 07:49:11 -0000 Received: (qmail 28648 invoked by uid 50); 1 Aug 2003 07:51:59 -0000 Date: 1 Aug 2003 07:51:59 -0000 Message-ID: <ywilliamson@example.org> From: ywilliamson@example.org To: ywilliamson@example.org Cc: Subject: DO NOT REPLY [Bug 14348] - Caching problem with XSP, XSL and cocoon pseudo protocol 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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348>. 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=14348 Caching problem with XSP, XSL and cocoon pseudo protocol ------- Additional Comments From ywilliamson@example.org 2003-08-01 07:51 ------- the bug is the way SitemapSource (here cocoon:/bar) computes its last modified date; it hashes a combination of the event pipeline's cache key and the corresponding validity. this yields (in most cases?) a negative number. when ProgramGeneratorImpl checks the xsp's creation date against the source's last modified date it 'finds out' that the xsp is 'newer' and must be updated. in cocoon 2.1 (from a quick look at a checkout) the SitemapSource just returns 0; can't determine. which means that recompilation of the XSP would be done here also. so, the solution is to get a valid last modification date for the SitemapSource, for which there are probably many ways, e.g. - store the creation/modification date for a cached stream/event pipeline, and make it accessible - store that date and the pipeline's validity in transient cache and later on check previous (stored) validity against current validity and if validity changed, update last modified and store validity I've tried the latter one. if there's any interest I could provide a patch. From ywilliamson@example.org Fri Aug 01 07:57:39 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 79781 invoked by uid 500); 1 Aug 2003 07:57:36 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 79768 invoked from network); 1 Aug 2003 07:57:35 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 07:57:35 -0000 Received: (qmail 28790 invoked by uid 50); 1 Aug 2003 08:00:22 -0000 Date: 1 Aug 2003 08:00:22 -0000 Message-ID: <ywilliamson@example.org> From: ywilliamson@example.org To: ywilliamson@example.org Cc: Subject: DO NOT REPLY [Bug 14348] - Caching problem with XSP, XSL and cocoon pseudo protocol 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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348>. 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=14348 Caching problem with XSP, XSL and cocoon pseudo protocol ------- Additional Comments From ywilliamson@example.org 2003-08-01 08:00 ------- correction: since the xsp's creation date is 'newer' it isn't updated. From ywilliamson@example.org Fri Aug 01 08:02:54 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 86801 invoked by uid 500); 1 Aug 2003 08:02:53 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 86781 invoked from network); 1 Aug 2003 08:02:53 -0000 Received: from host166-4.pool62211.interbusiness.it (HELO linux.local) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 08:02:53 -0000 Received: from apache.org (localhost [83.161.120.155]) by linux.local (Postfix) with ESMTP id E9DFA84D36 for <ywilliamson@example.org>; Fri, 1 Aug 2003 10:03:03 +0200 (CEST) Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 10:03:03 +0200 From: Gianugo Rabellino <ywilliamson@example.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org Subject: Promotion of [XPath]TraversableGenerators to main trunk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Before the upcoming release, I'd like to promote the TraversableGenerator stuff to the main trunk. There are several things to discuss, though: 1. naming. TraversableGenerator sucks, yes. I guess the best option as of now is SourceHierarchyGenerator, any others? 2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do you think you can take care of that? 3. namespace: is http://apache.org/cocoon/collection/1.0 ok? 4. back-compatibility: should we deprecate DirectoryGenerator? Should we provide a stylesheet to convert the output of Traversable to Directory's? 5. xpath: I'm starting to wonder whether is OK to have a separate XPathTraversableGenerator or if it would be better having a single SourceHierarchyGenerator with (optional) XPath capabilities. How about it? Let's discuss all these issue (and I might well have forgotten some): I think that at a very least we need a [VOTE] on the namespace afterwards. -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/) From ywilliamson@example.org Fri Aug 01 08:04:14 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 88121 invoked by uid 500); 1 Aug 2003 08:04:12 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 88043 invoked from network); 1 Aug 2003 08:04:11 -0000 Received: from unknown (HELO trinity.anyware-tech.com) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 08:04:11 -0000 Received: (qmail 21737 invoked from network); 1 Aug 2003 08:13:46 -0000 Received: from unknown (HELO anyware-tech.com) (83.161.120.155) by trinity.anyware-tech.com with SMTP; 1 Aug 2003 08:13:46 -0000 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 10:04:22 +0200 From: Sylvain Wallez <ywilliamson@example.org> Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: fr, en, en-us MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Garbage or The Quest for the Perfect Template Language References: <ywilliamson@example.org> <ywilliamson@example.org> <ywilliamson@example.org> In-Reply-To: <ywilliamson@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Ugo Cei wrote: > Christopher Oliver wrote: > >> Ugo Cei wrote: >> >>> These days I'm banging my head against the limitations of template >>> languages. I've tried XSP and it's not in any way limited, but it has >>> its share of problems (difficult to debug and offers too many ways to >>> shoot oneself in the foot), JXTemplate{Transformer,Generator} (no >>> way to >>> call methods on context objects, no decent arithmetic) >> >> >> >> What exactly is the problem with the arithmetic in Jexl and/or >> JXPath? What problem did you encounter calling methods? You should be >> able to with do that with both Jexl and JXPath. >> >> Regards, >> >> Chris > > > I'll try to come up with an example but I seem to remember having > problems doing even a simple counter. And WRT calling Java methods, I > must admit I didn't even try it. Since it's not documented I thought > it wasn't even implemented ;-). Checkout the last paragraph of JXPath's PackageFunctions description [1], this may be what you're looking for : the whole classpath is accessible through fully-qualified names. [1] http://jakarta.apache.org/commons/jxpath/apidocs/org/apache/commons/jxpath/PackageFunctions.html Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com From ywilliamson@example.org Fri Aug 01 08:14:00 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 1917 invoked by uid 500); 1 Aug 2003 08:13:59 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 1890 invoked from network); 1 Aug 2003 08:13:58 -0000 Received: from mail.s-und-n.de (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 08:13:58 -0000 Received: from notes.sundn.de (ntsrv5.sundn.de [83.161.120.155]) by mail.s-und-n.de (postfix) with ESMTP id 14BBEAF20 for <ywilliamson@example.org>; Fri, 1 Aug 2003 10:14:10 +0200 (CEST) Received: from hw0386 ([83.161.120.155]) by notes.sundn.de (Lotus Domino Release 5.0.8) with SMTP id 2003080110140591:9653 ; Fri, 1 Aug 2003 10:14:05 +0200 From: "Carsten Ziegeler" <ywilliamson@example.org> To: "Cocoon-Dev" <ywilliamson@example.org> Subject: [Vote] Make Xalan the default xslt processor again [was: RE: Releasing 2.1] Date: Fri, 1 Aug 2003 10:16:07 +0200 Message-ID: <ywilliamson@example.org> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 01.08.2003 10:14:06, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 01.08.2003 10:14:08 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N There are several problems with xsltc which makes Cocoon in some scenarios unusable. We have several problem reports and I know from many customers that they all had to disable xsltc and use xslt in their environment. It's ok to have xsltc as the default for development cycles to help the xalan team find bugs, but I think it's not good to have it as the default for the final release as most users have to change this default setting anyway. So, I'm +1 on making xalan the default for the final release again. What do you think? Carsten Simon H=FCrlimann wrote: > > Am Donnerstag, 31. Juli 2003 17.46 schrieb Joerg Heinicke: > > Some issues: > > > > 1. POI: No real problem, but what about the code move to the POI > > project? They seem to prepare the 2.0 release, so I guess they only have > > no time at the moment ... > > > > 2. XSLTC: Geoff already mentioned it. I know of two heavy bugs in our > > 2.5.1 XSLTC: > > http://nagoya.apache.org/bugzilla/show=5Fbug.cgi?id=3D20308 : stylesheet > > includes, seems to be already fixed in XSLTC CVS. > > http://nagoya.apache.org/bugzilla/show=5Fbug.cgi?id=3D20381 : top-level > > variable with document(). This bug is so annoying because the stylesheet > > "works" in a way, but the cause of the failure is not obvious. And we > > don't know the reason for it until now: XSLTC command line works, Xalan > > works. But if we switch from Xalan to XSLTC in Cocoon the stylesheet > > stops working. > > There's another XSLTC Bug that affects Cocoon. If you use a > cocoon:/ URL in > XSLTs document() function, the URI is prepended by the > stylesheets path. That > was a realy annoying bug that took me quite some time. The only "fix" for > this bug is to switch back to Xalan: > http://nagoya.apache.org/bugzilla/show=5Fbug.cgi?id=3D21857 From ywilliamson@example.org Fri Aug 01 08:50:13 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 48831 invoked by uid 500); 1 Aug 2003 08:50:12 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 48817 invoked from network); 1 Aug 2003 08:50:12 -0000 Received: from mail.s-und-n.de (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 08:50:12 -0000 Received: from notes.sundn.de (ntsrv5.sundn.de [83.161.120.155]) by mail.s-und-n.de (postfix) with ESMTP id CA9ADAE2F2 for <ywilliamson@example.org>; Fri, 1 Aug 2003 10:50:24 +0200 (CEST) Received: from hw0386 ([83.161.120.155]) by notes.sundn.de (Lotus Domino Release 5.0.8) with SMTP id 2003080110502165:9745 ; Fri, 1 Aug 2003 10:50:21 +0200 From: "Carsten Ziegeler" <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: [RT] New Input for woody Date: Fri, 1 Aug 2003 10:52:23 +0200 Message-ID: <ywilliamson@example.org> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) In-Reply-To: <ywilliamson@example.org> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 01.08.2003 10:50:21, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 5.0.8 |June 18, 2001) at 01.08.2003 10:50:22, Serialize ywilliamson@example.org 10:50:22 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Marc Portier wrote: > > <snip/> > as I understood from earlier discussions this also serves as a > form-model-definition (meaning dywel doesn't require an aditional > file for that) More or less: yes - you need the "binding". > > > > How does it work? A component (a java implementation) parses > > the template and the binding file, the first time it's used. > > The template is compiled and the bindings are attached to > > the internal tree representing the template. > > > > could you elaborate on 'attached' > is an instance of the business object involved in this process? No, a tree is created is created with java objects for the different elements or fields used. So you have a java object representing one particular input field. This object gets the binding, so it knows from where to get it's input. But this is only the definition, so the object does not get the business object itself only the string like "user.name". > > A special generator uses the java component and asks it to > > render the page. Now the tree is processed. Each field > > knows how to render itself. To get the values for a > > form field, the field asks the component for the > > value for e.g. "user.name". The component now has > > a getUser() method and the returned user object has > > a getName() method. > > > > this sounds like the business object instance values are only > read at this time... > Exactly. The tree I mentioned above is traversed and the java object for the field gets a "component" and can ask that component for the value of let's say "user.name". > > > For each form or better web page, you have to write > > the java component = controller. You simply inherit > > from a base class and provided methods to get your > > business objects. (I'm looking to simplify this using > > fom when everything else is set). > > So, this solution is tied to java objects (currently). > > > > well, it is tied to a custom-to-be-written java object > > from a distance it looks like you'll need some luck for hooking > up some existing java objects from a long-before-dywel designed > business application (e.g. the validation method, but also the > type of the argument in the setXXX methods, the web is presenting > you with Strings, how is the conversion done? <-- this is the > crux of my current understanding of dywel) Ah, ok, you don't need something in between you can directly connect to existing business objects. E.g. JXPath can do most of the conversions for you, if you have a string with a number and have a setAge(int) the conversion is done for you automatically etc. So most conversions can be done by that, you can set optional formatter objects in the binding that do the conversion for you, e.g. for date objects. > > if that is the case then one is going to need to write a specific > javabean to accomodate for the intermediate step before actually > talking to the legacy backend system No, as explained above. > > woody's proposition is to use not Java code but the > form-definition file to describe this intermediate model... AFAIU > both approaches use this kind of intermediate stage as a basis > for validation and string-type conversion > > (remembering Bruno's recent rumblings on jxpath addressing inside > form-widgets the line could get very thin) > > > Now, it is possible to specify additional validation and > > formatting in the binding, like: > > <dywel:binding id="street"> > > <value>user.address.city</value> > > <validation>a rule</validation> > > <formatter>a formatter</formatter> > > </dywel:binding> > > > > etc. > > similar > > I'm still looking for the reverse of the formatter (string to type?) The formatter does both. > > As I see it now, the integration is not trivial (but possible) > Your bean seems to provide an alternative to the declarative > woody-widget tree (form-model) > > We could argue about the woody-widget tree being the real CORE of > woody, so the 'not trivial' gets to have some meaning I guess :-) > > 'Integration' then becomes making the form-model pluggable which > would come down to > 1/ making the woody-template-transformer can pull out the values > using jxpath rather then using the widget API > 2/ and the other way around the form.process(request) needs to > evolve to Dywel.process(bean-or-widgetTree, request); which could > again use some jxpath-like approach to perform its setValues... > > not trivial, maybe possible, useful? Hmm, I'm a little unsure. Now, I don't want to destroy the design of woody only to make me happy. If it makes sense, to change woody: great. If it doesn't, well, then I can live with that as well. It's a decision I'm currently not able to make or contribute to. I think, currently if Dywel will ever work sometime in the distant future, it's more elegant to connect to existing business objects than woody; but on the other hand woody has great advantage in all the other form areas where you don't connect to business objects. Carsten From ywilliamson@example.org Fri Aug 01 09:03:07 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 65200 invoked by uid 500); 1 Aug 2003 09:03:05 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 65173 invoked from network); 1 Aug 2003 09:03:04 -0000 Received: from unknown (HELO mail.cbim.it) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:03:04 -0000 Received: from cuprouter.cbim.it (cuprouter.cbim.it [83.161.120.155]) by mail.cbim.it (8.11.6/8.11.0) with ESMTP id h719QcG16825 for <ywilliamson@example.org>; Fri, 1 Aug 2003 11:26:39 +0200 Received: from cbim.it (caterina.cbim.it [83.161.120.155]) by cuprouter.cbim.it (8.9.3/8.9.3) with ESMTP id LAA28594 for <ywilliamson@example.org>; Fri, 1 Aug 2003 11:03:49 +0200 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 11:05:08 +0200 From: Ugo Cei <ywilliamson@example.org> Organization: C.B.I.M. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030314 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Garbage or The Quest for the Perfect Template Language References: <ywilliamson@example.org> <ywilliamson@example.org> <ywilliamson@example.org> <ywilliamson@example.org> In-Reply-To: <ywilliamson@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sylvain Wallez wrote: > Checkout the last paragraph of JXPath's PackageFunctions description > [1], this may be what you're looking for : the whole classpath is > accessible through fully-qualified names. Uh, cool. This deserves to be documented more clearly. I'll try to find the time to do it. Ugo -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica P.le Volontari del Sangue, 2 - 27100 Pavia - Italy Phone: 523.542.2966 - E-mail: ywilliamson@example.org From ywilliamson@example.org Fri Aug 01 09:14:57 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 73463 invoked by uid 500); 1 Aug 2003 09:14:54 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 73446 invoked from network); 1 Aug 2003 09:14:53 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:14:53 -0000 Received: (qmail 18592 invoked by uid 65534); 1 Aug 2003 09:15:05 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp003) with SMTP; 01 Aug 2003 11:15:05 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: [Vote] Make Xalan the default xslt processor again [was: RE: Releasing 2.1] Date: Fri, 1 Aug 2003 11:15:16 +0200 Message-ID: <003001c3580d$6ca13830$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <ywilliamson@example.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: Carsten Ziegeler > There are several problems with xsltc which makes Cocoon in > some scenarios unusable. We have several problem reports and > I know from many customers that they all had to disable xsltc > and use xslt in their environment. > > It's ok to have xsltc as the default for development cycles > to help the xalan team find bugs, but I think it's not good > to have it as the default for the final release as most users > have to change this default setting anyway. > > So, I'm +1 on making xalan the default for the final release again +1 too for the release (XSLTC is hell if you use namespaces) then we should set XSLTC as default xslt processor again. Cheers, Reinhard From ywilliamson@example.org Fri Aug 01 09:14:58 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 73666 invoked by uid 500); 1 Aug 2003 09:14:57 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 73619 invoked from network); 1 Aug 2003 09:14:56 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:14:56 -0000 Received: (qmail 18704 invoked by uid 65534); 1 Aug 2003 09:15:06 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp003) with SMTP; 01 Aug 2003 11:15:06 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor] Date: Fri, 1 Aug 2003 11:15:16 +0200 Message-ID: <003101c3580d$6daf9af0$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <ywilliamson@example.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > For the actual code see > http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900 Marc, why don't you put Apples it into scratchpad? Cheers, Reinhard From ywilliamson@example.org Fri Aug 01 09:15:02 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 74028 invoked by uid 500); 1 Aug 2003 09:15:00 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 73934 invoked from network); 1 Aug 2003 09:15:00 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:15:00 -0000 Received: (qmail 18930 invoked by uid 65534); 1 Aug 2003 09:15:10 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp003) with SMTP; 01 Aug 2003 11:15:10 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: Releasing 2.1 Date: Fri, 1 Aug 2003 11:15:16 +0200 Message-ID: <003201c3580d$6fda6a30$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <ywilliamson@example.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: Carsten Ziegeler > I just want to collect opinions how to manage the final release. > > Now, it seems 2.1rc1 is relative stable, no real complains, > some minor issues but no showstoppers. From that we could > say: the current cvs is the final version. point. I don't > think we need a rc2. > > Should we take before we do the release some actions? Like... > ..updating docs ..changing readme ..asking users for testing > (which was a success for 2.0.3 and 2.0.4) etc. IMO there are two important issues: - the docs must reflect that Cocoon is not a publishing framework _only_ - decide what we do with alpha blocks and scratchpad I would exclude them from the build properties by default Cheers, Reinhard > > Whatever we do, I think a timeframe of two weeks is good, so > I suggest a final release on tuesday, 12th. > > Carsten > > From ywilliamson@example.org Fri Aug 01 09:15:05 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 74238 invoked by uid 500); 1 Aug 2003 09:15:04 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 74176 invoked from network); 1 Aug 2003 09:15:03 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:15:03 -0000 Received: (qmail 7335 invoked by uid 65534); 1 Aug 2003 09:15:15 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp001) with SMTP; 01 Aug 2003 11:15:15 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: Releasing 2.1 Date: Fri, 1 Aug 2003 11:15:26 +0200 Message-ID: <003301c3580d$72a263d0$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <ywilliamson@example.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: Carsten Ziegeler > I just want to collect opinions how to manage the final release. > > Now, it seems 2.1rc1 is relative stable, no real complains, > some minor issues but no showstoppers. From that we could > say: the current cvs is the final version. point. I don't > think we need a rc2. > > Should we take before we do the release some actions? Like... > ..updating docs ..changing readme ..asking users for testing > (which was a success for 2.0.3 and 2.0.4) etc. IMO there are two important issues: - the docs must reflect that Cocoon is not a publishing framework _only_ - decide what we do with alpha blocks and scratchpad I would exclude them from the build properties by default Cheers, Reinhard > > Whatever we do, I think a timeframe of two weeks is good, so > I suggest a final release on tuesday, 12th. > > Carsten > > From ywilliamson@example.org Fri Aug 01 09:16:08 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 76843 invoked by uid 500); 1 Aug 2003 09:16:08 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 76816 invoked from network); 1 Aug 2003 09:16:07 -0000 Received: from dobit2.ugent.be (HELO dobit2.rug.ac.be) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:16:07 -0000 Received: from allserv.UGent.be (allserv.ugent.be [83.161.120.155]) by dobit2.rug.ac.be (8.12.8/8.12.8) with ESMTP id h719GGbs004703 for <ywilliamson@example.org>; Fri, 1 Aug 2003 11:16:16 +0200 (MEST) Received: from otsrv1.iic.rug.ac.be (otsrv1.iic.ugent.be [83.161.120.155]) by allserv.UGent.be (8.12.8/8.12.8) with ESMTP id h719GGJx009612 for <ywilliamson@example.org>; Fri, 1 Aug 2003 11:16:16 +0200 (MEST) Received: from outerthought.org (host104 [83.161.120.155]) by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h719GGx24830 for <ywilliamson@example.org>; Fri, 1 Aug 2003 11:16:16 +0200 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 11:16:15 +0200 From: Steven Noels <ywilliamson@example.org> Organization: Outerthought User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor] References: <003101c3580d$6daf9af0$7953efd9@WRPO> In-Reply-To: <003101c3580d$6daf9af0$7953efd9@WRPO> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 1/08/2003 11:15 Reinhard Pötz wrote: > >>For the actual code see >>http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=21900 > > > Marc, why don't you put Apples it into scratchpad? Karma request is in process, he isn't listed in the avail file yet. </Steven> -- Steven Noels http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/stevenn/ ywilliamson@example.org ywilliamson@example.org From ywilliamson@example.org Fri Aug 01 09:21:36 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 80427 invoked by uid 500); 1 Aug 2003 09:21:35 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 80412 invoked from network); 1 Aug 2003 09:21:35 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:21:35 -0000 Received: (qmail 5633 invoked by uid 65534); 1 Aug 2003 09:21:47 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp001) with SMTP; 01 Aug 2003 11:21:47 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor] Date: Fri, 1 Aug 2003 11:21:58 +0200 Message-ID: <003401c3580e$5c0f5140$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <ywilliamson@example.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: Steven Noels > On 1/08/2003 11:15 Reinhard P=F6tz wrote: > >=20 > >>For the actual code see > >>http://nagoya.apache.org/bugzilla/show_> bug.cgi?id=3D21900 > >=20 > >=20 > > Marc, why don't you put Apples it into scratchpad? >=20 > Karma request is in process, he isn't listed in the avail file yet. Ah, thanks! I thought that those things have already happend. Reinhard From ywilliamson@example.org Fri Aug 01 09:34:22 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 91931 invoked by uid 500); 1 Aug 2003 09:34:21 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 91918 invoked from network); 1 Aug 2003 09:34:21 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:34:21 -0000 Received: (qmail 739 invoked by uid 50); 1 Aug 2003 09:37:10 -0000 Date: 1 Aug 2003 09:37:10 -0000 Message-ID: <ywilliamson@example.org> From: ywilliamson@example.org To: ywilliamson@example.org Cc: Subject: DO NOT REPLY [Bug 22042] New: - [PATCH] LDAPTransformer 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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22042>. 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=22042 [PATCH] LDAPTransformer Summary: [PATCH] LDAPTransformer Product: Cocoon 2 Version: 2.1m3 Platform: Other OS/Version: Linux Status: NEW Severity: Normal Priority: Other Component: core AssignedTo: ywilliamson@example.org ReportedBy: ywilliamson@example.org Now LDAPTransformer supports 'modify attribute' and 'add attribute' methods. 'Modify attribute' method, in additional, supports the 'append' modify mode. LDAPTransformer now can works without any search filter (with full path) also. From ywilliamson@example.org Fri Aug 01 09:36:47 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 96771 invoked by uid 500); 1 Aug 2003 09:36:46 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 96725 invoked from network); 1 Aug 2003 09:36:46 -0000 Received: from exchange.sun.com (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:36:46 -0000 Received: (qmail 787 invoked by uid 50); 1 Aug 2003 09:39:34 -0000 Date: 1 Aug 2003 09:39:34 -0000 Message-ID: <ywilliamson@example.org> From: ywilliamson@example.org To: ywilliamson@example.org Cc: Subject: DO NOT REPLY [Bug 22042] - [PATCH] LDAPTransformer 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 <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22042>. 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=22042 [PATCH] LDAPTransformer ------- Additional Comments From ywilliamson@example.org 2003-08-01 09:39 ------- Created an attachment (id=7612) With this patch, LDAPTransformer supports the add and modify attribute methods From ywilliamson@example.org Fri Aug 01 09:48:38 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 6669 invoked by uid 500); 1 Aug 2003 09:48:37 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 6656 invoked from network); 1 Aug 2003 09:48:36 -0000 Received: from mail.gmx.de (HELO mail.gmx.net) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 09:48:36 -0000 Received: (qmail 18850 invoked by uid 65534); 1 Aug 2003 09:48:49 -0000 Received: from pD9EF5379.dip0.t-ipconnect.de (EHLO WRPO) (83.161.120.155) by mail.gmx.net (mp021) with SMTP; 01 Aug 2003 11:48:49 +0200 Reply-To: <ywilliamson@example.org> From: =?iso-8859-1?Q?Reinhard_P=F6tz?= <ywilliamson@example.org> To: <ywilliamson@example.org> Subject: Paginator and ImageReader --> core components? Date: Fri, 1 Aug 2003 11:48:59 +0200 Message-ID: <003501c35812$22f1bf70$7953efd9@WRPO> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Quick question: Is there a reason why the paginator and the image reader are part of Cocoon core and not put into blocks? I'm asking because if you call http://localhost:8888/samples/ you get the impression that they are major parts of Cocoon ... Reinhard From ywilliamson@example.org Fri Aug 01 10:13:35 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 35387 invoked by uid 500); 1 Aug 2003 10:13:35 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 35372 invoked from network); 1 Aug 2003 10:13:34 -0000 Received: from unknown (HELO trinity.anyware-tech.com) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 10:13:34 -0000 Received: (qmail 26571 invoked from network); 1 Aug 2003 10:23:11 -0000 Received: from unknown (HELO anyware-tech.com) (83.161.120.155) by trinity.anyware-tech.com with SMTP; 1 Aug 2003 10:23:11 -0000 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 12:13:46 +0200 From: Sylvain Wallez <ywilliamson@example.org> Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: fr, en, en-us MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's form definition) References: <ywilliamson@example.org> <ywilliamson@example.org> <ywilliamson@example.org> <ywilliamson@example.org> In-Reply-To: <ywilliamson@example.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Marc Portier wrote: > Sylvain Wallez wrote: > >> Andreas Hochsteger wrote: >> >>> Hi! >>> >>> A short question comes to my mind, while reading your RT: >>> Is it possible to use data types which are composed of several HTML >>> input fields? >>> We are currently using three input fields for dates (day, month, >>> year) at our current form solution. >>> >>> Thanks for clearification! >> >> >> >> >> Marc explained how this can technically occur using AggregatedField. >> >> Now from a more semantical point of view, AggregateField is something >> I'm not very comfortable with. Let's consider its two use cases : >> >> 1/ Phone number example >> In this example, the displayed form shows only one input box, and its >> value is split into several non-visual subfields used by the >> application (country code, area code, number). Do these non-visual >> subfields really belong to the form definition if it never displays >> them ? Doesn't this split belong to the binding more than to the form >> definition ? >> >> 2/ Date split in several inputs >> The day/month/year inputs are just a particular visual implementation >> of a date widget (in the GUI meaning of "widget"). What if we finally >> decide to use a calendar popup instead of 3 inputs ? Do we have to >> change all form definitions ? >> >> Maybe that's just nitpicking, but I find this somewhat breaks Woody's >> clean SoC. >> > > Touché. ;-) Actually, this is something I was uncomfortable with right from the beginning, but did not want to throw on the table immediately as it's rather peripheral. > Indeed: The aggregatefield was only introduced when we started > thinking about binding... however, by now I have learned to appreciate > the concept as having its own value in the woody-model > > You are right: it does somewhat hook up some back-end business-model > vision onto the form-fields...but then again the (other) discussion we > are having on the business-model-specific datatyping and even > business-model-specific-validation does introduce the same level of > mixing, no? Yes and no. Yes, because business-model-specific-validation introduces the application into the form definition, but no as it does not impact the structure of the form (i.e. the number of widgets it contains). > And while we try to manage the good SoC here, the reality of the app > will always be that people *know* (influenced by their business-domain > knowledge on the app they write) about these aggregations when they > model the form. And not unlikely the form will need to be able to > exploit that knowledge. > (In fact I guess that the reality vision expressed above is the real > drive behind your current effort to make Woody more lightweight and > generally usable?) > > Purely technical I have also the following argument: I expressed > earlier that the Woody model should be seen as the insulation layer > between how the end user sees things and how the business-models need > to be presented... now, I'm ready to change that into: it is the > insulation-POINT where the two worlds are meeting. > > The Woody form-model is what sits in between how the end-user consumes > and edits his HTML-form and how the back-end presents and expects > business data... > > On the HTML form there is weak typing (only strings) and weak > structuring (only a map-like structure of request-params) compared to > the back-end view of things (rigid structure of staticly typed values) > > The Woody-form-model takes up the responsibility of making the match > between both, therefor it largely needs to know everything about both! > (maybe this explains why it is perceived heavy at first glance?) > > So it needs > - datatype knowledge and convertors (doing the string to YourType in 2 > directions) > - validation rules (making sure we're not handing over gibberish to > the backend-model) > - mapping pointers into the backend-structure (binding) > - ... > > What the introduction of the Aggregate-field is adding to the show is > something I would call 'granularity of information', and to date I'm > convinced that the woody-model needs to be aware of the smallest > granularity either it be imposed by the end-user view or the back-end > structure: > > 1/ phone number example: > end-user sees 1 field > back-end expects 3 distinct ones (ctr, zone, local) > --> imposed granularity == 3 > > 2/ date example > end-user sees 3 fields (day, month, year) > back-end expects 1 > --> imposed granularity == 3 > > The above also illustrates that the usage of the aggregate-field will > only be useful to people actually having the intent to map stuff onto > a backend-business model. > (but by now we already aggreed(?) that such is not really tied to > actually using the declarative data mapping provided by the binding) > > What do you think? This technically makes sense, but I'm not comfortable with the actual widget implementation having an impact on the form definition... > I also like the practical consequences introduced by the > aggregate-field notion: > > - it becomes a template-designer choice to present the date as one > field or as separate fields In fact, I think there can be various interpretation of the "template-designer" role. It seems like you consider the template designer more like an HTML-guy, while I my experience shows that he's more an application-domain-related guy. What I'd like to achieve is to have the form template define the overall form layout (fieldsets, columns, etc) but not the details of the layout, especially for low-level widgets. IMO, the form designer should not have to worry about the fact that the date input is actually implemented using a combination of 3 popups instead of a single input. Moreover, requiring the form designer to explicitely write these 3 popups in the template each time a date input is needed will certainly lead to inconsistencies in the GUI. So actually, what I'd like to see in the form template for this date example is : <wt:field id="startDate"><date/></wt:field> <wt:field id="endDate"><date/></wt:field> Which should be expanded into : <wi:field id="birthDate"> <wi:style><date/></wi:style> <wi:field id="birthDate.year"/> <wi:field id="birthDate.month"/> <wi:field id="birthDate.day"/> </wi:field> <wi:field id="endDate"> <wi:style><date/></wi:style> <wi:field id="birthDate.year"/> <wi:field id="birthDate.month"/> <wi:field id="birthDate.day"/> </wi:field> This can be easily achieved if we consider two types of AggregateField that are SAXed differently : - app-related aggregation (phone-number) : child fields are non-visual, an only the aggregating widget is output - GUI-related aggregation (date) : child fields are visual, but not explicitely written in the template, and the aggregating widet SAXes them as part of it's own SAX production. Now we still have a problem on the form-definition part : just as it would be painful to write all 3 subfields in the template each time we have a date, it is also painful to write them in the form declaration. Plus the usual consistency problems. After the datatype and format catalogues, what is coming here is a catalogue for reusable field definitions ! Catalogue : <wd:aggregate-field id="date-template"> <wd:field id="year"/> <wd:field id="month"/> <wd:field id="day"/> </wd:aggregate-field> Form definition : <wd:field id="startDate" extends="date-template"> <wi:label>Start date</wi:label> </wd:field> </wd:field id="endDate" extends="date-template"> <wi:label>End date</wi:label> </wd:field> ... or should both the form definition and template go through and transformation (XSL or STX) that "expands" the widgets ? That's a more immediate solution, but introduces new pipelines and "cocoon:" sources for the definition and template. What do you think ? > - it allows for (maybe easier) validation rules on the split parts Sure ! > - it made writing the binding-stuff so easy that I could do it :-) > (now you see how I do all effort not to overload Bruno ;-)) Which confirms the previous point. Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com From ywilliamson@example.org Fri Aug 01 10:19:25 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 44506 invoked by uid 500); 1 Aug 2003 10:19:24 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 44486 invoked from network); 1 Aug 2003 10:19:23 -0000 Received: from unknown (HELO trinity.anyware-tech.com) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 10:19:23 -0000 Received: (qmail 26811 invoked from network); 1 Aug 2003 10:29:01 -0000 Received: from unknown (HELO anyware-tech.com) (83.161.120.155) by trinity.anyware-tech.com with SMTP; 1 Aug 2003 10:29:01 -0000 Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 12:19:36 +0200 From: Sylvain Wallez <ywilliamson@example.org> Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: fr, en, en-us MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Promotion of [XPath]TraversableGenerators to main trunk References: <ywilliamson@example.org> In-Reply-To: <ywilliamson@example.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Gianugo Rabellino wrote: > Before the upcoming release, I'd like to promote the > TraversableGenerator stuff to the main trunk. There are several things > to discuss, though: > > 1. naming. TraversableGenerator sucks, yes. I guess the best option as > of now is SourceHierarchyGenerator, any others? +1 for SourceHierarchyGenerator > 2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do > you think you can take care of that? Sorry, I should have done this before. Will do it today. > 3. namespace: is http://apache.org/cocoon/collection/1.0 ok? Mmmh... "collection" it a bit too vague IMO. Why not keeping the current "directory" namespace ? > 4. back-compatibility: should we deprecate DirectoryGenerator? Should > we provide a stylesheet to convert the output of Traversable to > Directory's? There's no need to convert if we keep the current namespace. This would allow a smooth transition by just changing the class name in <map:generator> > 5. xpath: I'm starting to wonder whether is OK to have a separate > XPathTraversableGenerator or if it would be better having a single > SourceHierarchyGenerator with (optional) XPath capabilities. How about > it? Dunno... Sylvain -- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } Orixo, the opensource XML business alliance - http://www.orixo.com From ywilliamson@example.org Fri Aug 01 10:29:42 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 51915 invoked by uid 500); 1 Aug 2003 10:29:42 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 51896 invoked from network); 1 Aug 2003 10:29:41 -0000 Received: from vern.chem.tu-berlin.de (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 10:29:41 -0000 Received: from vern.chem.tu-berlin.de (localhost [83.161.120.155]) by vern.chem.tu-berlin.de (8.12.3/8.12.3/SuSE Linux 0.6) with ESMTP id h71ATrGD008437 for <ywilliamson@example.org>; Fri, 1 Aug 2003 12:29:53 +0200 Received: from localhost (stephan@localhost) by vern.chem.tu-berlin.de (8.12.3/8.12.3/Submit) with ESMTP id h71ATrc3008434 for <ywilliamson@example.org>; Fri, 1 Aug 2003 12:29:53 +0200 X-Authentication-Warning: vern.chem.tu-berlin.de: stephan owned process doing -bs Date: Fri, 1 Aug 2003 12:29:53 +0200 (CEST) From: Stephan Michels <ywilliamson@example.org> X-X-Sender: ywilliamson@example.org To: ywilliamson@example.org Subject: Re: Promotion of [XPath]TraversableGenerators to main trunk In-Reply-To: <ywilliamson@example.org> Message-ID: <{{EMAIL+PHONE}}> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 1 Aug 2003, Sylvain Wallez wrote: > Gianugo Rabellino wrote: > > > Before the upcoming release, I'd like to promote the > > TraversableGenerator stuff to the main trunk. There are several things > > to discuss, though: > > > > 1. naming. TraversableGenerator sucks, yes. I guess the best option as > > of now is SourceHierarchyGenerator, any others? > > > +1 for SourceHierarchyGenerator > > > 2. merge Sylvain's stuff (caching, directory filter...). Sylvain, do > > you think you can take care of that? > > > Sorry, I should have done this before. Will do it today. > > > 3. namespace: is http://apache.org/cocoon/collection/1.0 ok? > > > Mmmh... "collection" it a bit too vague IMO. Why not keeping the current > "directory" namespace ? At least, we should agree on one name SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0 SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0 SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0 or DirectoryGenerator. My 2cents, Stephan. From ywilliamson@example.org Fri Aug 01 10:38:41 2003 Return-Path: <ywilliamson@example.org> Delivered-To: ywilliamson@example.org Received: (qmail 60452 invoked by uid 500); 1 Aug 2003 10:38:41 -0000 Mailing-List: contact ywilliamson@example.org; run by ezmlm Precedence: bulk list-help: <mailto:ywilliamson@example.org> list-unsubscribe: <mailto:ywilliamson@example.org> list-post: <mailto:ywilliamson@example.org> Reply-To: ywilliamson@example.org Delivered-To: mailing list ywilliamson@example.org Received: (qmail 60437 invoked from network); 1 Aug 2003 10:38:40 -0000 Received: from host166-4.pool62211.interbusiness.it (HELO linux.local) (83.161.120.155) by daedalus.apache.org with SMTP; 1 Aug 2003 10:38:40 -0000 Received: from apache.org (localhost [83.161.120.155]) by linux.local (Postfix) with ESMTP id E7B0684D36 for <ywilliamson@example.org>; Fri, 1 Aug 2003 12:38:38 +0200 (CEST) Message-ID: <ywilliamson@example.org> Date: Fri, 01 Aug 2003 12:38:38 +0200 From: Gianugo Rabellino <ywilliamson@example.org> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ywilliamson@example.org Subject: Re: Promotion of [XPath]TraversableGenerators to main trunk References: <{{EMAIL+PHONE}}> In-Reply-To: <{{EMAIL+PHONE}}> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Stephan Michels wrote: > >> >>Mmmh... "collection" it a bit too vague IMO. Why not keeping the current >>"directory" namespace ? > > > At least, we should agree on one name > > SourceHierarchyGenerator -> http://apache.org/cocoon/hierachy/1.0 > SourceCollectionGenerator -> http://apache.org/cocoon/collection/1.0 > SourceDirectoryGenerator -> http://apache.org/cocoon/directory/1.0 > > or DirectoryGenerator. > Makes sense. I'm a bit against using "directory" since it's definitely filesystem oriented. Both WebDAV and XML:DB have the more generic concept of "collection" and "resource", which I like. I now tend to think that, semantically, the best option is to use "hierarchy" and have the output as: <hierarchy:hierarchy> <hierarchy:collection name="cocoon-2.1"> <hierarchy:resource name="build.xml"/> <hierarchy:collection name="src"> <hierarchy:resource name="Cocoon.java"/> </hierarchy:collection> </hierarchy:collection> </hierarchy:hierarchy> How does it sound? -- Gianugo Rabellino
{'source': 'Apache Software Foundation Public Mail Archives'}