You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Andrew Robinson <an...@gmail.com> on 2006/04/07 17:12:27 UTC
Improving AJAX support in MyFaces
One method of implementing AJAX is to re-render the page and only send
pieces down to the browser. This is the way AjaxAnywhere works.
However, it is not easy to get this to work in MyFaces with HTML
forms. The issue:
AJAX needs a way to identify HTML to replace on AJAX response. This is
usually done via id:
"document.getElementById('idFromAjaxResponse').innerHtml =
reponseData".
However, there is no containing HTML element for the "special" form
elements. These "special" elements include:
1) input type="hidden" elements that are rendered for parameters,
client-side state, etc.
2) script tag that contains the clear_[formid]() JavaScript function
that uses the above hidden input elements
In 1.1.1, these were placed at the top and bottom of the form. In
1.1.2/3 they are put only at the bottom, but in neither is the
capability that I would like.
Workaround I used: Extended the HtmlFormRenderer and buffered the
output of the endcodeEnd and encodeBegin. Then I loop through the
buffer and strip out all hidden input elements and JavaScript tags. I
then add the stripped portion into a new SPAN element that is
formatted for AjaxAnywhere to work.
How this could have been much easier:
Add 4 new methods to HtmlFormRendererBase:
public void beforeFormElementsStart(FacesContext facesContext,
UIComponent component)
throws IOException {}
public void afterFormElementsStart(FacesContext facesContext,
UIComponent component)
throws IOException {}
public void beforeFormElementsEnd(FacesContext facesContext,
UIComponent component)
throws IOException {}
public void afterFormElementsEnd(FacesContext facesContext,
UIComponent component)
throws IOException {}
These methods would the be called:
encodeBegin(...) {
...render the start tag...
call before form elements start
...render and elements into the form
call after form elements end
...
encodeEnd(...) {
call before form elements end
... render state, javascript etc. ...
call after form elements end
... render the form end tag ...
Then, with projects like AjaxAnywhere, users can extend
HtmlFormRenderer and implement these methods. In these methods, we can
write tags to contain this data that can be used in the AJAX code to
update on every request.
This would be a very simple change, would incur almost no overhead and
give complete flexibility that would be needed to AJAX authors to have
control over the special form behavior of JSF.
I wouldn't care about the method names, in fact there could be one
method with an enum argument that specifies before/after information.
What do you think? If it sounds good, could this be added to current
before the next release? Since it would be just empty methods, it
would not de-stabilize the current code.
Thanks,
Andrew
Re: Improving AJAX support in MyFaces
Posted by Lisaa <li...@yahoo.com>.
Hi.,
I just came accross an AJAX oriented DWR (Direct Web Remoting) .
Please take a look at the following pages if you are interested..
http://getahead.ltd.uk/dwr/overview/dwr
JSF-Integration
http://getahead.ltd.uk/dwr/server/jsf
Just a few minutes back I got this info...I have to start my play during
this weekend.
If anyone already knew about this and successfully using with JSF..please
post your comments.
Thanks.
--
View this message in context: http://www.nabble.com/Improving-AJAX-support-in-MyFaces-t1412639.html#a3877488
Sent from the MyFaces - Users forum at Nabble.com.
Re: Improving AJAX support in MyFaces
Posted by Andrew Robinson <an...@gmail.com>.
I made 2 patches, one for 1.1.1 and one for current SVN:
http://issues.apache.org/jira/browse/MYFACES-1276
On 4/8/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
> > Would it be possible to have those extra methods in the
> > HtmlFormRenderer? Or at least an equivalent to allow me to add HTML
> > code before and after the "special" form elements?
>
> Andrew, there's no reason why we can't add this functionality to the
> tomahawk form tag (provided we have one yet). Please open a JIRA
> issue and provide a patch adding them.
>
Re: Improving AJAX support in MyFaces
Posted by Mike Kienenberger <mk...@gmail.com>.
On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
> Would it be possible to have those extra methods in the
> HtmlFormRenderer? Or at least an equivalent to allow me to add HTML
> code before and after the "special" form elements?
Andrew, there's no reason why we can't add this functionality to the
tomahawk form tag (provided we have one yet). Please open a JIRA
issue and provide a patch adding them.
Re: Improving AJAX support in MyFaces
Posted by Andrew Robinson <an...@gmail.com>.
This is all great and well and good (honestly), except for the fact
that I am developing production code to do this right now.
AjaxAnywhere, although with it's limitations, is enabling me to
quickly get the AJAX support I need. Although not as nice as the
Avatar idea, it functions. With just a little help from the MyFaces
component model I could make it easier as well.
I don't want to risk more components and frameworks if I can help it
as each new tool means long hours of integration and work-arounds when
they don't fit 100% well together.
Would it be possible to have those extra methods in the
HtmlFormRenderer? Or at least an equivalent to allow me to add HTML
code before and after the "special" form elements?
On 4/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> Also, here's some useful links on incoming extensions to JSF :
>
> http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
> https://jsf-extensions.dev.java.net/#documentation
>
> On 4/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> > ADF partial page rendering should do the trick in my opinion, well as
> > soon as it is released.
> >
> > On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
> > > I am making the HTML render something like:
> > >
> > > <form id="myform" ...>
> > >
> > > <span id="aazone.JsfFormState">
> > > <input type="hidden" ... />
> > > <input type="hidden" ... />
> > > <input type="hidden" ... />
> > >
> > > <script>
> > > function clear_myform() {
> > > ...
> > > }
> > > </script>
> > > </span>
> > > </form>
> > >
> > > This way AjaxAnywhere is able to replace the inner HTML of
> > > "aazone.JsfFormState" on every AJAX reply.
> > >
> > > Right now I have to severly hack the HtmlForm to search for the input
> > > and script elements written by encodeBegin and encodeEnd so that my
> > > AJAX response will always send the new clear function and new hidden
> > > elements.
> > >
> > > There is no other easier way to do this with AjaxAnywhere 1.1.0.6 and
> > > I don't want to write my own AJAX JSF framework. This functionality
> > > will give me the ability to render start and end span tags around the
> > > HTML written by HtmlFormRenderer without having to write my own
> > > renderer or do the hack I am already doing.
> > >
> > > -Andrew
> > >
> > >
> > > On 4/7/06, Travis Reeder <tr...@gmail.com> wrote:
> > > > What are you trying to accomplish exactly?
> > > >
> > > > Travis
> > > >
> > > >
> > > > On 4/7/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > > One method of implementing AJAX is to re-render the page and only send
> > > > > pieces down to the browser. This is the way AjaxAnywhere works.
> > > > > However, it is not easy to get this to work in MyFaces with HTML
> > > > > forms. The issue:
> > > > >
> > > > > AJAX needs a way to identify HTML to replace on AJAX response. This is
> > > > > usually done via id:
> > > > > "document.getElementById('idFromAjaxResponse').innerHtml
> > > > =
> > > > > reponseData".
> > > > >
> > > > > However, there is no containing HTML element for the "special" form
> > > > > elements. These "special" elements include:
> > > > >
> > > > > 1) input type="hidden" elements that are rendered for parameters,
> > > > > client-side state, etc.
> > > > > 2) script tag that contains the clear_[formid]() JavaScript function
> > > > > that uses the above hidden input elements
> > > > >
> > > > > In 1.1.1, these were placed at the top and bottom of the form. In
> > > > > 1.1.2/3 they are put only at the bottom, but in neither is the
> > > > > capability that I would like.
> > > > >
> > > > > Workaround I used: Extended the HtmlFormRenderer and buffered the
> > > > > output of the endcodeEnd and encodeBegin. Then I loop through the
> > > > > buffer and strip out all hidden input elements and JavaScript tags. I
> > > > > then add the stripped portion into a new SPAN element that is
> > > > > formatted for AjaxAnywhere to work.
> > > > >
> > > > > How this could have been much easier:
> > > > >
> > > > > Add 4 new methods to HtmlFormRendererBase:
> > > > > public void beforeFormElementsStart(FacesContext
> > > > facesContext,
> > > > > UIComponent component)
> > > > > throws IOException {}
> > > > > public void afterFormElementsStart(FacesContext
> > > > facesContext,
> > > > > UIComponent component)
> > > > > throws IOException {}
> > > > > public void beforeFormElementsEnd(FacesContext
> > > > facesContext,
> > > > > UIComponent component)
> > > > > throws IOException {}
> > > > > public void afterFormElementsEnd(FacesContext
> > > > facesContext,
> > > > > UIComponent component)
> > > > > throws IOException {}
> > > > >
> > > > > These methods would the be called:
> > > > > encodeBegin(...) {
> > > > > ...render the start tag...
> > > > > call before form elements start
> > > > > ...render and elements into the form
> > > > > call after form elements end
> > > > >
> > > > > ...
> > > > >
> > > > > encodeEnd(...) {
> > > > > call before form elements end
> > > > > ... render state, javascript etc. ...
> > > > > call after form elements end
> > > > > ... render the form end tag ...
> > > > >
> > > > >
> > > > > Then, with projects like AjaxAnywhere, users can extend
> > > > > HtmlFormRenderer and implement these methods. In these methods, we can
> > > > > write tags to contain this data that can be used in the AJAX code to
> > > > > update on every request.
> > > > >
> > > > > This would be a very simple change, would incur almost no overhead and
> > > > > give complete flexibility that would be needed to AJAX authors to have
> > > > > control over the special form behavior of JSF.
> > > > >
> > > > > I wouldn't care about the method names, in fact there could be one
> > > > > method with an enum argument that specifies before/after information.
> > > > >
> > > > > What do you think? If it sounds good, could this be added to current
> > > > > before the next release? Since it would be just empty methods, it
> > > > > would not de-stabilize the current code.
> > > > >
> > > > > Thanks,
> > > > > Andrew
> > > > >
> > > >
> > > >
> > >
> >
> >
> > --
> > Alexandre Poitras
> > Québec, Canada
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
Re: Improving AJAX support in MyFaces
Posted by Alexandre Poitras <al...@gmail.com>.
Also, here's some useful links on incoming extensions to JSF :
http://weblogs.java.net/blog/jhook/archive/2005/09/jsf_avatar_vs_m_1.html
https://jsf-extensions.dev.java.net/#documentation
On 4/7/06, Alexandre Poitras <al...@gmail.com> wrote:
> ADF partial page rendering should do the trick in my opinion, well as
> soon as it is released.
>
> On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
> > I am making the HTML render something like:
> >
> > <form id="myform" ...>
> >
> > <span id="aazone.JsfFormState">
> > <input type="hidden" ... />
> > <input type="hidden" ... />
> > <input type="hidden" ... />
> >
> > <script>
> > function clear_myform() {
> > ...
> > }
> > </script>
> > </span>
> > </form>
> >
> > This way AjaxAnywhere is able to replace the inner HTML of
> > "aazone.JsfFormState" on every AJAX reply.
> >
> > Right now I have to severly hack the HtmlForm to search for the input
> > and script elements written by encodeBegin and encodeEnd so that my
> > AJAX response will always send the new clear function and new hidden
> > elements.
> >
> > There is no other easier way to do this with AjaxAnywhere 1.1.0.6 and
> > I don't want to write my own AJAX JSF framework. This functionality
> > will give me the ability to render start and end span tags around the
> > HTML written by HtmlFormRenderer without having to write my own
> > renderer or do the hack I am already doing.
> >
> > -Andrew
> >
> >
> > On 4/7/06, Travis Reeder <tr...@gmail.com> wrote:
> > > What are you trying to accomplish exactly?
> > >
> > > Travis
> > >
> > >
> > > On 4/7/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > > One method of implementing AJAX is to re-render the page and only send
> > > > pieces down to the browser. This is the way AjaxAnywhere works.
> > > > However, it is not easy to get this to work in MyFaces with HTML
> > > > forms. The issue:
> > > >
> > > > AJAX needs a way to identify HTML to replace on AJAX response. This is
> > > > usually done via id:
> > > > "document.getElementById('idFromAjaxResponse').innerHtml
> > > =
> > > > reponseData".
> > > >
> > > > However, there is no containing HTML element for the "special" form
> > > > elements. These "special" elements include:
> > > >
> > > > 1) input type="hidden" elements that are rendered for parameters,
> > > > client-side state, etc.
> > > > 2) script tag that contains the clear_[formid]() JavaScript function
> > > > that uses the above hidden input elements
> > > >
> > > > In 1.1.1, these were placed at the top and bottom of the form. In
> > > > 1.1.2/3 they are put only at the bottom, but in neither is the
> > > > capability that I would like.
> > > >
> > > > Workaround I used: Extended the HtmlFormRenderer and buffered the
> > > > output of the endcodeEnd and encodeBegin. Then I loop through the
> > > > buffer and strip out all hidden input elements and JavaScript tags. I
> > > > then add the stripped portion into a new SPAN element that is
> > > > formatted for AjaxAnywhere to work.
> > > >
> > > > How this could have been much easier:
> > > >
> > > > Add 4 new methods to HtmlFormRendererBase:
> > > > public void beforeFormElementsStart(FacesContext
> > > facesContext,
> > > > UIComponent component)
> > > > throws IOException {}
> > > > public void afterFormElementsStart(FacesContext
> > > facesContext,
> > > > UIComponent component)
> > > > throws IOException {}
> > > > public void beforeFormElementsEnd(FacesContext
> > > facesContext,
> > > > UIComponent component)
> > > > throws IOException {}
> > > > public void afterFormElementsEnd(FacesContext
> > > facesContext,
> > > > UIComponent component)
> > > > throws IOException {}
> > > >
> > > > These methods would the be called:
> > > > encodeBegin(...) {
> > > > ...render the start tag...
> > > > call before form elements start
> > > > ...render and elements into the form
> > > > call after form elements end
> > > >
> > > > ...
> > > >
> > > > encodeEnd(...) {
> > > > call before form elements end
> > > > ... render state, javascript etc. ...
> > > > call after form elements end
> > > > ... render the form end tag ...
> > > >
> > > >
> > > > Then, with projects like AjaxAnywhere, users can extend
> > > > HtmlFormRenderer and implement these methods. In these methods, we can
> > > > write tags to contain this data that can be used in the AJAX code to
> > > > update on every request.
> > > >
> > > > This would be a very simple change, would incur almost no overhead and
> > > > give complete flexibility that would be needed to AJAX authors to have
> > > > control over the special form behavior of JSF.
> > > >
> > > > I wouldn't care about the method names, in fact there could be one
> > > > method with an enum argument that specifies before/after information.
> > > >
> > > > What do you think? If it sounds good, could this be added to current
> > > > before the next release? Since it would be just empty methods, it
> > > > would not de-stabilize the current code.
> > > >
> > > > Thanks,
> > > > Andrew
> > > >
> > >
> > >
> >
>
>
> --
> Alexandre Poitras
> Québec, Canada
>
--
Alexandre Poitras
Québec, Canada
Re: Improving AJAX support in MyFaces
Posted by Alexandre Poitras <al...@gmail.com>.
ADF partial page rendering should do the trick in my opinion, well as
soon as it is released.
On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
> I am making the HTML render something like:
>
> <form id="myform" ...>
>
> <span id="aazone.JsfFormState">
> <input type="hidden" ... />
> <input type="hidden" ... />
> <input type="hidden" ... />
>
> <script>
> function clear_myform() {
> ...
> }
> </script>
> </span>
> </form>
>
> This way AjaxAnywhere is able to replace the inner HTML of
> "aazone.JsfFormState" on every AJAX reply.
>
> Right now I have to severly hack the HtmlForm to search for the input
> and script elements written by encodeBegin and encodeEnd so that my
> AJAX response will always send the new clear function and new hidden
> elements.
>
> There is no other easier way to do this with AjaxAnywhere 1.1.0.6 and
> I don't want to write my own AJAX JSF framework. This functionality
> will give me the ability to render start and end span tags around the
> HTML written by HtmlFormRenderer without having to write my own
> renderer or do the hack I am already doing.
>
> -Andrew
>
>
> On 4/7/06, Travis Reeder <tr...@gmail.com> wrote:
> > What are you trying to accomplish exactly?
> >
> > Travis
> >
> >
> > On 4/7/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > > One method of implementing AJAX is to re-render the page and only send
> > > pieces down to the browser. This is the way AjaxAnywhere works.
> > > However, it is not easy to get this to work in MyFaces with HTML
> > > forms. The issue:
> > >
> > > AJAX needs a way to identify HTML to replace on AJAX response. This is
> > > usually done via id:
> > > "document.getElementById('idFromAjaxResponse').innerHtml
> > =
> > > reponseData".
> > >
> > > However, there is no containing HTML element for the "special" form
> > > elements. These "special" elements include:
> > >
> > > 1) input type="hidden" elements that are rendered for parameters,
> > > client-side state, etc.
> > > 2) script tag that contains the clear_[formid]() JavaScript function
> > > that uses the above hidden input elements
> > >
> > > In 1.1.1, these were placed at the top and bottom of the form. In
> > > 1.1.2/3 they are put only at the bottom, but in neither is the
> > > capability that I would like.
> > >
> > > Workaround I used: Extended the HtmlFormRenderer and buffered the
> > > output of the endcodeEnd and encodeBegin. Then I loop through the
> > > buffer and strip out all hidden input elements and JavaScript tags. I
> > > then add the stripped portion into a new SPAN element that is
> > > formatted for AjaxAnywhere to work.
> > >
> > > How this could have been much easier:
> > >
> > > Add 4 new methods to HtmlFormRendererBase:
> > > public void beforeFormElementsStart(FacesContext
> > facesContext,
> > > UIComponent component)
> > > throws IOException {}
> > > public void afterFormElementsStart(FacesContext
> > facesContext,
> > > UIComponent component)
> > > throws IOException {}
> > > public void beforeFormElementsEnd(FacesContext
> > facesContext,
> > > UIComponent component)
> > > throws IOException {}
> > > public void afterFormElementsEnd(FacesContext
> > facesContext,
> > > UIComponent component)
> > > throws IOException {}
> > >
> > > These methods would the be called:
> > > encodeBegin(...) {
> > > ...render the start tag...
> > > call before form elements start
> > > ...render and elements into the form
> > > call after form elements end
> > >
> > > ...
> > >
> > > encodeEnd(...) {
> > > call before form elements end
> > > ... render state, javascript etc. ...
> > > call after form elements end
> > > ... render the form end tag ...
> > >
> > >
> > > Then, with projects like AjaxAnywhere, users can extend
> > > HtmlFormRenderer and implement these methods. In these methods, we can
> > > write tags to contain this data that can be used in the AJAX code to
> > > update on every request.
> > >
> > > This would be a very simple change, would incur almost no overhead and
> > > give complete flexibility that would be needed to AJAX authors to have
> > > control over the special form behavior of JSF.
> > >
> > > I wouldn't care about the method names, in fact there could be one
> > > method with an enum argument that specifies before/after information.
> > >
> > > What do you think? If it sounds good, could this be added to current
> > > before the next release? Since it would be just empty methods, it
> > > would not de-stabilize the current code.
> > >
> > > Thanks,
> > > Andrew
> > >
> >
> >
>
--
Alexandre Poitras
Québec, Canada
Re: Improving AJAX support in MyFaces
Posted by Andrew Robinson <an...@gmail.com>.
I am making the HTML render something like:
<form id="myform" ...>
<span id="aazone.JsfFormState">
<input type="hidden" ... />
<input type="hidden" ... />
<input type="hidden" ... />
<script>
function clear_myform() {
...
}
</script>
</span>
</form>
This way AjaxAnywhere is able to replace the inner HTML of
"aazone.JsfFormState" on every AJAX reply.
Right now I have to severly hack the HtmlForm to search for the input
and script elements written by encodeBegin and encodeEnd so that my
AJAX response will always send the new clear function and new hidden
elements.
There is no other easier way to do this with AjaxAnywhere 1.1.0.6 and
I don't want to write my own AJAX JSF framework. This functionality
will give me the ability to render start and end span tags around the
HTML written by HtmlFormRenderer without having to write my own
renderer or do the hack I am already doing.
-Andrew
On 4/7/06, Travis Reeder <tr...@gmail.com> wrote:
> What are you trying to accomplish exactly?
>
> Travis
>
>
> On 4/7/06, Andrew Robinson <andrew.rw.robinson@gmail.com > wrote:
> > One method of implementing AJAX is to re-render the page and only send
> > pieces down to the browser. This is the way AjaxAnywhere works.
> > However, it is not easy to get this to work in MyFaces with HTML
> > forms. The issue:
> >
> > AJAX needs a way to identify HTML to replace on AJAX response. This is
> > usually done via id:
> > "document.getElementById('idFromAjaxResponse').innerHtml
> =
> > reponseData".
> >
> > However, there is no containing HTML element for the "special" form
> > elements. These "special" elements include:
> >
> > 1) input type="hidden" elements that are rendered for parameters,
> > client-side state, etc.
> > 2) script tag that contains the clear_[formid]() JavaScript function
> > that uses the above hidden input elements
> >
> > In 1.1.1, these were placed at the top and bottom of the form. In
> > 1.1.2/3 they are put only at the bottom, but in neither is the
> > capability that I would like.
> >
> > Workaround I used: Extended the HtmlFormRenderer and buffered the
> > output of the endcodeEnd and encodeBegin. Then I loop through the
> > buffer and strip out all hidden input elements and JavaScript tags. I
> > then add the stripped portion into a new SPAN element that is
> > formatted for AjaxAnywhere to work.
> >
> > How this could have been much easier:
> >
> > Add 4 new methods to HtmlFormRendererBase:
> > public void beforeFormElementsStart(FacesContext
> facesContext,
> > UIComponent component)
> > throws IOException {}
> > public void afterFormElementsStart(FacesContext
> facesContext,
> > UIComponent component)
> > throws IOException {}
> > public void beforeFormElementsEnd(FacesContext
> facesContext,
> > UIComponent component)
> > throws IOException {}
> > public void afterFormElementsEnd(FacesContext
> facesContext,
> > UIComponent component)
> > throws IOException {}
> >
> > These methods would the be called:
> > encodeBegin(...) {
> > ...render the start tag...
> > call before form elements start
> > ...render and elements into the form
> > call after form elements end
> >
> > ...
> >
> > encodeEnd(...) {
> > call before form elements end
> > ... render state, javascript etc. ...
> > call after form elements end
> > ... render the form end tag ...
> >
> >
> > Then, with projects like AjaxAnywhere, users can extend
> > HtmlFormRenderer and implement these methods. In these methods, we can
> > write tags to contain this data that can be used in the AJAX code to
> > update on every request.
> >
> > This would be a very simple change, would incur almost no overhead and
> > give complete flexibility that would be needed to AJAX authors to have
> > control over the special form behavior of JSF.
> >
> > I wouldn't care about the method names, in fact there could be one
> > method with an enum argument that specifies before/after information.
> >
> > What do you think? If it sounds good, could this be added to current
> > before the next release? Since it would be just empty methods, it
> > would not de-stabilize the current code.
> >
> > Thanks,
> > Andrew
> >
>
>
Re: Improving AJAX support in MyFaces
Posted by Travis Reeder <tr...@gmail.com>.
What are you trying to accomplish exactly?
Travis
On 4/7/06, Andrew Robinson <an...@gmail.com> wrote:
>
> One method of implementing AJAX is to re-render the page and only send
> pieces down to the browser. This is the way AjaxAnywhere works.
> However, it is not easy to get this to work in MyFaces with HTML
> forms. The issue:
>
> AJAX needs a way to identify HTML to replace on AJAX response. This is
> usually done via id:
> "document.getElementById('idFromAjaxResponse').innerHtml =
> reponseData".
>
> However, there is no containing HTML element for the "special" form
> elements. These "special" elements include:
>
> 1) input type="hidden" elements that are rendered for parameters,
> client-side state, etc.
> 2) script tag that contains the clear_[formid]() JavaScript function
> that uses the above hidden input elements
>
> In 1.1.1, these were placed at the top and bottom of the form. In
> 1.1.2/3 they are put only at the bottom, but in neither is the
> capability that I would like.
>
> Workaround I used: Extended the HtmlFormRenderer and buffered the
> output of the endcodeEnd and encodeBegin. Then I loop through the
> buffer and strip out all hidden input elements and JavaScript tags. I
> then add the stripped portion into a new SPAN element that is
> formatted for AjaxAnywhere to work.
>
> How this could have been much easier:
>
> Add 4 new methods to HtmlFormRendererBase:
> public void beforeFormElementsStart(FacesContext facesContext,
> UIComponent component)
> throws IOException {}
> public void afterFormElementsStart(FacesContext facesContext,
> UIComponent component)
> throws IOException {}
> public void beforeFormElementsEnd(FacesContext facesContext,
> UIComponent component)
> throws IOException {}
> public void afterFormElementsEnd(FacesContext facesContext,
> UIComponent component)
> throws IOException {}
>
> These methods would the be called:
> encodeBegin(...) {
> ...render the start tag...
> call before form elements start
> ...render and elements into the form
> call after form elements end
>
> ...
>
> encodeEnd(...) {
> call before form elements end
> ... render state, javascript etc. ...
> call after form elements end
> ... render the form end tag ...
>
>
> Then, with projects like AjaxAnywhere, users can extend
> HtmlFormRenderer and implement these methods. In these methods, we can
> write tags to contain this data that can be used in the AJAX code to
> update on every request.
>
> This would be a very simple change, would incur almost no overhead and
> give complete flexibility that would be needed to AJAX authors to have
> control over the special form behavior of JSF.
>
> I wouldn't care about the method names, in fact there could be one
> method with an enum argument that specifies before/after information.
>
> What do you think? If it sounds good, could this be added to current
> before the next release? Since it would be just empty methods, it
> would not de-stabilize the current code.
>
> Thanks,
> Andrew
>