[jsr-314-open] JSF 2.1 ajax spec enhancements
by Ganesh
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
14 years, 11 months
Re: [jsr-314-open] Method signatures for event handlers
by Lincoln Baxter, III
It would be nice if jsf made all these event signatures optional.
I know its a stumbling block for many users.
Perhaps the ability to inject those parameters with an annotation (or access
via facesContext.getCurrentSystemEvent() ... obviously just a short winded
concept. But the idea is to somehow provide optional access.)
Lincoln Baxter's Droid
http://ocpsoft.com
http://scrumshark.com
Keep it simple.
On Jan 21, 2010 10:19 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 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
14 years, 11 months
[jsr-314-open] Fwd: [Issue 6] New - Framework (caller) provided parameters get lost with the new method-expression param functionality
by Martin Marinschek
For your information - my discussion with Kin Man on our desired
extension to the Unified EL.
(we need a way to pass in the JSF supplied parameters to methods with
user-specified params as well).
Kin-Man's suggestion is that in a next revision we will be able to use:
#{myNs:myMethod(*, myParam)}
which sounds great to me!
best regards,
Martin
---------- Forwarded message ----------
From: Martin Marinschek <mmarinschek(a)apache.org>
Date: Thu, Jan 21, 2010 at 7:42 AM
Subject: Re: [jsr-314-open] [Issue 6] New - Framework (caller) provided parameters
get lost with the new method-expression param functionality
To: Kin-Man.Chung(a)sun.com
>> we came to the conclusion that there should be two
>> possibilities: either the method which is being called only takes the
>> parsed parameters, then it should be called with these params only, or
>
> This how EL behaves now. :-)
agreed
>> it takes more than these, than the additional params should be taken
>> over from the invoke-method call and passed on to the method. I see it
>> rather counter-intuitive and confusing that params that
>> method-listeners in JSF have always received (like the ActionEvent or
>> the ValueChangeEvent, certainly an important parameter) are suddenly
>> not available anymore.
>
> Just a clarification about what I think is confusing.
>
> If you create an MethodExpression with
>
> ExpressionFactory.createMethodExpression(
> elContext,
> "#{myBean.method("param")",
> String.class,
> Object[] {String.class} )
JSF doesn't create a method expression like this, it creates a method
expression like this:
ExpressionFactory.createMethodExpression(
elContext,
userSuppliedString,
String.class,
Object[] {String.class} )
so for JSF it is not counter intuitive or confusing that the method
suddenly gets an additional parameter from the user - it doesn't even
know about it. JSF (the framework) needs to pass some params to the
method, and it is counter-intuitive and confusing if these params
don't end up in the method!
> you are telling EL to create an expression that represents a method with
> one parameter of String type, but now you want to invoke a method with
> two parameters. This is counter-intuitive and confusing.
You disagree with yourself here: the types that you pass in to the
create method expression call from above don't mean anything at all
(or else the new method invocation will not work at all, cause your
custom method expression signatures would all need to take
ActionListeners, and that would really be dumb)!
To make my point clearer - you could do this:
> ExpressionFactory.createMethodExpression(
> elContext,
> "#{myBean.method("param")",
> String.class,
> Object[] {FacesContext.class,Object.class, Object.class} )
And it would still call a method with the signature Bean.method(String
param) even though you supplied three parameters! (I didn't actually
test this assumption, but it has to work, or these user supplied
method parameters don't make sense at all for JSF, cause JSF will
always supply its own set of parameters).
The types and then the params which are passed in are ignored,
everything that counts is what is passed in from the user! The
confusing thing is that the current situation is ignoring stuff here,
not that whatever is parsed is off from what is passed in (that is
already true with the current situation).
> If you want the previous behavior, then you should use the old EL syntax
> #{myBean.method}.
With which you are saying: ok, you JSF folks cannot use user supplied
parameters properly. Thanks!
> Anyway, you also didn't say how EL can decide which of the two
> possibilities to take.
There should be a possibility to check which method signatures are
there - there is even an API now (I think it was in the EL resolver,
right?) where we can go look to find the proper method signature
ourselves, but we can't, cause we don't get the second set of
parameters there.
>>> When JSF framework passes the parameters to MethodExpression.invoke(),
>>> are the parameter types compatible with those expected by this
>>> instance of MethodExpression? How are this MethodExpression and
>>> parameters instantiated?
yes, but they will not be what is passed in from the user - that is
what I keep saying.
>> As before - there is some factory method for creating a
>> method-expression called - you should know this better than me, so I
>> am not gonna look it up right now - and the expected params are passed
>> in at creation time. As I see it, in the new version both the expected
>> param types and the actual param instances are ignored and instead the
>> parsed instances are taken over.
>>
> I though this is what JSF wanted, as conveyed to me by Ed Burns and
> Jacob Hookom. This also how the Jboss EL behaves too.
I don't know what exactly they conveyed to you, Jacob e.g. is not very
active anymore on the EG (he hasn't been for years). Ed will have
given you a big picture, but that was a detail that we discussed early
on, then we had heard that yes, it was supported (obviously we didn't
get the response from you directly) and then later we found out it
wouldn't work (and this was when I contacted you).
>>> Guess what I trying to figure out is: how can the EL API be modified to
>>> do what you want to achieve. So far I don't have a very clear picture.
>>
>> Well, it would have been great if we could have had that discussion a
>> little earlier (before the API was released) - I am not sure how this
>> would fit into the newly released API, either. My original suggestion
>> back in (I think) May was, if you couldn't do it by default, that you
>
> Nobody has talked to me about this before you did, but the EL MR was
> already closed then.
we really had an information problem - the EGs all should be _way_
more open, then this would work a lot better.
>> would provide us with a way where we could somehow get both sets of
>> parameters in the ELResolver and choose ourselves what method to call
>> - then we could easily fix this in a custom EL Resolver. Anyways - if
>> you want to help out the JSF EG, then it would certainly be great you
>> would take a look into this.
>>
> I don't think ELResolver is the answer. It is too much a hack.
>
> Maybe we can modify the EL syntax to allow for something like
>
> #{myBean.method(*, param)"
>
> and the "*" would instruct EL to take the parameters supplied when the
> MethodExpression was created, and prepend them to the list of parameters
> used for method selection and invocation. Would this work for you?
Sounds very good to me!
> Ah, we need a JSR for EL to discuss things like this!
Yes, definitely. Dan Allen even wrote a blog entry about the need for
a Unified EL EG.
> Should we get
> other JSF EGs involve so to get a consensus?
I will forward this mail to the JSF EG. Thanks for your feedback.
> -Kin-man
best regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
14 years, 11 months
[jsr-314-open] [ADMIN] EG Audio from today's meeting (was: REMINDER [ADMIN] EG Meeting Next Week)
by Ed Burns
Action Items
=> edburns uploaded audio to [1].
=> edburns assigned issue captains as follows
Roger Kitain
621 623 624 625 626 627 628 629 631 632 633 634 635 636 693 10 49 94 130 149 255 552 575 616 619 620 622
Ed Burns
106 201 205 240 241 260 263 271 316 323 342 448 464 473 478 485 520 526 547 548 559 564 595 599 609 612
Andy Schwartz
630 470 617 91 127 137 157 174 206 212 217 220 225 236 247 249 264 318 320 322 328 329 333 335 336 340 345 615
Kito Mann
346 350 353 418 420 421 424 431 435 436 437 441 443 444 446 449 452 457 459 460 461 462 466 467 469 471 472 614
Lincoln Baxter III
474 475 477 483 486 494 495 496 498 501 502 503 505 507 508 509 510 511 512 514 516 519 522 523 524 525 527 613
Jason Lee
528 529 530 531 532 533 534 535 536 537 539 540 541 542 543 545 546 550 551 553 556 558 560 561 562 563 566 611
Alexandr Smirnov
567 568 569 571 572 573 576 577 579 581 582 584 585 589 590 591 592 593 594 596 598 600 601 605 606 607 608 610
Each issue captian should, by the end of January, have read each of the
issues in their list and assigned the correct subcomponent and target
milestone (either "2.0 Rev a" or leave it as "unscheduled"). Keep in
mind that 2.0 Rev a must only contain simple fixes that require very
little spec modification. You don't need to assign the bug to yourself
but if you really want to own the bug, please feel free to take it!
=> Kito Mann will fix javaserverfaces.org so that it goes to our google
sites page.
=> edburns sent mail to Max Lanfranconi from JCP about making mails to
jsr-314-open sent from non-post-enabled addresses bounce.
=> edburns sent mail to Max Lanfranconi from JCP about the status of the
archives
The next EG meeting will probably be mid February, or perhaps at JSFDays
in Vienna, Austria!
Ed
[1] https://javaserverfaces-spec-public.dev.java.net/files/documents/1936/147...
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
[jsr-314-open] [ADMIN] EG Meeting Next Week
by Ed Burns
I apologize for the arbitrary timing of this meeting. Let's see how
many can't make it and we'll tweak the timing of the next one.
Time and Date
=============
http://timeanddate.com/worldclock/meetingdetails.html?year=2010&month=1&d...
London Wednesday, January 20, 2010 at 6:00:00 PMUTC GMT
(U.K. - England)
Boston Wednesday, January 20, 2010 at 1:00:00 PMUTC-5 hours EST
(U.S.A. - Massachusetts)
San Francisco Wednesday, January 20, 2010 at 10:00:00 AMUTC-8 hours PST
(U.S.A. - California)
Sydney Thursday, January 21, 2010 at 5:00:00 AMUTC+11 hours EDT
(Australia - New South Wales)
Corresponding UTC Wednesday, January 20, 2010 at 18:00:00
(GMT)
Telephone call in
=================
U.S.A. toll free: 1 866 839 8145
Caller Paid: 865 524 6352
Access code: 3555194
If you don't want to pay full price a toll call, please consider
SkypeOut. It's very cheap and the quality is sometimes decent.
Duration: 60 minutes
Agenda
======
Planning for Revision 2.0 a of the spec.
Problem 1 Choosing what to do
=============================
The ChangeLog of record is now at our JCP Wiki [1]. TAnything not in the
"Accepted Changes" section will not be done for 2.0 Rev a. However, I'm
not convinced that everything that needs to be in that section is in
there. There are at least two additional data sources to which we
should look to discover issues that should be in the "Accepted changes"
section. I think we should undertake the following steps to get 2.0 Rev
a done.
A. Clean up the ChangeLog so that it accurately represents everything
that needs to go into 2.0 Rev a in its "Accepted Changes" section
B. Officially file the JCP MR.
C. Do the spec work during the review of the MR.
Task A subtasks
1. The Jsf2ErrataScratchPad [2]. Roger and I must go through this data
source and put content either directly into the spec, or into the
"Accepted changes" section, removing it from the scratchpad as we go.
2. The jsf-spec public issue tracker [3] We need issue captains to go
through all the issues currently targeted for "2.0 Rev a" or
"unscheduled" and make sure they are represented in the ChangeLog. If
the issue is already in the ChangeLog, great, no additional action is
required. If the issue is not in the changelog, add it to the "proposed
changes" section.
3. Roger and Ed make another pass thru the "Proposed Changes" section of
the ChangeLog and move things to "Accepted" or leave them in "Proposed"
Tasks B and C can run in parallel. I would like to ask for a volunteer
to install FrameMaker so Roger and I can have a helper on doing task C.
Sun owns some FrameMaker licenses, so I assume anyone that might buy
Sun will have access to these as well. This could mean that Andy,
Blake, or Matthias could step in and help. Anyone with a FrameMaker 7
license is welcome to be the helper.
Problem 2 Unfinished business from 20091202 meeting
===================================================
I'd like to spend 10 minutes getting an update on the JCP and list
situation, as well as on javaserverfaces.org.
I hope many people can make the meeting!
Ed
[1] http://wiki.jcp.org/wiki/index.php?page=JSF+2.0+Rev+A+Change+Log
[2] http://wiki.jcp.org/wiki/index.php?page=Jsf2ErrataScratchPad
[3] https://javaserverfaces-spec-public.dev.java.net/issues/reports.cgi?state...
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
Re: [jsr-314-open] Problem with Resource.getRequestPath() in a portlet environment
by Ed Burns
>>>>> On Mon, 18 Jan 2010 16:26:03 -0800, Alexander Smirnov <asmirnov(a)exadel.com> said:
AS> I've caught that problem too during development of the Jboss portletbridge.
AS> To those who are not familiar with subject: As required by JSR-301, Jsf
AS> Portlet bridge converts servlet URL to the Portlet ResourceURL in the
AS> ExternalContext#encodeResourceURL method that is never called for
AS> Mojarra resource URL's. Of course, that makes sense for
AS> session-independent resources in the servlet environment where
AS> "JSESSIONID" parameter only enforces browser to reload already cached
AS> resources but got us into a trouble in the portals.
I'm reviewing this thread now.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
Re: [jsr-314-open] getting behind CDI
by Ed Burns
>>>>> On Sat, 16 Jan 2010 07:56:10 -0800, Cay Horstmann <cay(a)horstmann.com> said:
CH> It seems so long ago that we had this discussion :-)
CH> I thought you might find it interesting that the Java EE tutorial does
CH> just what Dan asked for: They use @Named, not @ManagedBean, in their
CH> published examples. Look at
CH> http://java.sun.com/javaee/6/docs/tutorial/doc/gjcxv.html and search for
CH> "managed bean".
I'm relieved that the platform docs reflect the platform best practices!
Score one for quality.
Ed
--
| ed.burns(a)sun.com | office: 408 884 9519 OR x31640
| homepage: | http://ridingthecrest.com/
14 years, 11 months
