Return-Path: Delivered-To: apmail-cocoon-docs-archive@www.apache.org Received: (qmail 44704 invoked from network); 15 May 2004 01:00:14 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 15 May 2004 01:00:14 -0000 Received: (qmail 73131 invoked by uid 500); 15 May 2004 01:00:40 -0000 Delivered-To: apmail-cocoon-docs-archive@cocoon.apache.org Received: (qmail 73104 invoked by uid 500); 15 May 2004 01:00:39 -0000 Mailing-List: contact docs-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: docs@cocoon.apache.org Delivered-To: mailing list docs@cocoon.apache.org Received: (qmail 73085 invoked by uid 98); 15 May 2004 01:00:39 -0000 Received: from stevenn@outerthought.org by hermes.apache.org by uid 82 with qmail-scanner-1.20 (clamuko: 0.70. Clear:RC:0(157.193.121.51):. Processed in 0.275745 secs); 15 May 2004 01:00:39 -0000 X-Qmail-Scanner-Mail-From: stevenn@outerthought.org via hermes.apache.org X-Qmail-Scanner: 1.20 (Clear:RC:0(157.193.121.51):. Processed in 0.275745 secs) Received: from unknown (HELO otsrv1.iic.ugent.be) (157.193.121.51) by hermes.apache.org with SMTP; 15 May 2004 01:00:39 -0000 Received: from otsrv1.iic.ugent.be (localhost [127.0.0.1]) by otsrv1.iic.ugent.be (8.11.6/8.11.6) with ESMTP id i4F103O15609 for ; Sat, 15 May 2004 03:00:04 +0200 Date: Sat, 15 May 2004 03:00:04 +0200 Message-Id: <200405150100.i4F103O15609@otsrv1.iic.ugent.be> From: stevenn@outerthought.org To: docs@cocoon.apache.org Subject: [WIKI-UPDATE] Limpy Sat May 15 03:00:03 2004 X-Spam-Rating: hermes.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Page: http://wiki.cocoondev.org/Wiki.jsp?page=Limpy , version: 5 on Fri May 15 00:11:08 2004 by JonasEkstedt - There is a lot of cool stuff one can do with DOM. After having read a bit about it I started building a widget framework based on DOM. The advantages are several. Using a DOM to model all widgets one gets the benefits of DOM Event handling, DOM Traversal and XML schema all for free with hardly any effort on the programmer. ? ---- + There is a lot of cool stuff one can do with DOM. After having read a bit about it I started building a widget framework based on DOM. The advantages are several. Using a DOM to model widgets one gets the benefits of DOM Event handling, DOM Traversal and XML schema all for free with hardly any effort on the programmer. - I put this up here in case anyone would be interested in it. It is only proof-of-concept stuff and definitely not suitable for anything else than playing around with. + I put this up here in case anyone would be interested in it. It's not thouroughly tested yet so it is only usable for playing around with. - Using Limpy is very similar to using woody/cforms. You write a definition file containing the widget structure. A template file places those widgets on a page and a transformer does all the magic. As a last step you XSL transform the widgets to HTML elements. I'll try and outline a simple usage scenario below. ? - ^^ -- + Using Limpy is very similar to using woody/cforms. You write a definition file containing the widget structure. A template file lays out the widgets on a page and a transformer does all the magic. As a last step you XSL transform the widgets to HTML elements. I'll try and outline a simple usage scenario below. ? ^ ++++ - * li:template is reserved + * Elements outside the "li:" namespace (and all their descendants) will be ignored - As you can see the id of a widget is the parent id + its name. In the DOM the @id is also made to be a proper ID. That means that retrieving a specific widget in the DOM is dead easy. Simply do {{Element formWidget = document.getElementById("app/form")}}, no need for traversing the entire tree when searching for widgets. + As you can see the id of a widget is the parent id + "/" + its name. In the DOM the @id is also made to be a proper ID. That means that retrieving a specific widget in the DOM is dead easy. Simply do: + + {{Element formWidget = document.getElementById("app/form")}} - The transformer does very little. If we take a template ? ^ + The transformer does very little. If we use the definition above and the template: ? ++++ ++++++++++++++ ^^^ ++++++ + - The transformer simply replace all with the corresponding element from the widget definition. Note that you can adress widgets both by its id as in {{}} or by its name {{}}. In the latter case the transformer will look for the widget in the parent widgets context. + The transformer simply replace all with the corresponding element from the widget definition. Note that you can adress widgets both by its id as in {{}} or by its name {{}}. In the latter case the transformer will look for the widget in the parent widgets context. Limpy supports adressing of parent widgets, as in ? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ - The transformer also supports hiding widgets that have @active=false. Suppose before transformation we did this in flow {{tree.setAttribute("app/form", "active", "false")}} then the transformed template would be: + The transformer also supports hiding widgets that has @active=false. Suppose before transformation we did this in flow: + + {{tree.setAttribute("app/form", "active", "false")}} + + then the transformed template would be: - + * Build cocoon and make sure you include the forms block