You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by Stan Carney <st...@moohoffa.com> on 2007/05/26 02:19:19 UTC
JSF and AJAX without custom components?
Hello,
I was wondering if anybody has had any success with JSF and AJAX outside
of building custom components? We are fortunate to have a very talented
UI developer with a strong knowledge of JQuery and Taconite and we would
like to leverage his abilities as much as possible. We are using
Facelets on top of MyFaces with JQuery and Taconite moderate success
with the exception of forms due to JSF's state management facility.
Based on all my reading of similar solutions I have come up with the
following, not yet fully completed or working solution to the age old
Country/Subdivision problem. i.e. when the user picks a country from a
select box on a form the country subdivision select box (i.e. states,
provinces, etc..) are retrieved via AJAX and inserted into the DOM.
1) Use JavaScript to find the value and submit the javax.faces.ViewState
hidden form field along with the country code using a GET to the same
URL as the viewId value in the embedded javax.faces.ViewState field.
2) Created a PhaseListener that runs after the RestoreView phase that
detects the request is an Ajax call via configurable query string
parameters.
3) PhaseListener finds the HtmlSelectOneMenu component for the country
subdivision field by it's id, clears existing children and updates the
list with the new subdivisions. See code below:
FacesContext facesContext = FacesContext.getCurrentInstance();
HtmlSelectOneMenu c = (HtmlSelectOneMenu)
facesContext.getViewRoot().findComponent("form:country-subdivision");
List children = c.getChildren();
children.clear();
children.addAll(selectBoxUtils.convertSelectItemToUISelectItem(subdivisions));
4) The new state is saved via the following code (based on similar
examples and lots of debugging):
SerializedView serializedview =
facesContext.getApplication().getStateManager().saveSerializedView(facesContext);
Object[] savedState = new Object[3];
Object treeStruct = serializedview.getStructure();
if (treeStruct != null) {
if (treeStruct instanceof String) {
savedState[0] = treeStruct;
}
}
savedState[2] = facesContext.getViewRoot().getViewId();
String viewState = StateUtils.construct(savedState,
facesContext.getExternalContext());
5) The javax.faces.ViewState field (viewState from above code) is
returned in an XML response and inserted into the DOM via taconite.
6) The PhaseListener then marks the response as complete.
Unfortunately it isn't working 100% because I think I'm not updating the
state properly somewhere. Either that or not returning the correct
sequence number or not getting it into the StateManager correctly. But
before I proceed any further I wanted to solicit advice from others that
have done this before.
Thoughts?
Thanks,
Stan
Re: JSF and AJAX without custom components?
Posted by Ernst Fastl <er...@gmail.com>.
Hi Stan,
Thank you for the insights to your solution. It sounds very interesting
indeed. Hope we'll hear again from you on the list.
kind regards
Ernst
On 6/5/07, Stan Carney <st...@moohoffa.com> wrote:
> Thanks for your response Ernst!
>
> Yeah, I have looked around at pretty much every JSF AJAX framework out
> there and it isn't that I'm not impressed. There are definitely some
> smart people working to create generic components to be consumed by the
> masses. In our current position though I don't think these frameworks
> make a lot of sense for us to use. We have an extremely strong UI
> developer and we just want to be able to expose his talents, and in our
> current circumstance having to use pre-built AJAX components or having
> to create our own would severely hamper his abilities.
>
> So anyway I have solved my problem via the following process. It allows
> us to interact with JSF, i.e. forms, via AJAX without having to write
> components. It has some significant short comings if it was going to be
> used for general consumption by the JSF community (i.e. lacking
> configuration, you can shoot your foot off easily, etc...) but works for
> us. So keeping with good list etiquette I'm posting my solution below
> for those, if any, that get a hit on my initial question.
>
>
> I have created a PhaseListener that runs after the RESTORE_VIEW phase
> and checks for the presence of a known parameter. Every parameter on
> every request is checked which I'm not a fan of but from what I have
> seen most other JSF/AJAX solutions do the same and it appears to run
> super fast. If a 'known' parameter exists the PhaseListener instantiates
> the class associated with the parameter for processing. In my case all
> of these 'processor' classes implement a simple interface with one
> method, process(), that takes a CaseInsensitiveMap as an argument. This
> map contains the map returned value from the getParameterMap() method on
> HttpServletRequest:
>
> HttpServletRequest req = (HttpServletRequest)
> event.getFacesContext().getExternalContext().getRequest();
> CaseInsensitiveMap map = new CaseInsensitiveMap();
> map.putAll(req.getParameterMap());
>
> The process() method then does what it needs to do. Typically finding
> components by their ids in the restored view, that are either known by
> the class or sent as parameters, and updating their values accordingly.
> Then the class composes an XML document that our client side JavaScript
> (taconite and/or JQuery) understands and returns this XML string. The
> PhaseListener then determines if the returned string contains a
> javax.faces.ViewState placeholder we came up with and substitutes the
> placeholder with the new ViewState value generated below. If there is no
> placeholder, i.e. not interacting with a JSF form, we can omit the
> updating of the ViewState value. In that case though we typically do
> straight HTTP and bypass JSF completely.
>
> try {
> UIViewRoot viewRoot = context.getViewRoot();
>
> StateManager stateMgr =
> context.getApplication().getStateManager();
> ComponentSupport.removeTransient(viewRoot);
>
> SerializedView serializedView =
> stateMgr.saveSerializedView(context);
>
> Object[] savedState = new Object[3];
> Object treeStruct = serializedView.getStructure();
> if (treeStruct != null) {
> if (treeStruct instanceof String) {
> savedState[0] = treeStruct;
> }
> }
> savedState[2] = viewRoot.getViewId();
> String viewState = StateUtils.construct(savedState,
> context.getExternalContext());
>
> return viewState;
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
>
> The PhaseListener writes out the string to the response stream and marks
> the response as complete. The client JavaScript interprets the XML and
> updates the DOM. The DOM should now match the DOM stored on the server.
>
> It works well for us and results in the creation of only one class,
> after the initial PhaseListener creation, per Ajaxable event. The above
> code does tinker with the internal workings of MyFaces which may/will
> cause us issues on an upgrade. I haven't tested it for thread-safety yet
> but everything I have seen with other frameworks leads me to believe all
> is well.
>
> Thanks,
> Stan
>
>
> Ernst Fastl wrote:
> > Hi,
> >
> > I can understand you don't like to write your own component for
> > soving this problem (although seeing the stuff you posted I guess
> > you are skilled enough for that).
> >
> > Anyway, have you tried the
> > existing solutions like PPRPanelGroup from the tomahawk sandbox
> > or Ajax4JSF?
> >
> > regards
> >
> > Ernst
>
Re: JSF and AJAX without custom components?
Posted by Stan Carney <st...@moohoffa.com>.
Werner Punz wrote:
> Actually the idea mostly is if you can not to call the jsf layer at all,
> but to call something which does not trigger the faces servlet, since
> you do not have to rely on jsf anyway in your case.
> Hence you should not run into viewid issues at all (correct me here if I
> am wrong but I am rather sure this works)
>
I think we have had a misunderstanding along the way. We do bypass JSF
in certain cases where we don't need JSF. We do this via a Spring aware
servlet.
In cases where we do need JSF and AJAX together we use the custom built
Phase Listener. Originally I thought you suggested replacing the Phase
Listener with a JSF aware servlet to avoid having the PhaseListener
being called on every JSF request. I think this still makes sense from a
performance standpoint but I'm not sure how much work it would be to
mimic the behavior of a Phase Listener that is called after the
RESTORE_VIEW phase in a servlet.
Thanks,
Stan
Re: JSF and AJAX without custom components?
Posted by Werner Punz <we...@gmail.com>.
Stan Carney schrieb:
> Looking at the source code of FacesServlet it seems pretty straight
> forward. What would I have to do to get JSF to complete the RESTORE_VIEW
> phase and stop without a phase listener? Won't I also have problems with
> the pesky javax.faces.ViewState containing the wrong viewId and not
> restoring state?
>
Actually the idea mostly is if you can not to call the jsf layer at all,
but to call something which does not trigger the faces servlet, since
you do not have to rely on jsf anyway in your case.
Hence you should not run into viewid issues at all (correct me here if I
am wrong but I am rather sure this works)
Re: JSF and AJAX without custom components?
Posted by Stan Carney <st...@moohoffa.com>.
Yeah, we actually make use of Springs ServletWrappingController class
when we don't need JSF. i.e. no forms etc...
From a performance standpoint you do have a good point actually. So
rather than a phase listener that is hit on every single JSF request
just use a Servlet that mimics FacesServlet but just performs the task
that you need done when called directly.
Looking at the source code of FacesServlet it seems pretty straight
forward. What would I have to do to get JSF to complete the RESTORE_VIEW
phase and stop without a phase listener? Won't I also have problems with
the pesky javax.faces.ViewState containing the wrong viewId and not
restoring state?
i.e.
Servlet URL: /path/to/servlet.foo
viewId: /my/page.xhtml
Thanks,
Stan
Werner Punz wrote:
> For specialized cases it might be better to use servlets or servlet
> filters as callback points.
> The problem with phase listeners is they are called every time a request
> is triggered.
> The + side is, that you do not have to initialize jsf it is
> preinitialized for you if you need access to the jsf inastructure
>
> (which in many cases you wont need anyway, especially if you are on ejb3
> or spring for providing the backend beans)
> The other + side is, phase listeners are deployed more easily as we all
> know.
>
> So either way has its ups and downs, but if speed is a concern than
> going the servlet route really might be better!
>
>
>
> Stan Carney schrieb:
>
>> Thanks for your response Ernst!
>>
>> Yeah, I have looked around at pretty much every JSF AJAX framework out
>> there and it isn't that I'm not impressed. There are definitely some
>> smart people working to create generic components to be consumed by the
>> masses. In our current position though I don't think these frameworks
>> make a lot of sense for us to use. We have an extremely strong UI
>> developer and we just want to be able to expose his talents, and in our
>> current circumstance having to use pre-built AJAX components or having
>> to create our own would severely hamper his abilities.
>>
>> So anyway I have solved my problem via the following process. It allows
>> us to interact with JSF, i.e. forms, via AJAX without having to write
>> components. It has some significant short comings if it was going to be
>> used for general consumption by the JSF community (i.e. lacking
>> configuration, you can shoot your foot off easily, etc...) but works for
>> us. So keeping with good list etiquette I'm posting my solution below
>> for those, if any, that get a hit on my initial question.
>>
>>
>> I have created a PhaseListener that runs after the RESTORE_VIEW phase
>> and checks for the presence of a known parameter. Every parameter on
>> every request is checked which I'm not a fan of but from what I have
>> seen most other JSF/AJAX solutions do the same and it appears to run
>> super fast. If a 'known' parameter exists the PhaseListener instantiates
>> the class associated with the parameter for processing. In my case all
>> of these 'processor' classes implement a simple interface with one
>> method, process(), that takes a CaseInsensitiveMap as an argument. This
>> map contains the map returned value from the getParameterMap() method on
>> HttpServletRequest:
>>
>> HttpServletRequest req = (HttpServletRequest)
>> event.getFacesContext().getExternalContext().getRequest();
>> CaseInsensitiveMap map = new CaseInsensitiveMap();
>> map.putAll(req.getParameterMap());
>>
>> The process() method then does what it needs to do. Typically finding
>> components by their ids in the restored view, that are either known by
>> the class or sent as parameters, and updating their values accordingly.
>> Then the class composes an XML document that our client side JavaScript
>> (taconite and/or JQuery) understands and returns this XML string. The
>> PhaseListener then determines if the returned string contains a
>> javax.faces.ViewState placeholder we came up with and substitutes the
>> placeholder with the new ViewState value generated below. If there is no
>> placeholder, i.e. not interacting with a JSF form, we can omit the
>> updating of the ViewState value. In that case though we typically do
>> straight HTTP and bypass JSF completely.
>>
>> try {
>> UIViewRoot viewRoot = context.getViewRoot();
>>
>> StateManager stateMgr =
>> context.getApplication().getStateManager();
>> ComponentSupport.removeTransient(viewRoot);
>>
>> SerializedView serializedView =
>> stateMgr.saveSerializedView(context);
>>
>> Object[] savedState = new Object[3];
>> Object treeStruct = serializedView.getStructure();
>> if (treeStruct != null) {
>> if (treeStruct instanceof String) {
>> savedState[0] = treeStruct;
>> }
>> }
>> savedState[2] = viewRoot.getViewId();
>> String viewState = StateUtils.construct(savedState,
>> context.getExternalContext());
>>
>> return viewState;
>> } catch (Exception e) {
>> throw new RuntimeException(e);
>> }
>>
>> The PhaseListener writes out the string to the response stream and marks
>> the response as complete. The client JavaScript interprets the XML and
>> updates the DOM. The DOM should now match the DOM stored on the server.
>>
>> It works well for us and results in the creation of only one class,
>> after the initial PhaseListener creation, per Ajaxable event. The above
>> code does tinker with the internal workings of MyFaces which may/will
>> cause us issues on an upgrade. I haven't tested it for thread-safety yet
>> but everything I have seen with other frameworks leads me to believe all
>> is well.
>>
>> Thanks,
>> Stan
>>
>>
>> Ernst Fastl wrote:
>>
>>> Hi,
>>>
>>> I can understand you don't like to write your own component for
>>> soving this problem (although seeing the stuff you posted I guess
>>> you are skilled enough for that).
>>>
>>> Anyway, have you tried the
>>> existing solutions like PPRPanelGroup from the tomahawk sandbox
>>> or Ajax4JSF?
>>>
>>> regards
>>>
>>> Ernst
>>>
Re: JSF and AJAX without custom components?
Posted by Werner Punz <we...@gmail.com>.
For specialized cases it might be better to use servlets or servlet
filters as callback points.
The problem with phase listeners is they are called every time a request
is triggered.
The + side is, that you do not have to initialize jsf it is
preinitialized for you if you need access to the jsf inastructure
(which in many cases you wont need anyway, especially if you are on ejb3
or spring for providing the backend beans)
The other + side is, phase listeners are deployed more easily as we all
know.
So either way has its ups and downs, but if speed is a concern than
going the servlet route really might be better!
Stan Carney schrieb:
> Thanks for your response Ernst!
>
> Yeah, I have looked around at pretty much every JSF AJAX framework out
> there and it isn't that I'm not impressed. There are definitely some
> smart people working to create generic components to be consumed by the
> masses. In our current position though I don't think these frameworks
> make a lot of sense for us to use. We have an extremely strong UI
> developer and we just want to be able to expose his talents, and in our
> current circumstance having to use pre-built AJAX components or having
> to create our own would severely hamper his abilities.
>
> So anyway I have solved my problem via the following process. It allows
> us to interact with JSF, i.e. forms, via AJAX without having to write
> components. It has some significant short comings if it was going to be
> used for general consumption by the JSF community (i.e. lacking
> configuration, you can shoot your foot off easily, etc...) but works for
> us. So keeping with good list etiquette I'm posting my solution below
> for those, if any, that get a hit on my initial question.
>
>
> I have created a PhaseListener that runs after the RESTORE_VIEW phase
> and checks for the presence of a known parameter. Every parameter on
> every request is checked which I'm not a fan of but from what I have
> seen most other JSF/AJAX solutions do the same and it appears to run
> super fast. If a 'known' parameter exists the PhaseListener instantiates
> the class associated with the parameter for processing. In my case all
> of these 'processor' classes implement a simple interface with one
> method, process(), that takes a CaseInsensitiveMap as an argument. This
> map contains the map returned value from the getParameterMap() method on
> HttpServletRequest:
>
> HttpServletRequest req = (HttpServletRequest)
> event.getFacesContext().getExternalContext().getRequest();
> CaseInsensitiveMap map = new CaseInsensitiveMap();
> map.putAll(req.getParameterMap());
>
> The process() method then does what it needs to do. Typically finding
> components by their ids in the restored view, that are either known by
> the class or sent as parameters, and updating their values accordingly.
> Then the class composes an XML document that our client side JavaScript
> (taconite and/or JQuery) understands and returns this XML string. The
> PhaseListener then determines if the returned string contains a
> javax.faces.ViewState placeholder we came up with and substitutes the
> placeholder with the new ViewState value generated below. If there is no
> placeholder, i.e. not interacting with a JSF form, we can omit the
> updating of the ViewState value. In that case though we typically do
> straight HTTP and bypass JSF completely.
>
> try {
> UIViewRoot viewRoot = context.getViewRoot();
>
> StateManager stateMgr =
> context.getApplication().getStateManager();
> ComponentSupport.removeTransient(viewRoot);
>
> SerializedView serializedView =
> stateMgr.saveSerializedView(context);
>
> Object[] savedState = new Object[3];
> Object treeStruct = serializedView.getStructure();
> if (treeStruct != null) {
> if (treeStruct instanceof String) {
> savedState[0] = treeStruct;
> }
> }
> savedState[2] = viewRoot.getViewId();
> String viewState = StateUtils.construct(savedState,
> context.getExternalContext());
>
> return viewState;
> } catch (Exception e) {
> throw new RuntimeException(e);
> }
>
> The PhaseListener writes out the string to the response stream and marks
> the response as complete. The client JavaScript interprets the XML and
> updates the DOM. The DOM should now match the DOM stored on the server.
>
> It works well for us and results in the creation of only one class,
> after the initial PhaseListener creation, per Ajaxable event. The above
> code does tinker with the internal workings of MyFaces which may/will
> cause us issues on an upgrade. I haven't tested it for thread-safety yet
> but everything I have seen with other frameworks leads me to believe all
> is well.
>
> Thanks,
> Stan
>
>
> Ernst Fastl wrote:
>> Hi,
>>
>> I can understand you don't like to write your own component for
>> soving this problem (although seeing the stuff you posted I guess
>> you are skilled enough for that).
>>
>> Anyway, have you tried the
>> existing solutions like PPRPanelGroup from the tomahawk sandbox
>> or Ajax4JSF?
>>
>> regards
>>
>> Ernst
>
Re: JSF and AJAX without custom components?
Posted by Stan Carney <st...@moohoffa.com>.
Thanks for your response Ernst!
Yeah, I have looked around at pretty much every JSF AJAX framework out
there and it isn't that I'm not impressed. There are definitely some
smart people working to create generic components to be consumed by the
masses. In our current position though I don't think these frameworks
make a lot of sense for us to use. We have an extremely strong UI
developer and we just want to be able to expose his talents, and in our
current circumstance having to use pre-built AJAX components or having
to create our own would severely hamper his abilities.
So anyway I have solved my problem via the following process. It allows
us to interact with JSF, i.e. forms, via AJAX without having to write
components. It has some significant short comings if it was going to be
used for general consumption by the JSF community (i.e. lacking
configuration, you can shoot your foot off easily, etc...) but works for
us. So keeping with good list etiquette I'm posting my solution below
for those, if any, that get a hit on my initial question.
I have created a PhaseListener that runs after the RESTORE_VIEW phase
and checks for the presence of a known parameter. Every parameter on
every request is checked which I'm not a fan of but from what I have
seen most other JSF/AJAX solutions do the same and it appears to run
super fast. If a 'known' parameter exists the PhaseListener instantiates
the class associated with the parameter for processing. In my case all
of these 'processor' classes implement a simple interface with one
method, process(), that takes a CaseInsensitiveMap as an argument. This
map contains the map returned value from the getParameterMap() method on
HttpServletRequest:
HttpServletRequest req = (HttpServletRequest)
event.getFacesContext().getExternalContext().getRequest();
CaseInsensitiveMap map = new CaseInsensitiveMap();
map.putAll(req.getParameterMap());
The process() method then does what it needs to do. Typically finding
components by their ids in the restored view, that are either known by
the class or sent as parameters, and updating their values accordingly.
Then the class composes an XML document that our client side JavaScript
(taconite and/or JQuery) understands and returns this XML string. The
PhaseListener then determines if the returned string contains a
javax.faces.ViewState placeholder we came up with and substitutes the
placeholder with the new ViewState value generated below. If there is no
placeholder, i.e. not interacting with a JSF form, we can omit the
updating of the ViewState value. In that case though we typically do
straight HTTP and bypass JSF completely.
try {
UIViewRoot viewRoot = context.getViewRoot();
StateManager stateMgr =
context.getApplication().getStateManager();
ComponentSupport.removeTransient(viewRoot);
SerializedView serializedView =
stateMgr.saveSerializedView(context);
Object[] savedState = new Object[3];
Object treeStruct = serializedView.getStructure();
if (treeStruct != null) {
if (treeStruct instanceof String) {
savedState[0] = treeStruct;
}
}
savedState[2] = viewRoot.getViewId();
String viewState = StateUtils.construct(savedState,
context.getExternalContext());
return viewState;
} catch (Exception e) {
throw new RuntimeException(e);
}
The PhaseListener writes out the string to the response stream and marks
the response as complete. The client JavaScript interprets the XML and
updates the DOM. The DOM should now match the DOM stored on the server.
It works well for us and results in the creation of only one class,
after the initial PhaseListener creation, per Ajaxable event. The above
code does tinker with the internal workings of MyFaces which may/will
cause us issues on an upgrade. I haven't tested it for thread-safety yet
but everything I have seen with other frameworks leads me to believe all
is well.
Thanks,
Stan
Ernst Fastl wrote:
> Hi,
>
> I can understand you don't like to write your own component for
> soving this problem (although seeing the stuff you posted I guess
> you are skilled enough for that).
>
> Anyway, have you tried the
> existing solutions like PPRPanelGroup from the tomahawk sandbox
> or Ajax4JSF?
>
> regards
>
> Ernst
Re: JSF and AJAX without custom components?
Posted by Ernst Fastl <er...@gmail.com>.
Hi,
I can understand you don't like to write your own component for
soving this problem (although seeing the stuff you posted I guess
you are skilled enough for that).
Anyway, have you tried the
existing solutions like PPRPanelGroup from the tomahawk sandbox
or Ajax4JSF?
regards
Ernst
On 5/26/07, Stan Carney <st...@moohoffa.com> wrote:
> Hello,
>
> I was wondering if anybody has had any success with JSF and AJAX outside
> of building custom components? We are fortunate to have a very talented
> UI developer with a strong knowledge of JQuery and Taconite and we would
> like to leverage his abilities as much as possible. We are using
> Facelets on top of MyFaces with JQuery and Taconite moderate success
> with the exception of forms due to JSF's state management facility.
>
> Based on all my reading of similar solutions I have come up with the
> following, not yet fully completed or working solution to the age old
> Country/Subdivision problem. i.e. when the user picks a country from a
> select box on a form the country subdivision select box (i.e. states,
> provinces, etc..) are retrieved via AJAX and inserted into the DOM.
>
> 1) Use JavaScript to find the value and submit the javax.faces.ViewState
> hidden form field along with the country code using a GET to the same
> URL as the viewId value in the embedded javax.faces.ViewState field.
> 2) Created a PhaseListener that runs after the RestoreView phase that
> detects the request is an Ajax call via configurable query string
> parameters.
> 3) PhaseListener finds the HtmlSelectOneMenu component for the country
> subdivision field by it's id, clears existing children and updates the
> list with the new subdivisions. See code below:
>
> FacesContext facesContext = FacesContext.getCurrentInstance();
> HtmlSelectOneMenu c = (HtmlSelectOneMenu)
> facesContext.getViewRoot().findComponent("form:country-subdivision");
>
> List children = c.getChildren();
> children.clear();
>
> children.addAll(selectBoxUtils.convertSelectItemToUISelectItem(subdivisions));
>
> 4) The new state is saved via the following code (based on similar
> examples and lots of debugging):
>
> SerializedView serializedview =
> facesContext.getApplication().getStateManager().saveSerializedView(facesContext);
>
> Object[] savedState = new Object[3];
> Object treeStruct = serializedview.getStructure();
> if (treeStruct != null) {
> if (treeStruct instanceof String) {
> savedState[0] = treeStruct;
> }
> }
>
> savedState[2] = facesContext.getViewRoot().getViewId();
> String viewState = StateUtils.construct(savedState,
> facesContext.getExternalContext());
>
> 5) The javax.faces.ViewState field (viewState from above code) is
> returned in an XML response and inserted into the DOM via taconite.
> 6) The PhaseListener then marks the response as complete.
>
> Unfortunately it isn't working 100% because I think I'm not updating the
> state properly somewhere. Either that or not returning the correct
> sequence number or not getting it into the StateManager correctly. But
> before I proceed any further I wanted to solicit advice from others that
> have done this before.
>
> Thoughts?
>
> Thanks,
> Stan
>
>