From lincolnbaxter at gmail.com Sun Aug 16 04:45:19 2020
Content-Type: multipart/mixed; boundary="===============1456307857090956418=="
MIME-Version: 1.0
From: lincolnbaxter at gmail.com
To: jsr-314-open-mirror at lists.jboss.org
Subject: Re: [jsr-314-open] eval of inline scripts
Date: Wed, 19 Aug 2009 21:16:52 +0000
Message-ID: <1509482622-1250716600-cardhu_decombobulator_blackberry.rim.net-335025946-@bxe1197.bisx.prod.on.blackberry>
In-Reply-To: 4A8C6AE8.70104@sun.com

--===============1456307857090956418==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

Agreed. This threw me off too. Its possible to work around, but counter int=
uitive. =


My plus 1
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: Jim Driscoll <Jim.Driscoll(a)Sun.COM>

Date: Wed, 19 Aug 2009 14:13:12 =

To: JSR 314 Open Mailing list<JSR-314-OPEN(a)JCP.ORG>
Subject: [jsr-314-open] eval of inline scripts


I've filed spec bug 616, eval of inline scripts.

Currently, the specification doesn't require that <script> tags get =

evaluated during update or insert operations on the client, nor does it =

specify how they be evaluated if they are included.

Right now, the RI doesn't eval these included scripts - but we plan to =

do so, as does MyFaces.  Given that this behavior was the default for =

many "legacy" JSF Ajax solutions, I think that's the general user =

expectation as well.

Although there is a eval operation in the XML schema, this is =

unfortunately insufficient - renderers for custom components, for =

instance, will already be wrapped in an update operation, and cannot =

easily do a separate eval operation in the RI.

Just wanted to give warning to anyone who may be relying on us *not* =

doing script eval that's it's going in for FCS, as well as making the =

case for it's inclusion in the next rev of the spec.

Jim

--===============1456307857090956418==--