Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 66706 invoked from network); 5 Apr 2004 14:39:38 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 5 Apr 2004 14:39:38 -0000 Received: (qmail 5004 invoked by uid 500); 5 Apr 2004 14:39:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 4803 invoked by uid 500); 5 Apr 2004 14:39:27 -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 4781 invoked from network); 5 Apr 2004 14:39:27 -0000 Received: from unknown (HELO apache.org) (217.112.237.100) by daedalus.apache.org with SMTP; 5 Apr 2004 14:39:27 -0000 Message-ID: <40716F9F.2050604@apache.org> Date: Mon, 05 Apr 2004 16:39:27 +0200 From: Sylvain Wallez Organization: Anyware Technologies User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: fr, en, en-us MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: disabling widgets References: <407142EA.9000906@apache.org> <4071596F.8040703@reverycodes.com> <407161B4.2070206@apache.org> <4071782E.6070306@reverycodes.com> In-Reply-To: <4071782E.6070306@reverycodes.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Vadim Gritsenko wrote: > Sylvain Wallez wrote: > >> Vadim Gritsenko wrote: >> >>> Sylvain Wallez wrote: >>> >>>> Now, as I mentioned already [1], I started using the generator >>>> approach >>>> to form templates, using the implementation of "wt:" statements using >>>> JXMacro provided by Chris [2]. And this approach is very powerful, >>>> as it >>>> allows complex conditional form layout without requiring the >>>> introduction of yet-another-control-structure-markup in the "wt:" >>>> namespace. >>>> >>>> Introducing the widget states would allow these conditions to be >>>> computed with the form's own state rather than using some separate >>>> flow >>>> values. >>>> >>>> So, I propose the following changes to Cocoon forms: >>>> - add a state to widgets (enabled/disabled/hidden). >>>> >>>> >>> >>> Assuming this state will be available during binding, as well as in >>> form... +1. But, this will require some kind of "wt:" control markup >>> anyway... Given simple example: >>>
>> id="x"/>
>>> >>> There is a need to disable whole table, it's not enough to take out >>> widget only. >> >> >> This is exactly why a generator approach is needed : > > > Well, of course it will work with generator. But what if generator can > not be used in this scenario (xslt processing required; use of other > template engine; something else), what then? Either it should be also > possible with JXTemplateTransformer, or FormsTransformer to be > extended, or (ideally) both of those. The source of your generator can be a "cocoon:". This has the benefit (if the "cocoon:" is cacheable) that you don't necessarily have recompile the template like what would be needed with a transformer. > Also, what do you think about something to allow generation of >