[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13769291#comment-13769291
]
Xavier Cho commented on MYFACES-3733:
-
Is it possible to nest dynamically created composite components? I tried to
nest them using a component binding, and while it renders correctly, action
events from the nested components are not processed when the view is refreshed
after facelets.REFRESH_PERIOD has been passed since the initial render.
The cause of the problem seems to be that at the time of dynamically creating
and nesting composite components, they are not yet 'populated' as it's done by
RefreshDynamicComponentListener, so the contents of the nested components are
ignored when StateManager.saveView() is called. It will prevent those
components from reconstructed when the view is rebuilt after the refresh.
Am I right in assuming that what I have described above is related to this
issue, and it's not been fixed yet? And if so, should I create a separate issue
report about it?
Thanks in advance!
> Implement vdl.createComponent(...)
> --
>
> Key: MYFACES-3733
> URL: https://issues.apache.org/jira/browse/MYFACES-3733
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>
> This is a difficult issue to do in JSF 2.2 . I have spent a long time to
> solve this one, and given the complexity involved and since there is no
> documentation anywhere about how this should work, I'll let the required
> explanation here.
> The idea is allow to include generated vdl fragments into pages
> programatically. This includes normal components, composite components or
> just fragments of markup. The method signature is this:
> public UIComponent createComponent(FacesContext context, String taglibURI,
> String tagName, Map attributes)
> Some valid examples of this are:
> // Normal component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/html";,
> "outputText", attributes);
> // Composite component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/composite/testComposite";,
> "dynComp_1", attributes);
> // Dynamic include
> Map attributes = new HashMap();
> attributes.put("src", "/addSimpleIncludeVDL_1_1.xhtml");
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/facelets";,
> "include", attributes);
> The javadoc does not suggest the dynamic include is valid, but I think users
> expect these kind of stuff work.
> Theoretically it sounds like something easy to do, but unfortunately it is
> not. The reasons why this is so are:
> - Facelets algorithm wraps html markup into UILeaf instances, which is a
> special "transient" component. UILeaf instances are never saved or restored
> from the component tree, but in some points of the algorithm (restore view
> and before render response when vdl.buildView() is called) the component tree
> is updated, adding or removing UILeaf instances.
> - Facelets has an algorithm that require id generation to be stable,
> otherwise a duplicate id exception may arise. A lot of effort has been done
> to organize this part, and the current solution works very well. But in this
> case, we need to generate unique ids that can be refreshed somehow.
> - Facelets algorithm has an special logic to deal with dynamic sections like
> the ones generated by c:if or
> ui:include src="#{...}" . Add facelets sections programatically could make
> this algorithm fail, removing sections that should be.
> - Facelets PSS algorithm needs to be taken into account too. The listener
> that is used to register programmatic changes on the tree in
> DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
> identify which component belongs to the component tree and which one was
> added by outside. Add facelets sections programatically could make this
> algorithm fail, because it could assume some sections of the tree does not
> need to be saved fully, even if that's not true.
> The issue in the spec is this:
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
> At start the idea was to export FaceletFactory directly, but I told to the EG
> that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
> This previous message is useful too:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
> After thinking and trying different strategies to overcome this issue, I
> finally found the following solution:
> - Use the compiler for generate a custom Facelet "inline" or "on the fly". It
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13774454#comment-13774454
]
Xavier Cho commented on MYFACES-3733:
-
@[~lu4242], I tried to change ordering of components to make a child added
before the parent as suggested, though the problem seems to persist.
I'd very much like to contribute a test case, though I had to abandon the
current approach of dynamically creating composite components altogether as I'm
already far behind the schedule.
I'm sorry I couldn't submit any concrete example which reproduces the problem.
And thanks for the help!
> Implement vdl.createComponent(...)
> --
>
> Key: MYFACES-3733
> URL: https://issues.apache.org/jira/browse/MYFACES-3733
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>
> This is a difficult issue to do in JSF 2.2 . I have spent a long time to
> solve this one, and given the complexity involved and since there is no
> documentation anywhere about how this should work, I'll let the required
> explanation here.
> The idea is allow to include generated vdl fragments into pages
> programatically. This includes normal components, composite components or
> just fragments of markup. The method signature is this:
> public UIComponent createComponent(FacesContext context, String taglibURI,
> String tagName, Map attributes)
> Some valid examples of this are:
> // Normal component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/html";,
> "outputText", attributes);
> // Composite component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/composite/testComposite";,
> "dynComp_1", attributes);
> // Dynamic include
> Map attributes = new HashMap();
> attributes.put("src", "/addSimpleIncludeVDL_1_1.xhtml");
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/facelets";,
> "include", attributes);
> The javadoc does not suggest the dynamic include is valid, but I think users
> expect these kind of stuff work.
> Theoretically it sounds like something easy to do, but unfortunately it is
> not. The reasons why this is so are:
> - Facelets algorithm wraps html markup into UILeaf instances, which is a
> special "transient" component. UILeaf instances are never saved or restored
> from the component tree, but in some points of the algorithm (restore view
> and before render response when vdl.buildView() is called) the component tree
> is updated, adding or removing UILeaf instances.
> - Facelets has an algorithm that require id generation to be stable,
> otherwise a duplicate id exception may arise. A lot of effort has been done
> to organize this part, and the current solution works very well. But in this
> case, we need to generate unique ids that can be refreshed somehow.
> - Facelets algorithm has an special logic to deal with dynamic sections like
> the ones generated by c:if or
> ui:include src="#{...}" . Add facelets sections programatically could make
> this algorithm fail, removing sections that should be.
> - Facelets PSS algorithm needs to be taken into account too. The listener
> that is used to register programmatic changes on the tree in
> DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
> identify which component belongs to the component tree and which one was
> added by outside. Add facelets sections programatically could make this
> algorithm fail, because it could assume some sections of the tree does not
> need to be saved fully, even if that's not true.
> The issue in the spec is this:
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
> At start the idea was to export FaceletFactory directly, but I told to the EG
> that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
> This previous message is useful too:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
> After thinking and trying different strategies to overcome this issue, I
> finally found the following solution:
> - Use the compiler for generate a custom Facelet "inline" or "on the fly". It
> is not necessary to create an
> xml document and then parse it, just generate the Tag class and pass it to
> the compiler to generate an
> Abstract Syntax Tree (AST), with the hierarchy of facelet TagHandler
> instances.
> - To solve the issue with UILeaf instances, the best is create a stateful
> ComponentSystemEventListener that on restore view phase it compiles the
> custom Facelet and apply it over the fragment. The ideal and on
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776332#comment-13776332
]
Xavier Cho commented on MYFACES-3733:
-
Unfortunately, setting the REFRESH_PERIOD to -1 is not an option for me because
the project I'm working on is in active development, and I want restart the
server or logoff everytime I make changes to a .xhtml file.
Again, I cannot it to some short period (like 3 seconds) either, as it means I
have to test everything in that time span or it will cease to function so I
have to refresh the page and start it over.
Due to my project's deadline, I can't wait till it's get fixed so I need to
change my approach for now. But I'll keep watching this issue so I can later
refactor it when it'll be fixed.
> Implement vdl.createComponent(...)
> --
>
> Key: MYFACES-3733
> URL: https://issues.apache.org/jira/browse/MYFACES-3733
> Project: MyFaces Core
> Issue Type: Task
> Components: JSR-344
>Reporter: Leonardo Uribe
>
> This is a difficult issue to do in JSF 2.2 . I have spent a long time to
> solve this one, and given the complexity involved and since there is no
> documentation anywhere about how this should work, I'll let the required
> explanation here.
> The idea is allow to include generated vdl fragments into pages
> programatically. This includes normal components, composite components or
> just fragments of markup. The method signature is this:
> public UIComponent createComponent(FacesContext context, String taglibURI,
> String tagName, Map attributes)
> Some valid examples of this are:
> // Normal component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/html";,
> "outputText", attributes);
> // Composite component
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/composite/testComposite";,
> "dynComp_1", attributes);
> // Dynamic include
> Map attributes = new HashMap();
> attributes.put("src", "/addSimpleIncludeVDL_1_1.xhtml");
> UIComponent component = vdl.createComponent(facesContext,
> "http://java.sun.com/jsf/facelets";,
> "include", attributes);
> The javadoc does not suggest the dynamic include is valid, but I think users
> expect these kind of stuff work.
> Theoretically it sounds like something easy to do, but unfortunately it is
> not. The reasons why this is so are:
> - Facelets algorithm wraps html markup into UILeaf instances, which is a
> special "transient" component. UILeaf instances are never saved or restored
> from the component tree, but in some points of the algorithm (restore view
> and before render response when vdl.buildView() is called) the component tree
> is updated, adding or removing UILeaf instances.
> - Facelets has an algorithm that require id generation to be stable,
> otherwise a duplicate id exception may arise. A lot of effort has been done
> to organize this part, and the current solution works very well. But in this
> case, we need to generate unique ids that can be refreshed somehow.
> - Facelets algorithm has an special logic to deal with dynamic sections like
> the ones generated by c:if or
> ui:include src="#{...}" . Add facelets sections programatically could make
> this algorithm fail, removing sections that should be.
> - Facelets PSS algorithm needs to be taken into account too. The listener
> that is used to register programmatic changes on the tree in
> DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
> identify which component belongs to the component tree and which one was
> added by outside. Add facelets sections programatically could make this
> algorithm fail, because it could assume some sections of the tree does not
> need to be saved fully, even if that's not true.
> The issue in the spec is this:
> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
> At start the idea was to export FaceletFactory directly, but I told to the EG
> that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
> This previous message is useful too:
> https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
> After thinking and trying different strategies to overcome this issue, I
> finally found the following solution:
> - Use the compiler for generate a custom Facelet "inline" or "on the fly". It
> is not necessary to create an
> xml document and then parse it, just generate the Tag class and pass it to
> the compiler to generate an
> Abstract Syntax Tree (AST), with the hierarchy of facelet TagHandler
> instances.
> - To solve the issue with UILeaf instances, the
[jira] [Created] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.
Xavier Cho created MYFACES-3840: --- Summary: UIViewRoot uses different id while saving and restoring states. Key: MYFACES-3840 URL: https://issues.apache.org/jira/browse/MYFACES-3840 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.2.0-beta Reporter: Xavier Cho After I upgraded to 2.2.0-beta, every postback requests which requires @ViewScoped managed beans fails as they lose states after the initial request. I couldn't spend sufficient time to investigate so not perfectly sure if it's not caused by some misconfiguration on my end. Though, after a quick debugging, I found that in the DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to restore it using its view ID in restoreView:301, thus failing to restore the state. Is this behavior normal? If so, what possible configuration could cause it to use different IDs between saving and restoring state? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.
[ https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858529#comment-13858529 ] Xavier Cho commented on MYFACES-3840: - It happened during upgrading my project from MyFaces 2.1.12 + PrimeFaces 3.5 to MyFaces 2.2.0-beta + PrimeFaces 4.0. It seems that switching between partial or full state saving does not affect the issue. I found that it can be reproducible even after I downgraded MyFaces, so it could be caused by certain incompatibility of PrimeFaces 4.0 with MyFaces. It seems there are lot of such problems with the combination, compared to PrimeFaces 4.0 + Mojarra 2.2.4. I don't think I had ever explicitly called getClientId() or createUniqueId() methods on UIViewRoot myself, by the way. Is there any hint how I could debug this problem? Thanks! > UIViewRoot uses different id while saving and restoring states. > --- > > Key: MYFACES-3840 > URL: https://issues.apache.org/jira/browse/MYFACES-3840 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.0-beta >Reporter: Xavier Cho > > After I upgraded to 2.2.0-beta, every postback requests which requires > @ViewScoped managed beans fails as they lose states after the initial request. > I couldn't spend sufficient time to investigate so not perfectly sure if it's > not caused by some misconfiguration on my end. > Though, after a quick debugging, I found that in the > DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance > is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to > restore it using its view ID in restoreView:301, thus failing to restore the > state. > Is this behavior normal? If so, what possible configuration could cause it to > use different IDs between saving and restoring state? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.
[ https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901401#comment-13901401 ] Xavier Cho commented on MYFACES-3840: - Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue : - https://java.net/jira/browse/JAVASERVERFACES-1492 When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, as the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (2.2.0). > UIViewRoot uses different id while saving and restoring states. > --- > > Key: MYFACES-3840 > URL: https://issues.apache.org/jira/browse/MYFACES-3840 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.0-beta >Reporter: Xavier Cho >Assignee: Leonardo Uribe > > After I upgraded to 2.2.0-beta, every postback requests which requires > @ViewScoped managed beans fails as they lose states after the initial request. > I couldn't spend sufficient time to investigate so not perfectly sure if it's > not caused by some misconfiguration on my end. > Though, after a quick debugging, I found that in the > DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance > is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to > restore it using its view ID in restoreView:301, thus failing to restore the > state. > Is this behavior normal? If so, what possible configuration could cause it to > use different IDs between saving and restoring state? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.
[ https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901401#comment-13901401 ] Xavier Cho edited comment on MYFACES-3840 at 2/14/14 1:07 PM: -- Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue : - https://java.net/jira/browse/JAVASERVERFACES-1492 When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, because the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (line numbers are from 2.2.0). However, I wonder exactly when _view.restoreViewScopeState(context, viewRootState);_ (325 line) is triggered, as if this line is executed, the above problem can be solved as well. I verified this behavior, by temporarily override UIViewRoot, so that it's clientId to be the same with its view ID, which would make the said line to be executed. I'm wondering if it could really be the solution to the problem, or for now, it's just impossible to use component binding with PSS enabled for MyFaces. was (Author: mysticfall): Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue : - https://java.net/jira/browse/JAVASERVERFACES-1492 When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, as the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (line numbers are from 2.2.0). However, I wonder exactly when _view.restoreViewScopeState(context, viewRootState);_ (325 line) is triggered, as if this line is executed, the above problem can be solved as well. I verified this behavior, by temporarily override UIViewRoot, so that it's clientId to be the same with its view ID, which would make the said line to be executed. I'm wondering if it could really be the solution to the problem, or for now, it's just impossible to use component binding with PSS enabled for MyFaces. > UIViewRoot uses different id while saving and restoring states. > --- > > Key: MYFACES-3840 > URL: https://issues.apache.org/jira/browse/MYFACES-3840 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.0-beta >Reporter: Xavier Cho >Assignee: Leonardo Uribe > > After I upgraded to 2.2.0-beta, every postback requests which requires > @ViewScoped managed beans fails as they lose states after the initial request. > I couldn't spend sufficient time to investigate so not perfectly sure if it's > not caused by some misconfiguration on my end. > Though, after a quick debugging, I found that in the > DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance > is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to > restore it using its view ID in restoreView:301, thus failing to restore the > state. > Is this behavior normal? If so, what possible configuration could cause it to > use different IDs between saving and restoring state? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.
[ https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901401#comment-13901401 ] Xavier Cho edited comment on MYFACES-3840 at 2/14/14 1:06 PM: -- Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue : - https://java.net/jira/browse/JAVASERVERFACES-1492 When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, as the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (line numbers are from 2.2.0). However, I wonder exactly when _view.restoreViewScopeState(context, viewRootState);_ (325 line) is triggered, as if this line is executed, the above problem can be solved as well. I verified this behavior, by temporarily override UIViewRoot, so that it's clientId to be the same with its view ID, which would make the said line to be executed. I'm wondering if it could really be the solution to the problem, or for now, it's just impossible to use component binding with PSS enabled for MyFaces. was (Author: mysticfall): Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue : - https://java.net/jira/browse/JAVASERVERFACES-1492 When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, as the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (2.2.0). > UIViewRoot uses different id while saving and restoring states. > --- > > Key: MYFACES-3840 > URL: https://issues.apache.org/jira/browse/MYFACES-3840 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 2.2.0-beta >Reporter: Xavier Cho >Assignee: Leonardo Uribe > > After I upgraded to 2.2.0-beta, every postback requests which requires > @ViewScoped managed beans fails as they lose states after the initial request. > I couldn't spend sufficient time to investigate so not perfectly sure if it's > not caused by some misconfiguration on my end. > Though, after a quick debugging, I found that in the > DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance > is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to > restore it using its view ID in restoreView:301, thus failing to restore the > state. > Is this behavior normal? If so, what possible configuration could cause it to > use different IDs between saving and restoring state? -- This message was sent by Atlassian JIRA (v6.1.5#6160)
