ViewChangedEvent

[glassfishrobot]

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?

Environment

Operating System: All Platform: Sun

Affected Versions

[1.1]

[glassfishrobot]

Reported by @edburns

[glassfishrobot]

rogerk said: triage

[glassfishrobot]

dueni said: 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.

[glassfishrobot]

@edburns said:

jsf freenode IRC discussion

Hi all. I discovered a problem using component binding and teh detection of annotated ResourceDependencies e.g. in renderers when navigating to the same page, I end up with a new ViewRoot instance but I don't get the resource dependencies from annotations. that is because the component binding prevents the tag handlers from beeing invoked in the render phase after the viewRoot was exchanged. hpdueni: Wow, that's subtle. hpdueni: I think it's really because Application.createComponent() is not being called based on the scope of the binding. 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](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 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? 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 hpdueni: if your binding would always return null, wouldn't that solve the problem? not sure I got your issue right? 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 or why would you want to hold the component for longer then a request? 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 ioss: that problem already happens within one request - as required, we never hold bindings longer than a request. ioss: but as it tunred out, request scope is already too long in case when viewroot changes - hpdueni: Yes, I know requestscope is too long when the viewroot changes, but I'm still trying to understand your quandry. 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 Hanspeter: how about always returning null? then your component binding should get reset on the render-phase you should possibly get a call on restore-view and another one after the view changes 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. ioss: if teh binding always returns null I can't use it anymore to pass component references to some other component ... hpdueni: sure, name the binding in another way  In fact, I just had to make the first change in the facelet taglib xsd since 2.0 a few weeks ago. getTemplateComponent => null, setTemplateComponent => normal setter + getComponent => returns the one that was set by setTemplateComponent 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 ... right ioss: that could work, would that be your general recommendation for component binding ? hpdueni: not the nicest approach I agree, but still not horrible I would say hpdueni: for components that you will never provide yourself (you can not return null there) I guess it is a possible approach hpdueni: I nearly never use componentbinding hpdueni: I am more a "lookup"-guy  ioss: yea, it has its pitfalls * mbenson_ (~mbenson@apache/committer/mbenson) has joined ##jsf also there is a myfaces codi extension to bind components to longer scopes, that works that way (I think it is still in development) ak: Can you please file an issue in the docmentation sub-component on this JIRA: [http://java.net/jira/browse/JAVASERVERFACES](http://java.net/jira/browse/JAVASERVERFACES) 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 . hpdueni: so the template author does not know the id? 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 hpdueni: If it is different templates (inclusion/etc) it is probably cleaner to bind the component in question ok so this is really some sort of fire-and-(partially)-forget i guess a readonly property describes exactly your "contract", as that component is never meant to be set directly directly=by java code by java code=non jsf implementation java code  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 I just think some of the new features interfere with component binding and we need a general approach for that hpdueni: if you like to go creazy  you could add an ELResolver, that will set even a private property or one that will return null always when el is used that's actually not to bad if you can come up with a naming convention, or annotations or a "fake" scope # {componentwriteonlybinding.mybean.property} so setter and getter would work normally, but el will always return null hpdueni: but i think the viewchangedevent is not a bad one, you'll just have to find a good place to "bind" them too 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 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 ioss: talking about face scope - a custom scope could hanlde that  hpdueni: right 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 hpdueni: couldn't you use a prerender event? 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 ioss: sure - to always get a fresh or updated component in buildView all such bindings could be thrown away in before render phase 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 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 hpdueni: well i wouldn't call it bindingscope, but there might be use for a scope that has a "half-request" lifetime ioss: such a bindings scope would survive during the execute phases and be a separate instance for the render phase right ioss: whatever it's called - it would have separate lifetime for execute phases and render phase ioss: that is pretty close to the two Portlet phases  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  Reminds me, that I have to read about portlets!  ioss: guess we close the discussion for now - was anybody else listening on that? Any other positions on that? 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. edburns: yes, some special ELResolver was also in discussion hpdueni: But really, this is closelely related to <[http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876](http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-876)>. Let me capture this discussion to the comment thread on the issue. 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?

[glassfishrobot]

darious3 said: 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

[glassfishrobot]

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

[glassfishrobot]

@edburns said: Feel free to re-open if you want to contribute the fix yourself.

[glassfishrobot]

This issue was imported from java.net JIRA JAVASERVERFACES_SPEC_PUBLIC-876

[glassfishrobot]

Marked as won't fix on Tuesday, August 12th 2014, 12:47:32 pm