From dev-return-85384-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Mon Mar 13 10:54:38 2006 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 51547 invoked from network); 13 Mar 2006 10:54:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Mar 2006 10:54:36 -0000 Received: (qmail 43907 invoked by uid 500); 13 Mar 2006 10:53:57 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 43373 invoked by uid 500); 13 Mar 2006 10:53:55 -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 List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 43362 invoked by uid 99); 13 Mar 2006 10:53:55 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar 2006 02:53:55 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of hepabolu@gmail.com designates 64.233.162.204 as permitted sender) Received: from [64.233.162.204] (HELO zproxy.gmail.com) (64.233.162.204) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 13 Mar 2006 02:53:54 -0800 Received: by zproxy.gmail.com with SMTP id i1so1336151nzh for ; Mon, 13 Mar 2006 02:53:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=uN1pgrnk4Cd1SgV7zorHHyxr+Ol7D9J6RQbGk0aMjkGMeOR72o6lCb7rkAb4D9MhBFJAm+ReJ45UrmhNWXG46ByTT0xBQzkmKUmlKzPkcI8EJcxLE9N98i1Zokoy1TJE88EEsafzOH1nWE1YWqiiNP2AybceNqD2dZM27GIqnUg= Received: by 10.64.178.6 with SMTP id a6mr1009663qbf; Mon, 13 Mar 2006 02:53:33 -0800 (PST) Received: from ?137.120.15.239? ( [137.120.15.239]) by mx.gmail.com with ESMTP id e15sm50179qba.2006.03.13.02.53.32; Mon, 13 Mar 2006 02:53:33 -0800 (PST) Message-ID: <44154F37.7070302@gmail.com> Date: Mon, 13 Mar 2006 11:53:43 +0100 From: hepabolu Reply-To: hepabolu@gmail.com User-Agent: Thunderbird 1.5 (Macintosh/20051201) MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Release 2.1.9 (again) [Dojo] References: <44103D4F.4050001@dslextreme.com> <94611F9D-71FA-4239-AD62-66D026722FA5@apache.org> <441185D0.4070003@dslextreme.com> <44119364.9000500@apache.org> <44129F5A.9090405@gmx.de> <44131597.900@apache.org> <44153FCE.3000205@apache.org> <441543C3.3010209@gmail.com> <44154A40.9010509@apache.org> In-Reply-To: <44154A40.9010509@apache.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Sylvain Wallez said the following on 13-03-2006 11:32: > hepabolu wrote: >> Sylvain Wallez said the following on 13-03-2006 10:47: >>> Carsten Ziegeler wrote: >>>> Anyways, given my current time constraints I can do the release not any >>>> sooner than the 31st of March - so, seeing this as a positive fact, we >>>> have a little more time to test everything :). I would call for a code >>>> freeze on the 24th of March then. >>>> >>> +1. Dojo code is committed, and I'd like people to try the new forms >>> samples. >> Great! Thanks! >> >> Haven't looked thoroughly at the code yet, but I'm wondering two things: >> >> 1. several special attributes (ajax=true and some Dojo required >> attributes) make it impossible to produce valid XHTML pages. A quick >> reading in some Dojo files showed that most dojo attributes can be >> replaced with classnames or identifiers, making valid XHTML pages >> still possible. Have you used any of those? Or are there other ways to >> produce valid XHTML pages that can already be incorporated in the >> current code? > > The ajax="true" attribute is used server-side by Cocoon and can be > filtered out by the stylesheets. Ah, that's nice. It's currently not filtered, i.e. present in the resulting code. Maybe something to add to the stylesheets before the release? > The dojoType attribute triggers the Dojo widget system. It can be > written in 3 different ways depending on the context/requirements: > - dojoType attribute (e.g. dojoType="CFormsRepeater") -- works everywhere > - namespaced dojo:type attribute (e.g. dojo:type="CFormsRepeater") -- > works on namespace-aware browsers > - CSS class (e.g. class="dojo-CFormsRepeater") > > I used the dojoType attribute variant, now we may decide to use another one. I have not enough knowledge of the various browsers, so I cannot figure out whether a namespaced dojo:type attribute is feasible to work with (a.o. which browsers do and don't support it). OTOH web designers in general (dealing mainly with CSS, graphics and layout) prefer valid XHTML + valid CSS before they are able to tackle the browser-inconsistencies in CSS. We might as well try to accommodate that (i.e. produce a valid XHTML page) by making sure that no transformation step introduces any (X)HTML errors nor warnings. In short: when the final page is not valid (X)HTML, this is due to errors made by the builder of the pipeline. > However, some widgets _require_ foreign attributes to be present. These > are the widget-specific properties. Nasty. Having chatted with some members of the Dojo community gave the impression that they don't care about valid (X)HTML as long as the javascript works. So there is a conflicting point of view. >> 2. Dojo contains a (rich text) editor, much along the lines of >> htmlarea. Have you compared the two and would it be possible to >> replace htmlarea with the Dojo version or are there features we would >> miss? In the latter case: if we stick with htmlarea, is it worthwhile >> to update to Xinha since that is a more active project around htmlarea? > > I haven't investigated in this area... Do you think it's worth the effort? Bye, Helma