Wow, you guys got a lot of things covered. Good job!<br><br>I'm wondering how we should archive meeting minutes from here on out. My thought is to put them on the <a href="http://jcp.org">jcp.org</a> wiki under our section. The reason I suggest that rather than bundled at <a href="http://java.net">java.net</a> is because it is just easier to find them, you can use an RSS feed, etc.<br>
<br><a href="http://wiki.jcp.org/wiki/index.php?page=JSR-314+Meetings">http://wiki.jcp.org/wiki/index.php?page=JSR-314+Meetings</a><br><br>There would be a new wiki page for each meeting.<br><br>I'm open to other ideas. The one downside of wikis is that they don't have any concept of cataloging. The main page just ends up being one long list of meetings, a list that is edited by hand. If there is something we can link out to, I'm open to that.<br>
<br>-Dan<br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 9:41 PM, Jim Driscoll <span dir="ltr"><<a href="mailto:Jim.Driscoll@sun.com">Jim.Driscoll@sun.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
FYI, these are the minutes from the Ajax meeting we held on Nov 24th.<br>
<br>
I'm still working off this list of issues, btw.<br>
<br>
Jim<br>
<br>
-------- Original Message --------<br>
Subject: [jsr-314-open] JSF Ajax Meeting Minutes<br>
Date: Tue, 24 Nov 2009 11:03:10 -0800<br>
From: Jim Driscoll <Jim.Driscoll@Sun.COM><br>
To: <a href="mailto:jsr-314-ajax-ext@sun.com" target="_blank">jsr-314-ajax-ext@sun.com</a><br>
<br>
<br>
Nov 24th, JSF Ajax Meeting minutes<br>
<br>
Attending<br>
<br>
Nick<br>
Alex<br>
Jay<br>
Ted<br>
Andy<br>
Roger<br>
Jim<br>
<br>
During the meeting, we primarily went over the following list of issues:<br>
<br>
<a href="http://www.jboss.org/community/wiki/JSFAjaxpointsfordiscussionwithEG" target="_blank">http://www.jboss.org/community/wiki/JSFAjaxpointsfordiscussionwithEG</a><br>
<br>
<br>
First up: PartialResponseWriter should be more intelligent about<br>
handling new elements when inside a component. spec bug 658.<br>
<br>
One idea: if a new element is started, write it out after the update is<br>
finished writing. This is a small spec change that could be a spec<br>
clarification, and a fix to the impl (the impl fix may take a little<br>
while - it's liable to be somewhat risky change). (AI: Jim will write<br>
up a tentative proposal)<br>
<br>
Other idea (from Alex): Allow for some override of PartialViewContext,<br>
to allow for a more robust rendering options. There were some concerns<br>
about multi-libarary compatability, and this would be an attempt to<br>
allow for better multi-libarary interop. Alex tentatively agreed to<br>
flesh out this idea, if the above proposal does not meet RichFaces' needs.<br>
<br>
There's a request for a new event - after complete, and after each<br>
individual dom update (success happens after *all* dom updates). We'll<br>
need more details (I'll add a new spec RFE for this).<br>
<br>
Errors - in the event that 3 updates happen, if the 2nd fails, the third<br>
should still be attempted. This falls into the level of spec<br>
clarification, and impl fix. I'll file appropriate bugs.<br>
<br>
Add request options to event payload. Alex will take AI to elaborate.<br>
<br>
Add begin, complete, success constants. ex: jsf.ajax.BEGIN ? I'll add<br>
a spec RFE.<br>
<br>
Add ability to abort a request before XHR is created: from the begin<br>
event, a token could be aquired, and an abort() function called. Jim<br>
will take the AI to write this up.<br>
<br>
Response XML needs a version attribute. I'll file a spec RFE.<br>
<br>
Add ability to skip response processing - prehaps an abort like begin?<br>
(Jim AI)<br>
<br>
Support for request timeout (will file as spec RFE) Can be quite<br>
serious, since a network error can result in a hung app. Would like a<br>
config param (from the server) on a per-app basis, js api for<br>
per-request. Since this is so serious in effect, I'll also file a impl<br>
RFE as well.<br>
<br>
Form serialization should happen at the last possible second (just<br>
before the begin event), not on submission time. There was wide<br>
agreement that this is a problem, and requires a spec change. May only<br>
be a spec clarification - I'll have to check the spec to be sure.<br>
Regardless, this is a spec bug, and I'll file it.<br>
<br>
Be able to get a list of all registered JSF events. (and, while we're<br>
at it, the ability to deregister an event)... This will probably<br>
require two new functions client-side. Jim will file RFE on spec.<br>
<br>
<br>
Address IE freeze for inline script eval - either setTimeout or<br>
execScript. (Jim will file impl bug).<br>
<br>
Add ability to append <style> tag as part of the component. (Jim will<br>
file as impl bug)<br>
<br>
The group agreed to meet at the JSF Summit (without Alex,<br>
unfortunately), tentatively on Thursday.<br>
<br>
Please reply-all with any corrections or additions to these minutes.<br><font color="#888888">
<br>
<br>
Jim<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br>
<a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>