Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Trivial Trivial
    • Resolution: Won't Fix
    • Affects Version/s: 1.1
    • Fix Version/s: None
    • Component/s: Lifecycle
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Sun

    • Issuezilla Id:
      876
    • Status Whiteboard:
      Hide

      size_small importance_small

      Show
      size_small importance_small

      Description

      >>>>> On Fri, 30 Jul 2010 10:11:33 +0200, Dünnenberger Hanspeter said:

      HD> as an outcome of this discussion, would you welcome a new
      HD> SystemEvent (e.g. named ViewRootChangeEvent) to be fired whenever
      HD> the current ViewRoot instance changes?

        Activity

        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Hanspeter Duennenberger added a comment -

        Actually, it would be nice if the event object would provide references to the old and new ViewRoot - that would allow for some usage to copy viewScope entries from one ViewRoot to the next if a user wants to, e.g. in case both view's have the same viewId.

        Show
        Hanspeter Duennenberger added a comment - Actually, it would be nice if the event object would provide references to the old and new ViewRoot - that would allow for some usage to copy viewScope entries from one ViewRoot to the next if a user wants to, e.g. in case both view's have the same viewId.
        Hide
        Ed Burns added a comment -

        ##jsf freenode IRC discussion

        <hpdueni> Hi all. I discovered a problem using component binding and teh detection of annotated ResourceDependencies e.g. in renderers
        <hpdueni> when navigating to the same page, I end up with a new ViewRoot instance but I don't get the resource dependencies from annotations.
        <hpdueni> that is because the component binding prevents the tag handlers from beeing invoked in the render phase after the viewRoot was exchanged.
        <edburns> hpdueni: Wow, that's subtle.
        <edburns> hpdueni: I think it's really because Application.createComponent() is not being called based on the scope of the binding.
        <hpdueni> Now I suspect if we need a binding-scope or if we should just rely on the ViewRootChangeEvent (which i requested in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876) to reset all component bindings

        • rogerk1 (~Adium@pool-96-237-170-36.bstnma.fios.verizon.net) has joined ##jsf
          <edburns> hpdueni: When you say "reset all component bindings" do you mean that funny little traversal we do of the tree before really getting started with the lifecycle?
          <hpdueni> or what we already have in CS JSF is a Bindings bean that should be used for all component bindings - and that one is cleared whenever ViewRoot changes
          <ioss> hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right?
          <hpdueni> with reset component binding when viewroot changes I mean, the backing bean which holds the bound component must release that component which is from the previous view
          <ioss> or why would you want to hold the component for longer then a request?
          <hpdueni> for simplicity we used e.g. h:panelGroup bindgin="# {facesContext.attributes['someid']}

          " and then ass that el into another CC to pass on teh dynamic clientId
          <hpdueni> ioss: that problem already happens within one request - as required, we never hold bindings longer than a request.
          <hpdueni> ioss: but as it tunred out, request scope is already too long in case when viewroot changes -
          <edburns> hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry.
          <hpdueni> edburns: exactly, since the component that was created in restore phase is bound to something in request scope, the component is still there after viewRoot changed and therfore Application.createComponent() will not be invoked and none of teh resource dependencies are detected
          <ioss> Hanspeter: how about always returning null?
          <ioss> then your component binding should get reset on the render-phase
          <ioss> you should possibly get a call on restore-view and another one after the view changes
          <edburns> ak: I see. Actually, there were no changes in the XSD for facelet taglibs in 2.1, so you can just use the 2.0 one.
          <hpdueni> ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ...
          <ioss> hpdueni: sure, name the binding in another way
          <ioss>
          <edburns> In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago.
          <ioss> getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent
          <hpdueni> ioss: would mean to have one attribute name with only a set method to pass teh component and another read-only name to retrieve it ...
          <ioss> right
          <hpdueni> ioss: that could work, would that be your general recommendation for component binding ?
          <ioss> hpdueni: not the nicest approach I agree, but still not horrible I would say
          <ioss> hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach
          <ioss> hpdueni: I nearly never use componentbinding
          <ioss> hpdueni: I am more a "lookup"-guy
          <hpdueni> ioss: yea, it has its pitfalls

        • mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf
          <ioss> also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development)
          <edburns> ak: Can you please file an issue in the docmentation sub-component on this JIRA: http://java.net/jira/browse/JAVASERVERFACES
          <hpdueni> ioss: now we are close to what we do - we actually need to pass the id of one component to some CC - but as the component's clientId is unknown at development time we pass the component using this binding .
          <ioss> hpdueni: so the template author does not know the id?
          <hpdueni> ioss: not the full clientId - that may change depending on if you are running as a web app or as a Portlet - both is possible from the same web app instance
          <ioss> hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question
          <ioss> ok
          <ioss> so this is really some sort of fire-and-(partially)-forget
          <ioss> i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly
          <ioss> directly=by java code
          <ioss> by java code=non jsf implementation java code
          <hpdueni> ioss: kind of, but still I need a writable property to get hold on the component which I want to read-only from somewhere else
          <hpdueni> I just think some of the new features interfere with component binding and we need a general approach for that
          <ioss> hpdueni: if you like to go creazy you could add an ELResolver, that will set even a private property
          <ioss> or one that will return null always when el is used
          <ioss> that's actually not to bad
          <ioss> if you can come up with a naming convention, or annotations
          <ioss> or a "fake" scope
          <ioss> # {componentwriteonlybinding.mybean.property}

          <ioss> so setter and getter would work normally, but el will always return null
          <ioss> hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too
          <hpdueni> ioss: sounds somehow weird - actually, thinking on that kind of use my binding should work as readonly only while component tree is built - (buildView) - to prevent passing the component to the new view and allow Application.createComponent() doing it's work
          <hpdueni> ioss: I wouldn't like another ELResolver for that as there are already so many ELResolvers involved - and writing to private method would involve reflection and is somehow dirty
          <hpdueni> ioss: talking about face scope - a custom scope could hanlde that
          <ioss> hpdueni: right
          <hpdueni> ioss: on the other hand, I'd like a solution for all JSF users, not only the ones that are aware of that potential problem
          <ioss> hpdueni: couldn't you use a prerender event?
          <ioss> hpdueni: it guess it does not matter for you, if the view changed or not, you just have to get rid of that component before rendering
          <hpdueni> ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase
          <ioss> hpdueni: I think a scope is the easiest way to cope with that for now. either clean the scope, or let the scope have a "special" getter, while the normal getter will return null always
          <hpdueni> ioss: but now, where does that lead us - would that mean standard bindings usage should behave always like this? Then we could really use a BindingsScope to support that
          <ioss> hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime
          <hpdueni> ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase
          <ioss> right
          <hpdueni> ioss: whatever it's called - it would have separate lifetime for execute phases and render phase
          <hpdueni> ioss: that is pretty close to the two Portlet phases
          <ioss> you could probably even use it for some fancy persistence stuff, like make the "execute" phase transactional and write enabled, while the request-phase would have an long-running em to cope with lazy-load, but also would not allow to persist anything
          <ioss> Reminds me, that I have to read about portlets!
          <hpdueni> ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that?
          <edburns> hpdueni: Ok, so ioss proposed a workaround involving an extra javabeans property, and then the discussion went to having a scope for this use-case.
          <hpdueni> edburns: yes, some special ELResolver was also in discussion
          <edburns> hpdueni: But really, this is closelely related to <http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876>.
          <edburns> Let me capture this discussion to the comment thread on the issue.
          <hpdueni> edburns: what would be a solution for everybody - or should binding be considered as advanced usage where one has to know the bindings might need to be cleared in certain cases even in the middle of the request?

        Show
        Ed Burns added a comment - ##jsf freenode IRC discussion <hpdueni> Hi all. I discovered a problem using component binding and teh detection of annotated ResourceDependencies e.g. in renderers <hpdueni> when navigating to the same page, I end up with a new ViewRoot instance but I don't get the resource dependencies from annotations. <hpdueni> that is because the component binding prevents the tag handlers from beeing invoked in the render phase after the viewRoot was exchanged. <edburns> hpdueni: Wow, that's subtle. <edburns> hpdueni: I think it's really because Application.createComponent() is not being called based on the scope of the binding. <hpdueni> Now I suspect if we need a binding-scope or if we should just rely on the ViewRootChangeEvent (which i requested in http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876 ) to reset all component bindings rogerk1 (~Adium@pool-96-237-170-36.bstnma.fios.verizon.net) has joined ##jsf <edburns> hpdueni: When you say "reset all component bindings" do you mean that funny little traversal we do of the tree before really getting started with the lifecycle? <hpdueni> or what we already have in CS JSF is a Bindings bean that should be used for all component bindings - and that one is cleared whenever ViewRoot changes <ioss> hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right? <hpdueni> with reset component binding when viewroot changes I mean, the backing bean which holds the bound component must release that component which is from the previous view <ioss> or why would you want to hold the component for longer then a request? <hpdueni> for simplicity we used e.g. h:panelGroup bindgin="# {facesContext.attributes['someid']} " and then ass that el into another CC to pass on teh dynamic clientId <hpdueni> ioss: that problem already happens within one request - as required, we never hold bindings longer than a request. <hpdueni> ioss: but as it tunred out, request scope is already too long in case when viewroot changes - <edburns> hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry. <hpdueni> edburns: exactly, since the component that was created in restore phase is bound to something in request scope, the component is still there after viewRoot changed and therfore Application.createComponent() will not be invoked and none of teh resource dependencies are detected <ioss> Hanspeter: how about always returning null? <ioss> then your component binding should get reset on the render-phase <ioss> you should possibly get a call on restore-view and another one after the view changes <edburns> ak: I see. Actually, there were no changes in the XSD for facelet taglibs in 2.1, so you can just use the 2.0 one. <hpdueni> ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ... <ioss> hpdueni: sure, name the binding in another way <ioss> <edburns> In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago. <ioss> getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent <hpdueni> ioss: would mean to have one attribute name with only a set method to pass teh component and another read-only name to retrieve it ... <ioss> right <hpdueni> ioss: that could work, would that be your general recommendation for component binding ? <ioss> hpdueni: not the nicest approach I agree, but still not horrible I would say <ioss> hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach <ioss> hpdueni: I nearly never use componentbinding <ioss> hpdueni: I am more a "lookup"-guy <hpdueni> ioss: yea, it has its pitfalls mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf <ioss> also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development) <edburns> ak: Can you please file an issue in the docmentation sub-component on this JIRA: http://java.net/jira/browse/JAVASERVERFACES <hpdueni> ioss: now we are close to what we do - we actually need to pass the id of one component to some CC - but as the component's clientId is unknown at development time we pass the component using this binding . <ioss> hpdueni: so the template author does not know the id? <hpdueni> ioss: not the full clientId - that may change depending on if you are running as a web app or as a Portlet - both is possible from the same web app instance <ioss> hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question <ioss> ok <ioss> so this is really some sort of fire-and-(partially)-forget <ioss> i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly <ioss> directly=by java code <ioss> by java code=non jsf implementation java code <hpdueni> ioss: kind of, but still I need a writable property to get hold on the component which I want to read-only from somewhere else <hpdueni> I just think some of the new features interfere with component binding and we need a general approach for that <ioss> hpdueni: if you like to go creazy you could add an ELResolver, that will set even a private property <ioss> or one that will return null always when el is used <ioss> that's actually not to bad <ioss> if you can come up with a naming convention, or annotations <ioss> or a "fake" scope <ioss> # {componentwriteonlybinding.mybean.property} <ioss> so setter and getter would work normally, but el will always return null <ioss> hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too <hpdueni> ioss: sounds somehow weird - actually, thinking on that kind of use my binding should work as readonly only while component tree is built - (buildView) - to prevent passing the component to the new view and allow Application.createComponent() doing it's work <hpdueni> ioss: I wouldn't like another ELResolver for that as there are already so many ELResolvers involved - and writing to private method would involve reflection and is somehow dirty <hpdueni> ioss: talking about face scope - a custom scope could hanlde that <ioss> hpdueni: right <hpdueni> ioss: on the other hand, I'd like a solution for all JSF users, not only the ones that are aware of that potential problem <ioss> hpdueni: couldn't you use a prerender event? <ioss> hpdueni: it guess it does not matter for you, if the view changed or not, you just have to get rid of that component before rendering <hpdueni> ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase <ioss> hpdueni: I think a scope is the easiest way to cope with that for now. either clean the scope, or let the scope have a "special" getter, while the normal getter will return null always <hpdueni> ioss: but now, where does that lead us - would that mean standard bindings usage should behave always like this? Then we could really use a BindingsScope to support that <ioss> hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime <hpdueni> ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase <ioss> right <hpdueni> ioss: whatever it's called - it would have separate lifetime for execute phases and render phase <hpdueni> ioss: that is pretty close to the two Portlet phases <ioss> you could probably even use it for some fancy persistence stuff, like make the "execute" phase transactional and write enabled, while the request-phase would have an long-running em to cope with lazy-load, but also would not allow to persist anything <ioss> Reminds me, that I have to read about portlets! <hpdueni> ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that? <edburns> hpdueni: Ok, so ioss proposed a workaround involving an extra javabeans property, and then the discussion went to having a scope for this use-case. <hpdueni> edburns: yes, some special ELResolver was also in discussion <edburns> hpdueni: But really, this is closelely related to < http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876 >. <edburns> Let me capture this discussion to the comment thread on the issue. <hpdueni> edburns: what would be a solution for everybody - or should binding be considered as advanced usage where one has to know the bindings might need to be cleared in certain cases even in the middle of the request?
        Hide
        Darious3 added a comment -

        The bindings issue mentioned in the chat is somewhat related to the problem that if the view navigated to contains meta-data, that meta-data isn't processed. See JAVASERVERFACES-2279

        Show
        Darious3 added a comment - The bindings issue mentioned in the chat is somewhat related to the problem that if the view navigated to contains meta-data, that meta-data isn't processed. See JAVASERVERFACES-2279
        Hide
        Ed Burns added a comment -

        Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.

        Show
        Ed Burns added a comment - Set priority to baseline ahead of JSF 2.3 triage. Priorities will be assigned accurately after this exercise.
        Hide
        Ed Burns added a comment -

        Feel free to re-open if you want to contribute the fix yourself.

        Show
        Ed Burns added a comment - Feel free to re-open if you want to contribute the fix yourself.

          People

          • Assignee:
            Unassigned
            Reporter:
            Ed Burns
          • Votes:
            1 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: