Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 74684 invoked from network); 23 Sep 2004 08:49:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 23 Sep 2004 08:49:32 -0000 Received: (qmail 88384 invoked by uid 500); 23 Sep 2004 08:49:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88256 invoked by uid 500); 23 Sep 2004 08:49: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 88241 invoked by uid 99); 23 Sep 2004 08:49:27 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from [213.252.141.121] (HELO mail.juwimm.de) (213.252.141.121) by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 23 Sep 2004 01:49:26 -0700 Received: from localhost (localhost [127.0.0.1]) by mail.juwimm.de (Juwimm Mail-Exchanger) with ESMTP id E6EB51684D7 for ; Thu, 23 Sep 2004 10:49:23 +0200 (CEST) Received: from [10.0.0.226] (unknown [10.0.0.226]) by mail.juwimm.de (Juwimm Mail-Exchanger) with ESMTP id A08A91684B0 for ; Thu, 23 Sep 2004 10:49:19 +0200 (CEST) Message-ID: <41528E0F.90009@juwimm.com> Date: Thu, 23 Sep 2004 10:49:19 +0200 From: Claudius Spellmann User-Agent: Thunderbird 0.6 (Windows/20040502) X-Accept-Language: de-de, de-at, de, en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Widget states: let's do it (was Re: CForms making widgets invisible) References: <41514D5B.20709@juwimm.com> <415186AA.50601@apache.org> <41519897.6020400@upaya.co.uk> <4151A59A.2040902@apache.org> <415280C3.8060402@juwimm.com> <4152872D.4090904@apache.org> In-Reply-To: <4152872D.4090904@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Juwi|MacMillan X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Sylvain Wallez schrieb: > Claudius Spellmann wrote: > >> Sylvain Wallez schrieb: > > > > > >>> Mmmh... we could say that validation is not performed on >>> disabled/invisible widgets and their children. But this may cause >>> some forms to appear falsely valid, as non-enabled widgets may be >>> required and/or have validators that use values of other widgets. >>> >>> So I would better go the safer way, which is to validate *all* widgets. >>> >>> As for wizards, we could have an additional method on the JS Form >>> object that, instead of handling the whole form at once, may handle >>> it's first-level children which may be widget groups for each page >>> of the wizard. >>> >>> Sylvain >>> >> Ok if a widget is set invisible it is not rendered by cocoon but that >> doesn't mean that the widget is not existing in the widget container >> so if a widget is required and not visible but still exists in the >> container does mean it could be validated ???? > > > > Yes. > >> What about following widget states: enabled (default) < disabled < >> hidden < invisible >> The difference between hidden and invisible would be that hidden is >> still rendered but with an hidden attribute in the declaration and >> would go through the validation process. Invisible on the other side >> could be taken of the form completly and while a widget is in an >> invisible state all validation would be switched off. This way every >> user could decide wether they want to use validation or not and the >> output still would look the same. > > > > Interesting thoughts. But as we saw previously, "hidden" has an > implied meaning because of its use for in HTML > and I'd like to avoid it. > > What you're describing here is a widget state that is even less > visible than invisible, since no validation occurs. What about a > "phantom" state, where the widget exists but isn't validated? > > BTW, overnight I finally felt that "enabled" being the negation of > "disabled" can lead to confusion as when we have to talk about a > widget that's not in "enable" state, the natural word that comes is > "disabled" which is only one of the particular possible states for a > non-enabled widget. So in the end, I think "active" is better than > "enabled". > > That would lead to: > active (default) < disabled < invisible < phantom > > Thoughts? > > Sylvain > Ok sounds good to me What would happen when an invisible field doesn't pass validation and the enduser of a running system doesn't know that he's made a mistake entering data. The point I'm trying to make is that informing endusers about validation errors could be a tricky issue becausae a user can't enter data into fields he cannot see and would be a burden for system developers because they have to test forms throughly to avoid confusion Claudius.