4:33 p.m.
Hi,
Here's my wishlist for JSF 2.1 ajax spec enhancements. All
proposed enhancements are pure client side (js) stuff. Still
they are basic features that make a lot of difference in
practical use.
If there are no objections I will open spec enhancement requests
for JSF 2.1 on the 4 parameters and 2 functional clarifications
described hereafter.
First i'd like to see 4 parameters added to f:ajax as well as to
jsf.ajax.request. All 4 of them are optional and default to the
2.0 behaviour to guarantee backward compatibility:
1. delay: Number of milliseconds before an ajax request is issued.
If another ajax request comes in before the end of the delay the
prior one is discarded. Very important one for onkeyup events in
autosuggest boxes to avoid bombing the server down.
2. timeout: Number of milliseconds before a xhr request is cancelled.
We've already got
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=682
on this one.
3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
for most usages a queue size of 1 is appropriate. This param makes
the queue size configurable. Follow up requests would replace prior
request if the queue is full.
4. pps (true/false): Only the components named in the "execute"
parameter are processed in phase 2-4, but the spec insists
on submitting all elements included in a form. If pps is set to
true submission is reduced to the form params named in execute.
This is a performance feature that can boost speed on large
pages.
There are also 2 functional clarifications I want to propose.
Mojarra and MyFaces partly differ in this, so I think we need to
clarify.
runscripts: If a piece of XHTML comes in via xhr and contains <script>
tags the ajax engine should automatically trigger execution of
these scripts. This is important if you want to replace a js function
or if the scripts somehow initialize UI elements. It depends on a
combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser
platform whether the browsers automatically run these scripts,
IE mostly doesn't run them FF mostly does so. The ajax engine should
know whether the browser does automatically run the scripts and if it
doesn't they should be triggered via js.
applystyles: If a piece of XHTML comes in via xhr and contains <style>
tags the ajax engine should automatically apply the styles to the page.
Again some browser engines with some replacements methods do apply
the styles others don't and the ajax engine should be responsible
to guarantee it.
Best regards,
Ganesh
6:41 p.m.
Ganesh,
These are great suggestions. If I recall correctly, the RichFaces team has
been lobbying for several of these features as well, so many of us are on
the same page. I'm sure post holiday you should expect to get some good
responses to this message.
If there are no objections I will open spec enhancement requests
for JSF 2.1 on the 4 parameters and 2 functional clarifications
described hereafter.
Thanks for offering to take action on these.
One small comment to keep in mind. We should select attribute names very
carefully so that it's obvious to a beginning developer what functionality
it is enabling. We want to make sure JSF 2 is as approachable as possible.
While RichFaces 3.x has been very successful, I think one of its
shortcomings is that the attribute names are sometimes difficult to
understand. (Even those guys are working on better attribute names, based on
feedback from the community).
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
6:58 p.m.
2009/12/22 Ganesh <ganesh(a)j4fry.org>
Hi,
Here's my wishlist for JSF 2.1 ajax spec enhancements. All proposed
enhancements are pure client side (js) stuff. Still they are basic features
that make a lot of difference in practical use.
If there are no objections I will open spec enhancement requests
for JSF 2.1 on the 4 parameters and 2 functional clarifications
described hereafter.
First i'd like to see 4 parameters added to f:ajax as well as to
jsf.ajax.request. All 4 of them are optional and default to the
2.0 behaviour to guarantee backward compatibility:
1. delay: Number of milliseconds before an ajax request is issued. If
another ajax request comes in before the end of the delay the prior one is
discarded. Very important one for onkeyup events in autosuggest boxes to
avoid bombing the server down.
The delay attribute causes two things to happen: delay the request, and
(potentially) cancel the request. The attribute name identifies the former,
but does not imply the latter. I think that could be confusing.
I'm also not sure that we want to tightly couple delay and cancellation. I
want to control each individually, for example, I have a use case with an
autoSuggest composite component where I add a delay to an Ajax call that
hides a listbox, and I want don't want that Ajax call cancelled if another
Ajax request comes in before the delay is over.
Perhaps two attributes? "delay" and a boolean attribute that controls
whether the request is canceled if another Ajax request comes in before the
delay expires. A good name for the second attribute would be difficult to
come up with.
Also, there's the issue of whether we want to allow only certain types of
Ajax requests (for example only requests fired by the same component) to
cause the cancellation of a previous request with a delay.
2. timeout: Number of milliseconds before a xhr request is cancelled. We've
already got
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=6... this one.
+1
3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
for most usages a queue size of 1 is appropriate. This param makes the
queue size configurable. Follow up requests would replace prior request if
the queue is full.
I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
application-wide flag for Ajax behaviors (correct?), and is not specific to
the Ajax request to which the f:ajax tag is assocated.
4. pps (true/false): Only the components named in the
"execute" parameter
are processed in phase 2-4, but the spec insists on submitting all elements
included in a form. If pps is set to true submission is reduced to the form
params named in execute.
This is a performance feature that can boost speed on large
pages.
What does pps stand for? Why are we submitting all elements when we only
process a subset? Is that the best default?
This attribtue is specific to any Ajax request in a given form, not specific
to an ajax request that results from an f:ajax tag, so does the attribute
belong on f:ajax? What if two f:ajax tags set the attribute to different
values in the same form?
There are also 2 functional clarifications I want to propose. Mojarra and
MyFaces partly differ in this, so I think we need to
clarify.
Sorry, I'm confused. Are runscripts and applystyles f:ajax tag attributes?
If so, do the attributes affect only the Ajax request that f:ajax fires, or
is it an app-wide setting for all Ajax requests?
runscripts: If a piece of XHTML comes in via xhr and contains <script> tags
the ajax engine should automatically trigger execution of
these scripts. This is important if you want to replace a js function
or if the scripts somehow initialize UI elements. It depends on a
combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser
platform whether the browsers automatically run these scripts,
IE mostly doesn't run them FF mostly does so. The ajax engine should
know whether the browser does automatically run the scripts and if it
doesn't they should be triggered via js.
I understand the desire for this, but this opens a pretty big security hole,
doesn't it? Do we need to do anything about that?
david
applystyles: If a piece of XHTML comes in via xhr and contains
<style> tags
the ajax engine should automatically apply the styles to the page.
Again some browser engines with some replacements methods do apply
the styles others don't and the ajax engine should be responsible
to guarantee it.
Best regards,
Ganesh
7:02 p.m.
pps = partial page submit
+1 to delay and timeout for now, not sure about queue size, and PPS
would have implications for validation and other view processing, so
that will need a lot of thought.
On Tue, Dec 22, 2009 at 12:58 PM, David Geary
<clarity.training(a)gmail.com> wrote:
2009/12/22 Ganesh <ganesh(a)j4fry.org>
>
> Hi,
>
> Here's my wishlist for JSF 2.1 ajax spec enhancements. All proposed
> enhancements are pure client side (js) stuff. Still they are basic features
> that make a lot of difference in practical use.
>
> If there are no objections I will open spec enhancement requests
> for JSF 2.1 on the 4 parameters and 2 functional clarifications
> described hereafter.
>
>
> First i'd like to see 4 parameters added to f:ajax as well as to
> jsf.ajax.request. All 4 of them are optional and default to the
> 2.0 behaviour to guarantee backward compatibility:
>
> 1. delay: Number of milliseconds before an ajax request is issued. If
> another ajax request comes in before the end of the delay the prior one is
> discarded. Very important one for onkeyup events in autosuggest boxes to
> avoid bombing the server down.
The delay attribute causes two things to happen: delay the request, and
(potentially) cancel the request. The attribute name identifies the former,
but does not imply the latter. I think that could be confusing.
I'm also not sure that we want to tightly couple delay and cancellation. I
want to control each individually, for example, I have a use case with an
autoSuggest composite component where I add a delay to an Ajax call that
hides a listbox, and I want don't want that Ajax call cancelled if another
Ajax request comes in before the delay is over.
Perhaps two attributes? "delay" and a boolean attribute that controls
whether the request is canceled if another Ajax request comes in before the
delay expires. A good name for the second attribute would be difficult to
come up with.
Also, there's the issue of whether we want to allow only certain types of
Ajax requests (for example only requests fired by the same component) to
cause the cancellation of a previous request with a delay.
> 2. timeout: Number of milliseconds before a xhr request is cancelled.
> We've already got
>
> https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=682
> on this one.
+1
>
> 3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
> for most usages a queue size of 1 is appropriate. This param makes the
> queue size configurable. Follow up requests would replace prior request if
> the queue is full.
I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
application-wide flag for Ajax behaviors (correct?), and is not specific to
the Ajax request to which the f:ajax tag is assocated.
>
> 4. pps (true/false): Only the components named in the "execute" parameter
> are processed in phase 2-4, but the spec insists on submitting all elements
> included in a form. If pps is set to true submission is reduced to the form
> params named in execute.
> This is a performance feature that can boost speed on large
> pages.
What does pps stand for? Why are we submitting all elements when we only
process a subset? Is that the best default?
This attribtue is specific to any Ajax request in a given form, not specific
to an ajax request that results from an f:ajax tag, so does the attribute
belong on f:ajax? What if two f:ajax tags set the attribute to different
values in the same form?
>
> There are also 2 functional clarifications I want to propose. Mojarra and
> MyFaces partly differ in this, so I think we need to
> clarify.
Sorry, I'm confused. Are runscripts and applystyles f:ajax tag attributes?
If so, do the attributes affect only the Ajax request that f:ajax fires, or
is it an app-wide setting for all Ajax requests?
> runscripts: If a piece of XHTML comes in via xhr and contains <script>
> tags the ajax engine should automatically trigger execution of
> these scripts. This is important if you want to replace a js function
> or if the scripts somehow initialize UI elements. It depends on a
> combination of the js replacement code
> (innerHTML/adjacentHTML/contextualFragment/...) and the browser
> platform whether the browsers automatically run these scripts,
> IE mostly doesn't run them FF mostly does so. The ajax engine should
> know whether the browser does automatically run the scripts and if it
> doesn't they should be triggered via js.
I understand the desire for this, but this opens a pretty big security hole,
doesn't it? Do we need to do anything about that?
david
>
> applystyles: If a piece of XHTML comes in via xhr and contains <style>
> tags the ajax engine should automatically apply the styles to the page.
> Again some browser engines with some replacements methods do apply
> the styles others don't and the ajax engine should be responsible
> to guarantee it.
>
> Best regards,
> Ganesh
>
>
>
7:07 p.m.
On Tue, Dec 22, 2009 at 1:02 PM, Lincoln Baxter, III <
lincolnbaxter(a)gmail.com> wrote:
pps = partial page submit
In that case, we should use the attribute partialSubmit that was popularized
by ICEfaces. pps doesn't help anyone except gurus.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
8:56 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - delay
Actually the cancellation doesn't need to be part of the delay option
if the queuesize option is at hand. By setting queuesize=1 the new
request would automatically cancel the old one.
So, I modify the proposal for the delay option to:
1. delay: Number of milliseconds before an ajax request is issued.
Delayed requests are only queued *after* the delay, so another
non-delayed request that is triggered after the delayed request can
be queued before the delayed request. Still, delayed requests block
queue space, so if the queue size is set to x and n requests
are queued (n<=x) then the queue size is reduced to x-n. Now,
if another request comes in and the queue and x-n requests are in
the queue then one delayed request is cancelled. If several requests
were delayed the request to cancel is chosen first-in-first-out.
1. delay: Number of milliseconds before an ajax request is
issued.
If another ajax request comes in before the end of the delay the
prior one is discarded. Very important one for onkeyup events in
autosuggest boxes to avoid bombing the server down.
The delay attribute causes two things to happen: delay the request, and
(potentially) cancel the request. The attribute name identifies the
former, but does not imply the latter. I think that could be confusing.
I'm also not sure that we want to tightly couple delay and cancellation.
I want to control each individually, for example, I have a use case with
an autoSuggest composite component where I add a delay to an Ajax call
that hides a listbox, and I want don't want that Ajax call cancelled if
another Ajax request comes in before the delay is over.
Perhaps two attributes? "delay" and a boolean attribute that controls
whether the request is canceled if another Ajax request comes in before
the delay expires. A good name for the second attribute would be
difficult to come up with.
Also, there's the issue of whether we want to allow only certain types
of Ajax requests (for example only requests fired by the same component)
to cause the cancellation of a previous request with a delay.
9:03 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - queue
Actually the desired queue size can differ with
each use case, so this was meant to define the
number of queue elements this special request
tolerates before throwing one out, so f:ajax/
jsf.ajax.request could be the right place to put it.
Maybe "queue" would be nicer and more compact than
"queuesize".
Best regards,
Ganesh
3. queuesize: The 2.0 spec specifies an unlimited ajax queue,
though
for most usages a queue size of 1 is appropriate. This param makes
the queue size configurable. Follow up requests would replace prior
request if the queue is full.
I'm not sure this is appropriate for an f:ajax tag attribute. It sets a
application-wide flag for Ajax behaviors (correct?), and is not specific
to the Ajax request to which the f:ajax tag is assocated.
9:18 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - partialSubmit
+1 for partialSubmit instead of pps.
Actually I do not understand why the 2.0 spec insists on
submitting the complete form, not only the elements listed
in execute, but backwards compatibility would probably
require leaving it as default.
I don't completely understand what you are saying with
"This attribtue is specific to any Ajax request in a given form",
Can you please elaborate on this?
Lincoln, can be please give some details on the
"implications for validation and other view processing"
you see with this attribute?
Best regards,
Ganesh
4. pps (true/false): Only the components named in the
"execute"
parameter are processed in phase 2-4, but the spec insists on
submitting all elements included in a form. If pps is set to true
submission is reduced to the form params named in execute.
This is a performance feature that can boost speed on large
pages.
What does pps stand for? Why are we submitting all elements when we only
process a subset? Is that the best default?
This attribtue is specific to any Ajax request in a given form, not
specific to an ajax request that results from an f:ajax tag, so does the
attribute belong on f:ajax? What if two f:ajax tags set the attribute to
different values in the same form?
9:30 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - partialSubmit
What I (rather poorly) alluded to, was the fact that we will need to
decide how to handle fields defined in the form that are not passed
back during the partial page submit.
Actually, now that I think about this more, I don't think it would be
much different at all than the current behavior of partial view
traversal that we do now for Ajax submits. Since we already ignore the
other fields, it would most likely be a trivial (client side) change
to send only the specified fields. Is there any part of the
server-side Ajax processing that depends on having all form fields in
the request? I don't believe so (at least not in the spec).
--Lincoln
On Tue, Dec 22, 2009 at 3:18 PM, Ganesh <ganesh(a)j4fry.org> wrote:
+1 for partialSubmit instead of pps.
Actually I do not understand why the 2.0 spec insists on
submitting the complete form, not only the elements listed
in execute, but backwards compatibility would probably require leaving it as
default.
I don't completely understand what you are saying with
"This attribtue is specific to any Ajax request in a given form",
Can you please elaborate on this?
Lincoln, can be please give some details on the
"implications for validation and other view processing"
you see with this attribute?
Best regards,
Ganesh
> 4. pps (true/false): Only the components named in the "execute"
> parameter are processed in phase 2-4, but the spec insists on
> submitting all elements included in a form. If pps is set to true
> submission is reduced to the form params named in execute.
> This is a performance feature that can boost speed on large
> pages.
>
>
> What does pps stand for? Why are we submitting all elements when we only
> process a subset? Is that the best default?
>
> This attribtue is specific to any Ajax request in a given form, not
> specific to an ajax request that results from an f:ajax tag, so does the
> attribute belong on f:ajax? What if two f:ajax tags set the attribute to
> different values in the same form?
9:37 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - partialSubmit
No, it isn't. I have implemented this option in the MyFaces
JavaScript and tested it against Mojarra and it works just
fine. In MyFaces it's hidden because we didn't want to
bend the spec.
Best regards,
Ganesh
Lincoln Baxter, III schrieb:
What I (rather poorly) alluded to, was the fact that we will need to
decide how to handle fields defined in the form that are not passed
back during the partial page submit.
Actually, now that I think about this more, I don't think it would be
much different at all than the current behavior of partial view
traversal that we do now for Ajax submits. Since we already ignore the
other fields, it would most likely be a trivial (client side) change
to send only the specified fields. Is there any part of the
server-side Ajax processing that depends on having all form fields in
the request? I don't believe so (at least not in the spec).
--Lincoln
On Tue, Dec 22, 2009 at 3:18 PM, Ganesh <ganesh(a)j4fry.org> wrote:
> +1 for partialSubmit instead of pps.
> Actually I do not understand why the 2.0 spec insists on
> submitting the complete form, not only the elements listed
> in execute, but backwards compatibility would probably require leaving it as
> default.
>
> I don't completely understand what you are saying with
> "This attribtue is specific to any Ajax request in a given form",
> Can you please elaborate on this?
>
> Lincoln, can be please give some details on the
> "implications for validation and other view processing"
> you see with this attribute?
>
> Best regards,
> Ganesh
>
>> 4. pps (true/false): Only the components named in the "execute"
>> parameter are processed in phase 2-4, but the spec insists on
>> submitting all elements included in a form. If pps is set to true
>> submission is reduced to the form params named in execute.
>> This is a performance feature that can boost speed on large
>> pages.
>>
>>
>> What does pps stand for? Why are we submitting all elements when we only
>> process a subset? Is that the best default?
>>
>> This attribtue is specific to any Ajax request in a given form, not
>> specific to an ajax request that results from an f:ajax tag, so does the
>> attribute belong on f:ajax? What if two f:ajax tags set the attribute to
>> different values in the same form?
>
9:14 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - partialSubmit
Yes, actually to give Ganesh additional credits here, the partial submit
code stems
from the stuff he and Alex were doing in the J4Fry project. My original idea
was just to implement the specs as defined, but given their experience in
the J4Fry project
he proposed to add that stuff, and I was happy to get it in. We have some of
those hidden things
in there (like the queue control stuff modulariuzation, queue control to
some degree etc...)
the partial submit is not really that much of a change and definitely has to
go into the next spec.
(As well as the option for additional transport layers in my opinion,
because the current approach
blocks fileuploads or moves them into their own framework layer)
Werner
On Tue, Dec 22, 2009 at 9:37 PM, Ganesh <ganesh(a)j4fry.org> wrote:
No, it isn't. I have implemented this option in the MyFaces
JavaScript and tested it against Mojarra and it works just
fine. In MyFaces it's hidden because we didn't want to
bend the spec.
Best regards,
Ganesh
Lincoln Baxter, III schrieb:
What I (rather poorly) alluded to, was the fact that we will need to
> decide how to handle fields defined in the form that are not passed
> back during the partial page submit.
>
> Actually, now that I think about this more, I don't think it would be
> much different at all than the current behavior of partial view
> traversal that we do now for Ajax submits. Since we already ignore the
> other fields, it would most likely be a trivial (client side) change
> to send only the specified fields. Is there any part of the
> server-side Ajax processing that depends on having all form fields in
> the request? I don't believe so (at least not in the spec).
>
> --Lincoln
>
>
>
> On Tue, Dec 22, 2009 at 3:18 PM, Ganesh <ganesh(a)j4fry.org> wrote:
>
>> +1 for partialSubmit instead of pps.
>> Actually I do not understand why the 2.0 spec insists on
>> submitting the complete form, not only the elements listed
>> in execute, but backwards compatibility would probably require leaving it
>> as
>> default.
>>
>> I don't completely understand what you are saying with
>> "This attribtue is specific to any Ajax request in a given form",
>> Can you please elaborate on this?
>>
>> Lincoln, can be please give some details on the
>> "implications for validation and other view processing"
>> you see with this attribute?
>>
>> Best regards,
>> Ganesh
>>
>> 4. pps (true/false): Only the components named in the "execute"
>>> parameter are processed in phase 2-4, but the spec insists on
>>> submitting all elements included in a form. If pps is set to true
>>> submission is reduced to the form params named in execute.
>>> This is a performance feature that can boost speed on large
>>> pages.
>>>
>>>
>>> What does pps stand for? Why are we submitting all elements when we only
>>> process a subset? Is that the best default?
>>>
>>> This attribtue is specific to any Ajax request in a given form, not
>>> specific to an ajax request that results from an f:ajax tag, so does the
>>> attribute belong on f:ajax? What if two f:ajax tags set the attribute to
>>> different values in the same form?
>>>
>>
>>
>
4:34 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - partialSubmit
created a jira on this one:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=723
2009/12/22 Ganesh <ganesh(a)j4fry.org>:
+1 for partialSubmit instead of pps.
Actually I do not understand why the 2.0 spec insists on
submitting the complete form, not only the elements listed
in execute, but backwards compatibility would probably require leaving it as
default.
I don't completely understand what you are saying with
"This attribtue is specific to any Ajax request in a given form",
Can you please elaborate on this?
Lincoln, can be please give some details on the
"implications for validation and other view processing"
you see with this attribute?
Best regards,
Ganesh
> 4. pps (true/false): Only the components named in the "execute"
> parameter are processed in phase 2-4, but the spec insists on
> submitting all elements included in a form. If pps is set to true
> submission is reduced to the form params named in execute.
> This is a performance feature that can boost speed on large
> pages.
>
>
> What does pps stand for? Why are we submitting all elements when we only
> process a subset? Is that the best default?
>
> This attribtue is specific to any Ajax request in a given form, not
> specific to an ajax request that results from an f:ajax tag, so does the
> attribute belong on f:ajax? What if two f:ajax tags set the attribute to
> different values in the same form?
9:26 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - runscripts/applystyles
no, these aren't attributes. If XHTML that comes in via xhr
contains scripts these *always* need to be executed and
styles need to be *always* applied. Some browsers in
combination with some replacement methods already do this
for us, some don't, so we need to take action.
I cannot see the security hole with this as some browsers
actually do it. Can you make up a setup that illustrates
the hole?
Best regards,
Ganesh
There are also 2 functional clarifications I want to propose.
Mojarra and MyFaces partly differ in this, so I think we need to
clarify.
Sorry, I'm confused. Are runscripts and applystyles f:ajax tag
attributes? If so, do the attributes affect only the Ajax request that
f:ajax fires, or is it an app-wide setting for all Ajax requests?
runscripts: If a piece of XHTML comes in via xhr and contains
<script> tags the ajax engine should automatically trigger execution of
these scripts. This is important if you want to replace a js function
or if the scripts somehow initialize UI elements. It depends on a
combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser
platform whether the browsers automatically run these scripts,
IE mostly doesn't run them FF mostly does so. The ajax engine should
know whether the browser does automatically run the scripts and if it
doesn't they should be triggered via js.
I understand the desire for this, but this opens a pretty big security
hole, doesn't it? Do we need to do anything about that?
7:13 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - runscripts/applystyles
Ganesh -
As far as I know, the runscripts behavior is the same between MyFaces
and Mojarra - what's the difference that you are speaking of? Werner
and I collaborated a bit during beta to make sure they were the same...
Thus, I'm confused by your contention in the bug:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=724
That:
MyFaces 2.0 does execute script, Mojarra doesn't, spec needs to clarify for
unification
Agree that this needs to be in the spec. It's omission was an oversight.
As for applying styles:
The <style> tag is only valid in the <head> - and we do not apply stuff
in the head right now - mostly because there are just so very many bugs
when doing so.
So, this may be surfacing a more major lack in the spec than just styles.
Jim
On 12/22/09 12:26 PM, Ganesh wrote:
no, these aren't attributes. If XHTML that comes in via xhr
contains scripts these *always* need to be executed and
styles need to be *always* applied. Some browsers in combination with
some replacement methods already do this for us, some don't, so we need
to take action.
I cannot see the security hole with this as some browsers
actually do it. Can you make up a setup that illustrates
the hole?
Best regards,
Ganesh
> There are also 2 functional clarifications I want to propose.
> Mojarra and MyFaces partly differ in this, so I think we need to
> clarify.
>
>
> Sorry, I'm confused. Are runscripts and applystyles f:ajax tag
> attributes? If so, do the attributes affect only the Ajax request that
> f:ajax fires, or is it an app-wide setting for all Ajax requests?
>
> runscripts: If a piece of XHTML comes in via xhr and contains
> <script> tags the ajax engine should automatically trigger execution of
> these scripts. This is important if you want to replace a js function
> or if the scripts somehow initialize UI elements. It depends on a
> combination of the js replacement code
> (innerHTML/adjacentHTML/contextualFragment/...) and the browser
> platform whether the browsers automatically run these scripts,
> IE mostly doesn't run them FF mostly does so. The ajax engine should
> know whether the browser does automatically run the scripts and if it
> doesn't they should be triggered via js.
>
>
> I understand the desire for this, but this opens a pretty big security
> hole, doesn't it? Do we need to do anything about that?
>
9 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - runscripts/applystyles
On Tue, Jan 19, 2010 at 7:13 PM, Jim Driscoll <Jim.Driscoll(a)sun.com> wrote:
Ganesh -
As far as I know, the runscripts behavior is the same between MyFaces and
Mojarra - what's the difference that you are speaking of? Werner and I
collaborated a bit during beta to make sure they were the same...
Thus, I'm confused by your contention in the bug:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=724
That:
MyFaces 2.0 does execute script, Mojarra doesn't, spec needs to clarify for
unification
Agree that this needs to be in the spec. It's omission was an oversight.
As for applying styles:
The <style> tag is only valid in the <head> - and we do not apply stuff in
the head right now - mostly because there are just so very many bugs when
doing so.
Actually the head changing is not really possible afair as I can remember
our discussions and my testing on many browsers. So far only some IE
versions and Mozilla do some degree under some conditions allow that.
So, this may be surfacing a more major lack in the spec than just
styles.
Jim
On 12/22/09 12:26 PM, Ganesh wrote:
> no, these aren't attributes. If XHTML that comes in via xhr
> contains scripts these *always* need to be executed and
> styles need to be *always* applied. Some browsers in combination with
> some replacement methods already do this for us, some don't, so we need
> to take action.
>
> I cannot see the security hole with this as some browsers
> actually do it. Can you make up a setup that illustrates
> the hole?
>
> Best regards,
> Ganesh
>
>> There are also 2 functional clarifications I want to propose.
>> Mojarra and MyFaces partly differ in this, so I think we need to
>> clarify.
>>
>>
>> Sorry, I'm confused. Are runscripts and applystyles f:ajax tag
>> attributes? If so, do the attributes affect only the Ajax request that
>> f:ajax fires, or is it an app-wide setting for all Ajax requests?
>>
>> runscripts: If a piece of XHTML comes in via xhr and contains
>> <script> tags the ajax engine should automatically trigger execution of
>> these scripts. This is important if you want to replace a js function
>> or if the scripts somehow initialize UI elements. It depends on a
>> combination of the js replacement code
>> (innerHTML/adjacentHTML/contextualFragment/...) and the browser
>> platform whether the browsers automatically run these scripts,
>> IE mostly doesn't run them FF mostly does so. The ajax engine should
>> know whether the browser does automatically run the scripts and if it
>> doesn't they should be triggered via js.
>>
>>
>> I understand the desire for this, but this opens a pretty big security
>> hole, doesn't it? Do we need to do anything about that?
>>
>>
>
7:23 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - applystyles
You're probably right, the concept of exchanging styles
on-the-fly isn't that great. I've set issue 725 to WONTFIX
Best regards,
Ganesh
As for applying styles:
The <style> tag is only valid in the <head> - and we do not apply
stuff in the head right now - mostly because there are just so very
many bugs when doing so.
Actually the head changing is not really possible afair as I can
remember our discussions and my testing on many browsers. So far only
some IE versions and Mozilla do some degree under some conditions allow
that.
7:26 p.m.
New subject: [jsr-314-open] JSF 2.1 ajax spec enhancements - runscripts/applystyles
I had been testing with an older Mojarra version and I
agree that Mojarra perfectly runs scripts.
This will make it easy to put this into the spec,
probably 2.0a is no problem.
I don't see issue 724 in Ed's yesterdays list - can we still add it?
Best regards,
Ganesh
Jim Driscoll schrieb:
Ganesh -
As far as I know, the runscripts behavior is the same between MyFaces
and Mojarra - what's the difference that you are speaking of? Werner
and I collaborated a bit during beta to make sure they were the same...
7:30 p.m.
Re:
Delay, timeout, queuesize.
There are two ways to handle this behavior - we've discussed both over
the last year.
The first approach would be to simply specify them, as you do here. (It
was certainly my first impulse to do this same thing.)
There are a few problems with approach -
The biggest one is that it conflicts with the current behavior of
RichFaces. They have a very... rich... request delay and aggregation
infrastructure. Specifying something that's less than what they
currently do, without an extension mechanism, is probably not going to work.
The second problem is the rather high level of implicit complexity that
underlies your proposal. How many queues are there? Are we talking
connection queues, or request queues? How can you query the queues?
Can you tell which queue any given request goes to? What about user
driven aggregation? What about multi-field shared queues?
So, in reaction to these problems, I proposed a second approach, a
generic extension. It has two primary drawbacks - it's more complex
(though it should be hidden from the general purpose usecase), and it's
still not written up. (This last drawback is it's most serious one :-).
I promised to write up my proposal before the break, but was sidetracked
by a number of other urgent matters. I'll try to get it written up this
week.
Jim
On 12/22/09 7:33 AM, Ganesh wrote:
Hi,
Here's my wishlist for JSF 2.1 ajax spec enhancements. All proposed
enhancements are pure client side (js) stuff. Still they are basic
features that make a lot of difference in practical use.
If there are no objections I will open spec enhancement requests
for JSF 2.1 on the 4 parameters and 2 functional clarifications
described hereafter.
First i'd like to see 4 parameters added to f:ajax as well as to
jsf.ajax.request. All 4 of them are optional and default to the
2.0 behaviour to guarantee backward compatibility:
1. delay: Number of milliseconds before an ajax request is issued. If
another ajax request comes in before the end of the delay the prior one
is discarded. Very important one for onkeyup events in autosuggest boxes
to avoid bombing the server down.
2. timeout: Number of milliseconds before a xhr request is cancelled.
We've already got
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=682
on this one.
3. queuesize: The 2.0 spec specifies an unlimited ajax queue, though
for most usages a queue size of 1 is appropriate. This param makes the
queue size configurable. Follow up requests would replace prior request
if the queue is full.
4. pps (true/false): Only the components named in the "execute"
parameter are processed in phase 2-4, but the spec insists on submitting
all elements included in a form. If pps is set to true submission is
reduced to the form params named in execute.
This is a performance feature that can boost speed on large
pages.
There are also 2 functional clarifications I want to propose. Mojarra
and MyFaces partly differ in this, so I think we need to
clarify.
runscripts: If a piece of XHTML comes in via xhr and contains <script>
tags the ajax engine should automatically trigger execution of
these scripts. This is important if you want to replace a js function
or if the scripts somehow initialize UI elements. It depends on a
combination of the js replacement code
(innerHTML/adjacentHTML/contextualFragment/...) and the browser
platform whether the browsers automatically run these scripts,
IE mostly doesn't run them FF mostly does so. The ajax engine should
know whether the browser does automatically run the scripts and if it
doesn't they should be triggered via js.
applystyles: If a piece of XHTML comes in via xhr and contains <style>
tags the ajax engine should automatically apply the styles to the page.
Again some browser engines with some replacements methods do apply
the styles others don't and the ajax engine should be responsible
to guarantee it.
Best regards,
Ganesh
7:26 p.m.
Really looking forward to the generic approach you'll propose. I agree
that it would be great to give a higher degree of freedom to the
developer here.
I promised to write up my proposal before the break, but was
sidetracked
by a number of other urgent matters. I'll try to get it written up this
week.
Jim
4:15 a.m.
New subject: [jsr-314-open] Method signatures for event handlers
Consulting the specification for f:event
(http://java.sun.com/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/f/ev...),
I find that the signature is required to match public void
listener(javax.faces.event.ComponentSystemEvent event) throws
javax.faces.event.AbortProcessingException.
That's actually too bad. When I do a preRenderView event with
viewParams, I don't need the CSE parameter, and I'd rather not couple my
managed bean with the JSF API. So, it sure would be nice if I had the
flexibility of using the signature public void listener() instead.
Mojarra actually lets me do that!
I am asking here and not in the Mojarra forum because I am hoping that
the f:event spec isn't accurate--it has other issues
(https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=586,
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=639,
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=712)
Did you discuss this before? Does Mojarra implement what was intended?
Thanks,
Cay
--
Cay S. Horstmann | http://horstmann.com | mailto:cay@horstmann.com
11:39 p.m.
New subject: [jsr-314-open] Method signatures for event handlers
On Thu, Jan 21, 2010 at 10:15 PM, Cay Horstmann <cay(a)horstmann.com> wrote:
Consulting the specification for f:event (
http://java.sun.com/javaee/javaserverfaces/2.0/docs/pdldocs/facelets/f/ev...),
I find that the signature is required to match public void
listener(javax.faces.event.ComponentSystemEvent event) throws
javax.faces.event.AbortProcessingException.
That's actually too bad. When I do a preRenderView event with viewParams, I
don't need the CSE parameter, and I'd rather not couple my managed bean with
the JSF API. So, it sure would be nice if I had the flexibility of using the
signature public void listener() instead. Mojarra actually lets me do that!
I'm almost certain that we agreed that the event parameter (and exception
signature) were optional. I clearly remember having that discussion. I don't
have it in my archives, but for those that have them, the discussion should
start around Jan 17, 2009.
Thus, I consider this a spec error. The fact that Mojarra implements the
desired behavior is a partial indication that we agreed on it, too.
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
12:01 a.m.
New subject: [jsr-314-open] Method signatures for event handlers
Dan Allen wrote:
I'm almost certain that we agreed that the event parameter (and
exception signature) were optional. I clearly remember having that
discussion. I don't have it in my archives, but for those that have
them, the discussion should start around Jan 17, 2009.
I couldn't find the system event listener discussion, but I did find the
discussion about making FacesEvents optional. Was started on 8/13/08 by
Pete. Conditionally closed on 8/23 by Ed. I won't bother trying to
link to the mail archives (sigh), but the spec issue is:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=447
Thus, I consider this a spec error. The fact that Mojarra implements
the desired behavior is a partial indication that we agreed on it, too.
Yep. Think we are all in agreement on this now. The spec issue that I
logged is targeted for 2.0 Rev a, so at this point I think it is safe to
assume that we'll be fixing this for our MR.
Andy
-Dan
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
12:16 a.m.
New subject: [jsr-314-open] Method signatures for event handlers
Awesome. Thanks Andy.
-Dan
On Tue, Jan 26, 2010 at 6:01 PM, Andy Schwartz <andy.schwartz(a)oracle.com>wrote:
Dan Allen wrote:
> I'm almost certain that we agreed that the event parameter (and exception
> signature) were optional. I clearly remember having that discussion. I don't
> have it in my archives, but for those that have them, the discussion should
> start around Jan 17, 2009.
>
I couldn't find the system event listener discussion, but I did find the
discussion about making FacesEvents optional. Was started on 8/13/08 by
Pete. Conditionally closed on 8/23 by Ed. I won't bother trying to link to
the mail archives (sigh), but the spec issue is:
https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=447
> Thus, I consider this a spec error. The fact that Mojarra implements the
> desired behavior is a partial indication that we agreed on it, too.
>
Yep. Think we are all in agreement on this now. The spec issue that I
logged is targeted for 2.0 Rev a, so at this point I think it is safe to
assume that we'll be fixing this for our MR.
Andy
> -Dan
>
> --
> Dan Allen
> Senior Software Engineer, Red Hat | Author of Seam in Action
> Registered Linux User #231597
>
> http://mojavelinux.com
> http://mojavelinux.com/seaminaction
> http://www.google.com/profiles/dan.j.allen
>
--
Dan Allen
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597
http://mojavelinux.com
http://mojavelinux.com/seaminaction
http://www.google.com/profiles/dan.j.allen
5213
days inactive
5248
days old
jsr-314-open-mirror@lists.jboss.org
22 comments
9 participants
participants (9)
-
Andy Schwartz -
Cay Horstmann -
Dan Allen -
David Geary -
Ganesh -
Ganesh Jung
-
Jim Driscoll -
Lincoln Baxter, III -
Werner Punz