Re: Problems with partial page rendering
In JSF1.2, the tree is built before the rendering happens - so everything that is plain HTML is converted into a part of the component tree anyways. Maybe we should just wait for this to happen ;) ? Facelets is another question. No clue. regards, Martin On 9/22/06, Gerald Müllan [EMAIL PROTECTED] wrote: Hi, just played around a little bit with our new approach from ernst and got aware of some problems which might not be that easy to solve. The main issue is that actually a part of the component tree is rendered out which is embedded inside the ppr tag. If there is any view related stuff apart from components - e.g. in jsp verbatim tag (i know this is ugly, but the issue should be the same in facelets) - it is not rendered out. Ok, we could handle this with simple outputText in some cases, but that should not be the end of the story. Just discussed with thomas about it, and actually we don`t really get a good idea out, how to solve it. So, any ideas regarding it are warm welcome :) regards, Gerald -- 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
Re: Problems with partial page rendering
I think there may be a LiteralText or LiteralTextBlock element in facelets. Whether it's internal only or available as a public component, I don't know. On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote: Is there a new component in JSF 1.2 to store HTML output? On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote: Like JSP 1.2, Facelets builds the tree before rendering. Facelets might even have originated the idea :-) On 9/22/06, Martin Marinschek [EMAIL PROTECTED] wrote: In JSF1.2, the tree is built before the rendering happens - so everything that is plain HTML is converted into a part of the component tree anyways. Maybe we should just wait for this to happen ;) ? Facelets is another question. No clue. regards, Martin On 9/22/06, Gerald Müllan [EMAIL PROTECTED] wrote: Hi, just played around a little bit with our new approach from ernst and got aware of some problems which might not be that easy to solve. The main issue is that actually a part of the component tree is rendered out which is embedded inside the ppr tag. If there is any view related stuff apart from components - e.g. in jsp verbatim tag (i know this is ugly, but the issue should be the same in facelets) - it is not rendered out. Ok, we could handle this with simple outputText in some cases, but that should not be the end of the story. Just discussed with thomas about it, and actually we don`t really get a good idea out, how to solve it. So, any ideas regarding it are warm welcome :) regards, Gerald -- 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 -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problems with partial page rendering
The goal with JSF 1.2's rendering is that the ViewHandler, while it
builds the view, shouldn't render anything at all. So using JSP as your
view or Facelets as your view, the act of evaluating those artifacts
shouldn't push anything to the response.
Once you have the full component tree from a JSP or Facelet, you can
commit to rendering the whole thing:
uiViewRoot.renderAll(facesContext);
Or, only some of it with (specifically a known clientId):
uiViewRoot.invokeOnComponent(faces, clientId, new ContextCallback() {
public void invokeContextCallback(FacesContext ctx, UIComponent c) {
c.renderAll(ctx);
}
});
Mike Kienenberger wrote:
I think there may be a LiteralText or LiteralTextBlock element in
facelets. Whether it's internal only or available as a public
component, I don't know.
On 9/22/06, Thomas Spiegl [EMAIL PROTECTED] wrote:
Is there a new component in JSF 1.2 to store HTML output?
On 9/22/06, Mike Kienenberger [EMAIL PROTECTED] wrote:
Like JSP 1.2, Facelets builds the tree before rendering. Facelets
might even have originated the idea :-)
On 9/22/06, Martin Marinschek [EMAIL PROTECTED] wrote:
In JSF1.2, the tree is built before the rendering happens - so
everything that is plain HTML is converted into a part of the
component tree anyways. Maybe we should just wait for this to happen
;) ?
Facelets is another question. No clue.
regards,
Martin
On 9/22/06, Gerald Müllan [EMAIL PROTECTED] wrote:
Hi,
just played around a little bit with our new approach from
ernst and
got aware of some problems which might not be that easy to solve.
The main issue is that actually a part of the component tree is
rendered out which is embedded inside the ppr tag. If there is any
view related stuff apart from components - e.g. in jsp verbatim
tag (i
know this is ugly, but the issue should be the same in
facelets) - it
is not rendered out.
Ok, we could handle this with simple outputText in some cases, but
that should not be the end of the story.
Just discussed with thomas about it, and actually we don`t
really get
a good idea out, how to solve it. So, any ideas regarding it
are warm
welcome :)
regards,
Gerald
--
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
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: Problems with partial page rendering
From: "Mike Kienenberger" [EMAIL PROTECTED] Like JSP 1.2, Facelets builds the tree before rendering. Facelets might even have originated the idea :-) Actually, Clay was sitting in a bugzilla ticket as a proposed enhancement to the shale subview component before Jacob started facelets (http://weblogs.java.net/blog/edburns/archive/2005/04/javaserver_face_1.html). Clay also builds the tree before rendering (http://shale.apache.org/features-reusable-views.html). Gary On 9/22/06, Martin Marinschek <[EMAIL PROTECTED]>wrote: In JSF1.2, the tree is built before the rendering happens - so everything that is plain HTML is converted into a part of the component tree anyways. Maybe we should just wait for this to happen ;) ? Facelets is another question. No clue. regards, Martin On 9/22/06, Gerald Müllan <[EMAIL PROTECTED]>wrote:Hi, just played around a little bit with our new approach from ernst andgot aware of some problems which might not be that easy to solve. The main issue is that actually a part of the component tree isrendered out which is embedded inside the ppr tag. If there is anyview related stuf f apart from components - e.g. in jsp verbatim tag (iknow this is ugly, but the issue should be the same in facelets) - itis not rendered out. Ok, we could handle this with simple outputText in some cases, butthat should not be the end of the story. Just discussed with thomas about it, and actually we don`t really geta good idea out, how to solve it. So, any ideas regarding it are warmwelcome :) regards, Gerald --http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and German Professional Support for Apache MyFaces t;-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problems with partial page rendering
On 9/22/06, Gary VanMatre [EMAIL PROTECTED] wrote: Actually, Clay was sitting in a bugzilla ticket as a proposed enhancement to the shale subview component before Jacob started facelets (http://weblogs.java.net/blog/edburns/archive/2005/04/javaserver_face_1.html). Clay also builds the tree before rendering (http://shale.apache.org/features-reusable-views.html). There you go. So the only broken implementation is JSF 1.1.
Re: Problems with partial page rendering
Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. From: "Mike Kienenberger" [EMAIL PROTECTED] Like JSP 1.2, Facelets builds the tree before rendering. Facelets might even have originated the idea :-) Actually, Clay was sitting in a bugzilla ticket as a proposed enhancement to the shale subview component before Jacob started facelets (http://weblogs.java.net/blog/edburns/archive/2005/04/javaserver_face_1.html). Clay also builds the tree before rendering (http://shale.apache.org/features-reusable-views.html). Gary On 9/22/06, Martin Marinschek wrote: In JSF1.2, the tree is built before the rendering happens - so everything that is plain HTML is converted into a part of the component tree anyways. Maybe we should just wait for this to happen ;) ? Facelets is another question. No clue. regards, Martin On 9/22/06, Gerald Müllan wrote:Hi, just played around a little bit with our new approach from ernst andgot aware of some problems which might not be that easy to solve. The main issue is that actually a part of the component tree isrendered out which is embedded inside the ppr tag. If there is anyview related stuf f apart from components - e.g. in jsp verbatim tag (iknow this is ugly, but the issue should be the same in facelets) - itis not rendered out. Ok, we could handle this with simple outputText in some cases, butthat should not be the end of the story. Just discussed with thomas about it, and actually we don`t really geta good idea out, how to solve it. So, any ideas regarding it are warmwelcome :) regards, Gerald --http://www.irian.at Your JSF powerhouse -JSF Consulting, Development andCourses in English and German Professional Support for Apache MyFaces g t;-- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problems with partial page rendering
From: [EMAIL PROTECTED] Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. I have a related question that I'm sure you guys can help me understand. It has more to do with restoring the view and then recreating the components that are marked as transient. I think you would have similar issues with partial page rendering. There was a recent change in the myfaces UIViewRoot. The change was related to the createUniqueId method. This component now persists the last generated id. From what I understand, JSF RI 1.2 behaves the same. What I'm unsure about is how to insert a new component (verbatim) into a restored tree. What is the best way to calculate an id that won't collide. It also requires a different method of inspecting the restored tree to see if a component needs to be recreated using the findComponent method. For a temporary solution with Clay, I create my own sequence that is reset each time the view is rendered and passed around in request scope. This new sequence doesn't use the UIViewRoot's method of generating a sequence but it seems to work. It appears that the myfaces JSP tags are doing a similar thing. The generated component id's don't appear to be generated using the UIViewRoot. Any insight would be appreciated. Gary
Re: Problems with partial page rendering
The UIViewRoot unique id must be persisted to guarantee that no matter the state saving lifecycle of the component tree, that the UIViewRoot can always produce a unique ID, despite changes to the structure of the view at 'build time'. I understand what you are going for with Verbatims and unique ids-- but it requires repeatable order of evaluation. One or two if-statements could throw the whole order of comparison off. This is a major problem with sequence comparisons and accomodating document change. With JSP 2.1, we have JspIdConsumers which, by contract, assert that each JspTag will be assigned a unique id. This can be used instead in comparison since it's not order of evaluation dependent. With Facelets, we don't bother asserting uniqueness by Id for cleanup/transients and instead implement our own JspIdConsumer with an assignment to the AttributeMap. That value is instead used to determine duplication/cleanup, indifferent of the id assignments that the user or JSF impl provides. So instead of using the API's findComponent, we use a findComponent by Facelet Token ID. From: [EMAIL PROTECTED] Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. I have a related question that I'm sure you guys can help me understand. It has more to do with restoring the view and then recreating the components that are marked as transient. I think you would have similar issues with partial page rendering. There was a recent change in the myfaces UIViewRoot. The change was related to the createUniqueId method. This component now persists the last generated id. From what I understand, JSF RI 1.2 behaves the same. What I'm unsure about is how to insert a new component (verbatim) into a restored tree. What is the best way to calculate an id that won't collide. It also requires a different method of inspecting the restored tree to see if a component needs to be recreated using the findComponent method. For a temporary solution with Clay, I create my own sequence that is reset each time the view is rendered and passed around in request scope. This new sequence doesn't use the UIViewRoot's method of generating a sequence but it seems to work. It appears that the myfaces JSP tags are doing a similar thing. The generated component id's don't appear to be generated using the UIViewRoot. Any insight would be appreciated. Gary
Re: Problems with partial page rendering
Hi Gary, yes, this is what we are doing, exactly. And for the same reasons. I haven't found a better way - without JspIdConsumers around ;). regards, Martin On 9/22/06, Gary VanMatre [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. I have a related question that I'm sure you guys can help me understand. It has more to do with restoring the view and then recreating the components that are marked as transient. I think you would have similar issues with partial page rendering. There was a recent change in the myfaces UIViewRoot. The change was related to the createUniqueId method. This component now persists the last generated id. From what I understand, JSF RI 1.2 behaves the same. What I'm unsure about is how to insert a new component (verbatim) into a restored tree. What is the best way to calculate an id that won't collide. It also requires a different method of inspecting the restored tree to see if a component needs to be recreated using the findComponent method. For a temporary solution with Clay, I create my own sequence that is reset each time the view is rendered and passed around in request scope. This new sequence doesn't use the UIViewRoot's method of generating a sequence but it seems to work. It appears that the myfaces JSP tags are doing a similar thing. The generated component id's don't appear to be generated using the UIViewRoot. Any insight would be appreciated. Gary -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Problems with partial page rendering
From: [EMAIL PROTECTED] The UIViewRoot unique id must be persisted to guarantee that no matter the state saving lifecycle of the component tree, that the UIViewRoot can always produce a unique ID, despite changes to the structure of the view at 'build time'. I understand what you are going for with Verbatims and unique ids-- but it requires repeatable order of evaluation. One or two if-statements could throw the whole order of comparison off. This is a major problem with sequence comparisons and accomodating document change. I see what you mean. If the structure of the tree can be dynamically changed, thenthe simple sequence won't work. With JSP 2.1, we have JspIdConsumers which, by contract, assert that each JspTag will be assigned a unique id. This can be used instead in comparison since it's not order of evaluation dependent. Oh, that's interesting. The "jsp:id" is used for componentsthat don't have component id's. With Facelets, we don't bother asserting uniqueness by Id for cleanup/transients and instead implement our own JspIdConsumer with an assignment to the AttributeMap. That value is instead used to determine duplication/cleanup, indifferent of the id assignments that the user or JSF impl provides. So instead of using the API's findComponent, we use a findComponent by Facelet Token ID. I see buthow do you handle caching of page fragments? Thinkingof how Clay caches. It loads a digested HTML or XML fragment into a graph of objects. These fragments can be pulled into various page compositions. How do generate your Token ID and keep them from colliding as page fragments are reused? Gary From: [EMAIL PROTECTED]Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax components and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. I have a related question that I'm sure you guys can help me understand. It has more to do with restoring the view and then recreating the components that are marked as transient. I think you would have similar issues with partial page rendering. There was a recent change in the myfaces UIViewRoot. The change was related to the createUniqueId method. This component now persists the last generated id. From what I understand, JSF RI 1.2 behaves the same. What I'm unsure about is how to insert a new component (verbatim) into a restored tree. What is the best way to calculate an id that won't collide. It also requires a different method of inspecting the restored tree to see if a component needs to be recreated using the findComponent method. For a temporary solution with Clay, I create my own sequence that is reset each time the view is rendered and passed around in request scope. This new sequence doesn't use the UIViewRoot's method of generating a sequence but it seems to work. It appears that the myfaces JSP tags are doing a similar thing. The generated component id's don't appear to be generated using the UIViewRoot. Any insight would be appreciated. Gary
Re: Problems with partial page rendering
Martin and Jacob, Thanks for the info. I'll take a better look at the new JspIdConsumer. Gary -- Original message -- From: "Martin Marinschek" [EMAIL PROTECTED] Hi Gary, yes, this is what we are doing, exactly. And for the same reasons. I haven't found a better way - without JspIdConsumers around ;). regards, Martin On 9/22/06, Gary VanMatre <[EMAIL PROTECTED]>wrote: From: [EMAIL PROTECTED] Declaring subviews and ajax regions is only a partial solution-- when JSF in fact should be able to re-render any component without being explicitly declared as a refreshable region (that's what we were pushing out of Facelets and JSF 1.2). Ajax4Jsf does this by decoration of existing, non-ajax comp onents and the JSF 1.2 invokeOnComponent (Martin, et. al) can do it for any component without decoration in a very, very efficient manner. I have a related question that I'm sure you guys can help me understand. It has more to do with restoring the view and then recreating the components that are marked as transient. I think you would have similar issues with partial page rendering. There was a recent change in the myfaces UIViewRoot. The change was related to the createUniqueId method. This component now persists the last generated id. From what I understand, JSF RI 1.2 behaves the same. What I'm unsure about is how to insert a new component (verbatim) into a restored tree. What is the best way to calculate an i d that won't collide. It also requires a different method of inspecting the restored tree to see if a component needs to be recreated using the findComponent method. For a temporary solution with Clay, I create my own sequence that is reset each time the view is rendered and passed around in request scope. This new sequence doesn't use the UIViewRoot's method of generating a sequence but it seems to work. It appears that the myfaces JSP tags are doing a similar thing. The generated component id's don't appear to be generated using the UIViewRoot. Any insight would be appreciated. Gary -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Devel opment and Courses in English and German Professional Support for Apache MyFaces
