One of the major problems I see with using the wiki for this purpose is that when you paste in a huge block of text, you have to go back and enter in all these markup codes to make it stop linking to wikiwords. While wikiwords are useful when you are creating a wiki, it really sucks when you are just trying to put notes down.<br>
<br>-Dan<br><br><div class="gmail_quote">On Sun, Dec 13, 2009 at 1:46 PM, Dan Allen <span dir="ltr">&lt;<a href="mailto:dan.j.allen@gmail.com">dan.j.allen@gmail.com</a>&gt;</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;">
Wow, you guys got a lot of things covered. Good job!<br><br>I&#39;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" target="_blank">jcp.org</a> wiki under our section. The reason I suggest that rather than bundled at <a href="http://java.net" target="_blank">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" target="_blank">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&#39;m open to other ideas. The one downside of wikis is that they don&#39;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&#39;m open to that.<br>

<br>-Dan<div><div></div><div class="h5"><br><br><div class="gmail_quote">On Thu, Dec 10, 2009 at 9:41 PM, Jim Driscoll <span dir="ltr">&lt;<a href="mailto:Jim.Driscoll@sun.com" target="_blank">Jim.Driscoll@sun.com</a>&gt;</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&#39;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 &lt;Jim.Driscoll@Sun.COM&gt;<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&#39;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&#39; needs.<br>
<br>
There&#39;s a request for a new event - after complete, and after each<br>
individual dom update (success happens after *all* dom updates).  We&#39;ll<br>
need more details (I&#39;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&#39;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&#39;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&#39;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&#39;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&#39;ll have to check the spec to be sure.<br>
Regardless, this is a spec bug, and I&#39;ll file it.<br>
<br>
Be able to get a list of all registered JSF events.  (and, while we&#39;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 &lt;style&gt; 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></div></div><font color="#888888">-- <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" target="_blank">http://mojavelinux.com</a><br>

<a href="http://mojavelinux.com/seaminaction" target="_blank">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen" target="_blank">http://www.google.com/profiles/dan.j.allen</a><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>