For some people the priority is going to be backward-compatibility, for other people XHTML compliance. The general solution to this is not to hardcode the output format within the XForms output processor as we do today, so that the maximum flexibility is provided.

I suggest a solution in line with what we've done for JavaServer Faces, which consists in having components (in this case XForms controls) generate an intermediary format, and then use a transformation to generate the desired output (X)HTML, etc. This could potentially affect performance, but to alleviate this we could always write the "standard" transformation using a custom processor.

-Erik

Justin Makeig wrote:

XHTML compliance is much more important the Netscape 4 backwards
compatibility. Is there some way that the JavaScript that is generated when using an
xxforms:set element could be exposed in some sort of configuration? This
would allow users to enhance/customize the behavior of the client-side
script. The default could be the current script relying on the name
attribute. Just a thought.


- Justin Makeig

--
Center for Document Engineering
University of California, Berkeley


On 8/26/03 11:00 AM, "Alessandro Vernet" <[EMAIL PROTECTED]> wrote:



(2) I am reluctant on having the XForms Output processor generate a
<form> element with an "id" attribute, instead "name", as this will
break the compatibility with Netscape 4 (and perhaps other legacy
browsers). Is XHTML compliance more important than Netscape 4
compatibility? I guess it will depend on personal taste and the
particular project which is being considered. As far as we are
concerned, it does not look like we can make this decision once for
all and hardcode it in OXF. So I am leaning towards the solution of
adding option (use "id" or "name"), and keeping the current behavior
("name" attribute) as the default.


_______________________________________________
oxf-users mailing list
[EMAIL PROTECTED]
http://mail.orbeon.com/mailman/listinfo/oxf-users

Reply via email to