Hi,
I'm not exactly sure if I understand you.
PartialViewContext#processPartial() describes how the XML response should
be rendered. It does not describe how the XML response is
processed/executed in client side. This is described in jsf.ajax.response
jsdoc.
Cheers, B
On Tue, Oct 25, 2016 at 5:42 AM, Leonardo Uribe <leonardo.uribe_at_irian.at>
wrote:
> Hi
>
> Sorry for reopen this topic again (cannot reopen
> JAVASERVERFACES_SPEC_PUBLIC-1423), but I notice something that was not
> specified fully. The javadoc of PartialViewContext.processPartial(...)
> says this:
>
> "... When the indicated phaseId equals PhaseId.RENDER_RESPONSE,
> then perform the following tasks in sequence: ..."
>
> "... 5. If isRenderAll() returns false, then write out each
> script of getEvalScripts() as an eval element. ..."
>
> The problem is as the javadoc is written, the <eval> scripts are
> executed at last, or in other words after the nodes are updated. But
> The resource loading should be done "before" the ajax update is applied,
> otherwise a javascript exception could be thrown, because the <update>
> block could contain references to the resources to be loaded.
>
> Please note the intention of getEvalScripts() is correct (<eval> blocks
> created by developers should be executed normally after <update> blocks),
> but in this case we want something to load resources dynamically.
>
> The most simple solution is replace getEvalScripts() with two methods:
> getFirstEvalScripts() and getLastEvalScripts() or something like that.
>
> regards,
>
> Leonardo Uribe
>
>
>
>
>
>
> 2016-07-26 17:00 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:
>
>> Hi
>>
>> Yes, it is clear. +1
>>
>> regards,
>>
>> Leonardo
>>
>> 2016-07-26 3:11 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>
>>> Leo,
>>>
>>> Please see the updated API proposal in https://java.net/jira/brows
>>> e/JAVASERVERFACES_SPEC_PUBLIC-1423?focusedCommentId=392837
>>>
>>> Is it clear that way?
>>>
>>> Cheers, B
>>>
>>> On Tue, Jul 26, 2016 at 8:16 AM, Leonardo Uribe <leonardo.uribe_at_irian.at
>>> > wrote:
>>>
>>>> Hi
>>>>
>>>> Use something like javax.faces.Resource sounds good. After all, what
>>>> really matters is the scripts are loaded before perform the ajax operation
>>>> and for stylesheet is the same (no matter where the stylesheet are loaded,
>>>> preferred under <head> tag).
>>>>
>>>> regards,
>>>>
>>>> Leonardo Uribe
>>>>
>>>> 2016-07-26 0:12 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> Thank you for your thoughts. Definitely valid. I will take those into
>>>>> account.
>>>>>
>>>>> How about javax.faces.Resource instead of javax.faces.ViewHead?
>>>>>
>>>>> Cheers, B
>>>>>
>>>>> On Tue, Jul 26, 2016, 02:31 Leonardo Uribe <leonardo.uribe_at_irian.at>
>>>>> wrote:
>>>>>
>>>>>> Hi
>>>>>>
>>>>>> BS>> 1. No substantial changes in API/impl are necessary in order to
>>>>>> discover
>>>>>> BS>> newly added component resources provided that they are all added
>>>>>> via
>>>>>> BS>> UIViewRoot#addComponentResource().
>>>>>>
>>>>>> Yes, it looks good. Good idea to use UIViewRoot#processEvent() and
>>>>>> PostRestoreStateEvent.
>>>>>>
>>>>>> The only thing to notice is the simplification done for a component
>>>>>> resource
>>>>>> in order to be added. I resume it in this sentence:
>>>>>>
>>>>>> "... If a component resource has "name" and optionally "library"
>>>>>> property set
>>>>>> and does not have children and ResourceHandler#getRendererTyp
>>>>>> eForResourceName(
>>>>>> String resourceName) and getRendererType() is equals to
>>>>>> 'javax.faces.resource.Script' ..."
>>>>>>
>>>>>> What I mean is the way how the simplification is done must be
>>>>>> explicit in the
>>>>>> spec. That also means the full algorithm must be somewhere in the
>>>>>> javadoc or
>>>>>> in the spec pdf, maybe adding some lines in JSF 2.3 section 13 Ajax
>>>>>> Integration.
>>>>>>
>>>>>> I would like a general solution to the problem, but I think a
>>>>>> simplification
>>>>>> for only .js resources is also valid.
>>>>>>
>>>>>> BS>> 2. I would like to (re)use the currently unsupported <update
>>>>>> BS>> id="javax.faces.ViewHead"> in jsf.js to perform adding of new
>>>>>> component
>>>>>> BS>> resources.
>>>>>>
>>>>>> Unfortunately here there is a problem. This has been already
>>>>>> specified in the
>>>>>> javascript documentation of jsf.ajax.response(request, context);
>>>>>>
>>>>>> "... If an <update> element is found in the response with the
>>>>>> identifier
>>>>>> javax.faces.ViewRoot:
>>>>>>
>>>>>> <update id="javax.faces.ViewRoot">
>>>>>> <![CDATA[...]]>
>>>>>> </update>
>>>>>>
>>>>>> Update the entire DOM replacing the appropriate head and/or body
>>>>>> sections
>>>>>> with the content from the response. ..."
>>>>>>
>>>>>> The hack done in MyFaces works because this part was specified, so I
>>>>>> do not
>>>>>> think it is a good idea to change that meaning. Instead, one way to
>>>>>> fix
>>>>>> the problem is adding the necessary methods to PartialResponseWriter,
>>>>>> as
>>>>>> suggested before. It is not pretty (update facelet-partialresponse
>>>>>> .xsd,
>>>>>> fix PartialResponseWriter, update section 13 ...), but I have not
>>>>>> found
>>>>>> another way to fix it yet.
>>>>>>
>>>>>> regards,
>>>>>>
>>>>>> Leonardo Uribe
>>>>>>
>>>>>>
>>>>>> 2016-07-22 11:30 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I posted a comment on https://java.net/jira/brows
>>>>>>> e/JAVASERVERFACES_SPEC_PUBLIC-1423 with my new findings and
>>>>>>> thoughts.
>>>>>>>
>>>>>>> In a nutshell:
>>>>>>>
>>>>>>> 1. No substantial changes in API/impl are necessary in order to
>>>>>>> discover newly added component resources provided that they are all added
>>>>>>> via UIViewRoot#addComponentResource().
>>>>>>> 2. I would like to (re)use the currently unsupported <update
>>>>>>> id="javax.faces.ViewHead"> in jsf.js to perform adding of new component
>>>>>>> resources.
>>>>>>>
>>>>>>> Cheers, B
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Jul 4, 2016 at 8:06 PM, Leonardo Uribe <
>>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>>
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> BS>> As to "render target", isn't PartialViewContext#getRenderIds()
>>>>>>>> sufficient
>>>>>>>> BS>> for the task? This returns a mutable collection of client IDs
>>>>>>>> which need
>>>>>>>> BS>> to be updated on current partial request.
>>>>>>>>
>>>>>>>> I have been thinking about this for some time to see what's missing
>>>>>>>> from the
>>>>>>>> spec perspective, and the answer is no, getRenderIds() is not
>>>>>>>> enough to do
>>>>>>>> the job (in my personal opinion).
>>>>>>>>
>>>>>>>> The reason is getRenderIds() relies on the fact that it should be a
>>>>>>>> html tag
>>>>>>>> with an id rendered on the client markup that can be updated. If
>>>>>>>> there is
>>>>>>>> no html tag with id set, an ajax update will not work. Please note
>>>>>>>> getRenderIds() works for most cases, but for <head> and <body>
>>>>>>>> tags, both
>>>>>>>> does not allow an id to be set. It is true that there is a solution
>>>>>>>> updating
>>>>>>>> the whole content, but the central point is there is a better
>>>>>>>> solution that
>>>>>>>> could be done with the changes proposed previously in this thread.
>>>>>>>>
>>>>>>>> In summary, the current algorithm for ajax has these weaknesses
>>>>>>>> (sorry if
>>>>>>>> you found this too repetitive):
>>>>>>>>
>>>>>>>> 1. Resource components added as part of a partial update requires to
>>>>>>>> add some html markup inside a <head> or <body> tag, and both tags
>>>>>>>> does not have
>>>>>>>> an id set, and the current API doesn't help to do it without
>>>>>>>> replace
>>>>>>>> the whole tag.
>>>>>>>> 2. If a new component is added, there is no html tag we can use to
>>>>>>>> update it.
>>>>>>>>
>>>>>>>> The first case we have already discussed.
>>>>>>>>
>>>>>>>> The second one is more theoretical but goes far beyond what we have
>>>>>>>> discussed.
>>>>>>>> Anyway, just for clarity sake I'm going to describe it fully and
>>>>>>>> give a
>>>>>>>> possible solution.
>>>>>>>>
>>>>>>>> Think about this fragment:
>>>>>>>>
>>>>>>>> <h:panelGroup id="content" layout="block">
>>>>>>>> <c:if test="#{bean.chooseSomething}">
>>>>>>>> <h:outputScript name="script2.js"/>
>>>>>>>> </c:if>
>>>>>>>> <h:commandButton value="Update" actionListener="#{bean.check}">
>>>>>>>> <f:ajax />
>>>>>>>> </h:commandButton>
>>>>>>>> </h:panelGroup>
>>>>>>>>
>>>>>>>> Now imagine that when an ajax request is triggered, the code inside
>>>>>>>> bean.check() changes chooseSomething from false to true. The
>>>>>>>> lifecycle looks
>>>>>>>> like this:
>>>>>>>>
>>>>>>>> - Lifecycle Execute (....) invoke bean.check, change
>>>>>>>> chooseSomething to true.
>>>>>>>> - Call to vdl.buildView() refresh the whole component tree =>
>>>>>>>> h:outputScript
>>>>>>>> added and PostAddToViewEvent is triggered.
>>>>>>>> - f:ajax requires h:commandButton to be rendered, so a partial
>>>>>>>> update over the
>>>>>>>> commandButton is activated.
>>>>>>>>
>>>>>>>> What's wrong with this? A new component (h:outputScript) was added
>>>>>>>> on a
>>>>>>>> partial request. But the component never had the chance to update
>>>>>>>> itself, so
>>>>>>>> the script was never updated. Ok, you can replace f:ajax with:
>>>>>>>>
>>>>>>>> <f:ajax render="content"/>
>>>>>>>>
>>>>>>>> Problem solved, but is all that really necessary? What if
>>>>>>>> chooseSomething does
>>>>>>>> not change? why update the content in that case?.
>>>>>>>>
>>>>>>>> Please note every component addition triggers a PostAddToViewEvent.
>>>>>>>> It is
>>>>>>>> possible to use that event to detect the change. Since the
>>>>>>>> component is a new
>>>>>>>> one, there is no id on the client side, but probably an ancestor
>>>>>>>> could have an
>>>>>>>> id set. The problem is the current algorithm does not have a
>>>>>>>> standard way to
>>>>>>>> check whether it has an id set on the client or not.
>>>>>>>>
>>>>>>>> But if a method like UIComponent.isClientIdRendered(...) exist, we
>>>>>>>> could create
>>>>>>>> an algorithm that recursively find the parent that needs to be
>>>>>>>> rendered and
>>>>>>>> include it into the current ajax request adding it to
>>>>>>>> getRenderIds(). In that
>>>>>>>> sense, the algorithm could automatically find that "content" needs
>>>>>>>> to be
>>>>>>>> updated and activate the render automatically.
>>>>>>>>
>>>>>>>>
>>>>>>>> Going back to the main topic, getRenderIds() relies on a logic that
>>>>>>>> for each
>>>>>>>> id there is an html markup counterpart.
>>>>>>>> setRenderTargetComponent(...)
>>>>>>>> and getTargetComponentsToRender(...) are different because the
>>>>>>>> intention here
>>>>>>>> is to say "... this (resource) component needs to be added for this
>>>>>>>> target,
>>>>>>>> the way how you want to update the client is up to you ...".
>>>>>>>>
>>>>>>>> regards,
>>>>>>>>
>>>>>>>> Leonardo
>>>>>>>>
>>>>>>>> 2016-07-01 13:01 GMT-05:00 Neil Griffin <
>>>>>>>> neil.griffin_at_portletfaces.org>:
>>>>>>>>
>>>>>>>>> Kyle Stiemann will also be commenting on the following issue in
>>>>>>>>> JIRA:
>>>>>>>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1423
>>>>>>>>>
>>>>>>>>> Again, please click on the "watch" link in JIRA if you are
>>>>>>>>> interested. Thanks.
>>>>>>>>>
>>>>>>>>> > On Jun 27, 2016, at 7:12 AM, Bauke Scholtz <balusc_at_gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> >
>>>>>>>>> > As to "render target", isn't PartialViewContext#getRenderIds()
>>>>>>>>> sufficient for the task? This returns a mutable collection of client IDs
>>>>>>>>> which need to be updated on current partial request.
>>>>>>>>> >
>>>>>>>>> > Cheers, B
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > On Mon, Jun 27, 2016 at 11:56 AM, Leonardo Uribe <
>>>>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>>>> > Hi
>>>>>>>>> >
>>>>>>>>> > 2016-06-24 10:35 GMT+02:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>>>>>>> > encodePartial() looks OK.
>>>>>>>>> >
>>>>>>>>> > I only don't understand how RequestViewContext,
>>>>>>>>> setRenderTarget() and getComponentsToRender() are useful as compared to
>>>>>>>>> UIViewRoot#addComponentResource()/getComponentResources().
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > I haven't found good names for those ones but I'll explain the
>>>>>>>>> intention of them.
>>>>>>>>> >
>>>>>>>>> > setRenderTarget(...) is used to indicate a component inside a
>>>>>>>>> specified target needs to be updated on the client in the current partial
>>>>>>>>> request. In comparison, addComponentResource(...) is used to add the
>>>>>>>>> component to the tree.
>>>>>>>>> >
>>>>>>>>> > I know both methods look similar but they are not the same. The
>>>>>>>>> reason is addComponentResource(...) is used to affect the component tree,
>>>>>>>>> so it will be called each time the component tree is build (initial state,
>>>>>>>>> delta, ...), and setRenderTarget(...) is used as a flag to indicate how the
>>>>>>>>> current partial request must be rendered. Add a resource could cause the
>>>>>>>>> flag to be activated, but not every call to addComponentResource(...) cause
>>>>>>>>> the flag to be activated.
>>>>>>>>> >
>>>>>>>>> > Maybe a better name could be setRenderTargetComponent(...)
>>>>>>>>> >
>>>>>>>>> > getComponentsToRender(...) returns the list of the components
>>>>>>>>> bound to an specific target that needs to be rendered on the current ajax
>>>>>>>>> request. in comparison UIViewRoot.getComponentResources(...)
>>>>>>>>> return all components bound to an specific target in the view.
>>>>>>>>> >
>>>>>>>>> > Maybe a better name could be getTargetComponentsToRender(...)
>>>>>>>>> >
>>>>>>>>> > These two methods are in fact more bound to UIViewRoot than to
>>>>>>>>> FacesContext, but the data they manage is "transient", which means the data
>>>>>>>>> is discarded at the end of the request.
>>>>>>>>> >
>>>>>>>>> > I also don't understand "You can't use an eval block because the
>>>>>>>>> encoding does not work correctly". Which encoding exactly is problematic?
>>>>>>>>> (there's at least character encoding, html encoding and javascript encoding
>>>>>>>>> involved). Why couldn't that part be fixed instead?
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > If you have a block like this:
>>>>>>>>> >
>>>>>>>>> > <h:outputScript target="head">
>>>>>>>>> > script2 = function(){
>>>>>>>>> > alert("script2");
>>>>>>>>> > }
>>>>>>>>> > </h:outputScript>
>>>>>>>>> >
>>>>>>>>> > you could try to do in code something like this:
>>>>>>>>> >
>>>>>>>>> > prwriter.startEval(....);
>>>>>>>>> > renderChildren(...);
>>>>>>>>> > prwriter.endEval();
>>>>>>>>> >
>>>>>>>>> > I tried but it doesn't work because you need to encode it
>>>>>>>>> properly, but since there is a ResponseWriter outside of your control, you
>>>>>>>>> can't encapsulate the script without do some nasty hacks over
>>>>>>>>> ResponseWriter/PartialResponseWriter.
>>>>>>>>> >
>>>>>>>>> > In this case eval(...) does not work, so we need to attach the
>>>>>>>>> node (well, if we want to fix this use case, which I think we should).
>>>>>>>>> >
>>>>>>>>> > regards,
>>>>>>>>> >
>>>>>>>>> > Leonardo Uribe
>>>>>>>>> >
>>>>>>>>> > Cheers, B
>>>>>>>>> >
>>>>>>>>> > On Thu, Jun 23, 2016 at 2:45 PM, Leonardo Uribe <
>>>>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>>>> > Hi
>>>>>>>>> >
>>>>>>>>> > Since there is already a solution almost completed in MyFaces
>>>>>>>>> (which an small sample
>>>>>>>>> > done some time ago) I did a prototype to see how it works and
>>>>>>>>> try to find other details
>>>>>>>>> > that could give us a better idea about what to do.
>>>>>>>>> >
>>>>>>>>> > From spec perspective the relevant changes are:
>>>>>>>>> >
>>>>>>>>> > UIComponent: Add the following methods:
>>>>>>>>> >
>>>>>>>>> > public void encodePartial(FacesContext context) throws
>>>>>>>>> IOException
>>>>>>>>> >
>>>>>>>>> > Default implementation call startUpdate(), encodeAll(),
>>>>>>>>> endUpdate();
>>>>>>>>> >
>>>>>>>>> > UIComponentBase: Add the following methods:
>>>>>>>>> >
>>>>>>>>> > public void encodePartial(FacesContext context) throws
>>>>>>>>> IOException
>>>>>>>>> >
>>>>>>>>> > Default implementation if renderer found call
>>>>>>>>> Renderer.encodePartial, otherwise call
>>>>>>>>> > super.encodePartial(...)
>>>>>>>>> >
>>>>>>>>> > Renderer: Add the following methods:
>>>>>>>>> >
>>>>>>>>> > public void encodePartial(FacesContext context, UIComponent
>>>>>>>>> component)
>>>>>>>>> > throws IOException
>>>>>>>>> >
>>>>>>>>> > Default implementation call startUpdate(), encodeAll(),
>>>>>>>>> endUpdate();
>>>>>>>>> >
>>>>>>>>> > RequestViewContext: (it could be located in FacesContext)
>>>>>>>>> >
>>>>>>>>> > public void setRenderTarget(String target, boolean value,
>>>>>>>>> > UIComponent component)
>>>>>>>>> >
>>>>>>>>> > public List<UIComponent> getComponentsToRender(String target);
>>>>>>>>> > (it has an internal set to avoid duplicates, find a better name)
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > The remaining tasks are implement encodePartial(...) for
>>>>>>>>> h:outputScript,
>>>>>>>>> > h:outputStylesheet, and update the implementation in
>>>>>>>>> PartialViewContext to call
>>>>>>>>> > encodePartial.
>>>>>>>>> >
>>>>>>>>> > This is a fragment of the generated response when the change
>>>>>>>>> > is activated:
>>>>>>>>> >
>>>>>>>>> > <partial-response id="j_id__v_0"><changes><eval>
>>>>>>>>> > <![CDATA[myfaces._impl.core._Runtime.loadScript(
>>>>>>>>> > "/client-window-example/javax.faces.resource/script1.js.jsf",
>>>>>>>>> null, null,
>>>>>>>>> > "UTF-8", false);]]></eval><update id="content"><![CDATA[ ...
>>>>>>>>> >
>>>>>>>>> > The main page look like this:
>>>>>>>>> >
>>>>>>>>> > <h:commandLink id="page1" value="Page 1"
>>>>>>>>> actionListener="#{ajaxContentBean.setPage1}">
>>>>>>>>> > <f:ajax render=":content"/>
>>>>>>>>> > </h:commandLink>
>>>>>>>>> > ...
>>>>>>>>> > <h:panelGroup id="content" layout="block">
>>>>>>>>> > <ui:include src="#{ajaxContentBean.page}.xhtml" />
>>>>>>>>> > </h:panelGroup>
>>>>>>>>> >
>>>>>>>>> > And the included page has something like this:
>>>>>>>>> >
>>>>>>>>> > <h:outputScript name="script1.js" target="head"/>
>>>>>>>>> > <h:commandButton type="button" value="MSG" onclick="script1()"/>
>>>>>>>>> >
>>>>>>>>> > It works well for scripts but try to update something like this:
>>>>>>>>> >
>>>>>>>>> > <h:outputScript target="head">
>>>>>>>>> > script2 = function(){
>>>>>>>>> > alert("script2");
>>>>>>>>> > }
>>>>>>>>> > </h:outputScript>
>>>>>>>>> >
>>>>>>>>> > or this:
>>>>>>>>> >
>>>>>>>>> > <h:outputStylesheet name="style3.css"/> (target="head" is
>>>>>>>>> implicit)
>>>>>>>>> >
>>>>>>>>> > is the real problem. You can't use an eval block because the
>>>>>>>>> encoding does not work
>>>>>>>>> > correctly, so you really need to insert the DOM node. But the
>>>>>>>>> current API in
>>>>>>>>> > PartialResponseWriter is useless because head tag does not have
>>>>>>>>> an id or name where you
>>>>>>>>> > can grab.
>>>>>>>>> >
>>>>>>>>> > Ok, we can try to "make cheat" a little in this part and try:
>>>>>>>>> >
>>>>>>>>> > prwriter.startInsertAfter("javax.faces.ViewHead");
>>>>>>>>> >
>>>>>>>>> > but strictly speaking this should insert the html markup after
>>>>>>>>> </head>, but we want
>>>>>>>>> > the code inside. I just modified the js code to include it
>>>>>>>>> inside in this case, but for
>>>>>>>>> > a real implementation it is required to add some methods to
>>>>>>>>> PartialResponseWriter like:
>>>>>>>>> >
>>>>>>>>> > public void startInsertFirst(String targetId) throws IOException
>>>>>>>>> > public void startInsertLast(String targetId) throws IOException
>>>>>>>>> >
>>>>>>>>> > (find a better name, or maybe startInsertInsideAfter?, look in
>>>>>>>>> another framework how
>>>>>>>>> > they name this?)
>>>>>>>>> >
>>>>>>>>> > There is also another problem: How do you know you need to
>>>>>>>>> insert the node instead of
>>>>>>>>> > update it? The only clue is the node is processed specially in
>>>>>>>>> PartialViewContext like
>>>>>>>>> > this:
>>>>>>>>> >
>>>>>>>>> > List<UIComponent> componentsToRender =
>>>>>>>>> rvc.getComponentsToRender("head");
>>>>>>>>> >
>>>>>>>>> > for (UIComponent resource: componentsToRender)
>>>>>>>>> > {
>>>>>>>>> > resource.encodePartial(_facesContext);
>>>>>>>>> > }
>>>>>>>>> >
>>>>>>>>> > So, we need some flag or context attribute or something to
>>>>>>>>> indicate we are attempting
>>>>>>>>> > to include something new on the tree. Something like
>>>>>>>>> JAVAX_FACES_INSERT_PARTIAL for
>>>>>>>>> > example and something like JAVAX_FACES_UPDATE_TARGET, so the
>>>>>>>>> Renderer in encodePartial
>>>>>>>>> > can decide how to update the view.
>>>>>>>>> >
>>>>>>>>> > The partial response markup looks like this:
>>>>>>>>> >
>>>>>>>>> > <changes><insert><after id="javax.faces.ViewHead"><![CDATA[
>>>>>>>>> > <script type="text/javascript">
>>>>>>>>> > script2 = function(){
>>>>>>>>> > alert("script2");
>>>>>>>>> > }
>>>>>>>>> > </script>]]></after></insert>
>>>>>>>>> >
>>>>>>>>> > It should be better
>>>>>>>>> >
>>>>>>>>> > <changes><insert><last id="javax.faces.ViewHead"><![CDATA[<script
>>>>>>>>> type="text/javascript">
>>>>>>>>> > script2 = function(){
>>>>>>>>> > alert("script2");
>>>>>>>>> > }
>>>>>>>>> > </script>]]></last></insert>
>>>>>>>>> >
>>>>>>>>> > And that's it the proposal from MyFaces side. I think it is
>>>>>>>>> flexible enough to allow the
>>>>>>>>> > algorithm using "two lists comparison", but also enough to allow
>>>>>>>>> the implementation
>>>>>>>>> > inside MyFaces.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > But note the issue proposed here:
>>>>>>>>> >
>>>>>>>>> > JAVASERVERFACES_SPEC_PUBLIC-1404 Add
>>>>>>>>> UIViewRoot#getRenderedComponentResources()
>>>>>>>>> >
>>>>>>>>> > is still valid. But I'll send the comments related to that one
>>>>>>>>> in other email.
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Suggestions are welcomed.
>>>>>>>>> >
>>>>>>>>> > regards,
>>>>>>>>> >
>>>>>>>>> > Leonardo Uribe
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > 2016-06-22 9:19 GMT+02:00 Cagatay Civici <
>>>>>>>>> cagatay.civici_at_gmail.com>:
>>>>>>>>> > Sure, actually Thomas Andraschko, the reporter of
>>>>>>>>> JAVASERVERFACES_SPEC_PUBLIC-1423 has implemented it in PF, I’ve
>>>>>>>>> asked him for details and his response briefly is;
>>>>>>>>> >> Have a look at:
>>>>>>>>> >> org.primefaces.application.resource.DynamicResourcesPhaseListener
>>>>>>>>> - it collects the initial resources on the ajax request
>>>>>>>>> >> org.primefaces.context.PrimePartialResponseWriter - ln 278;
>>>>>>>>> gets the resources again, creates a diff of the initial and new resources,
>>>>>>>>> render some JS to load the resources dynamically
>>>>>>>>> > Regards,
>>>>>>>>> >
>>>>>>>>> > Cagatay Civici
>>>>>>>>> > PrimeFaces Lead
>>>>>>>>> > PrimeTek Informatics
>>>>>>>>> > On Wednesday 22 June 2016 at 10:02, Bauke Scholtz wrote:
>>>>>>>>> >
>>>>>>>>> >> Cagatay, can you point out it in the PrimeFaces codebase? Then
>>>>>>>>> I will look at similarities and differences and if necessary optimize the
>>>>>>>>> standard solution based on that.
>>>>>>>>> >>
>>>>>>>>> >> Cheers, B
>>>>>>>>> >>
>>>>>>>>> >>
>>>>>>>>> >> On Wed, Jun 22, 2016, 08:43 Cagatay Civici <
>>>>>>>>> cagatay.civici_at_gmail.com> wrote:
>>>>>>>>> >>> We also have a custom solution to this in PrimeFaces as it is
>>>>>>>>> a very common case. A standard solution would be preferred for sure.
>>>>>>>>> >>>
>>>>>>>>> >>> Regards,
>>>>>>>>> >>>
>>>>>>>>> >>> Cagatay Civici
>>>>>>>>> >>> PrimeFaces Lead
>>>>>>>>> >>> PrimeTek Informatics
>>>>>>>>> >>> On Tuesday 21 June 2016 at 22:34, Bauke Scholtz wrote:
>>>>>>>>> >>>
>>>>>>>>> >>>> Coming to it, a new encodeAjax() method in UIComponent and
>>>>>>>>> Renderer (I'd rather call it encodePartial(), in line with the existing
>>>>>>>>> API) is a great suggestion which could indeed solve this problem and has
>>>>>>>>> potential for solving/optimizing ajax based problems in a much more
>>>>>>>>> flexible way. This is indeed a small and easy change in the API (and impl).
>>>>>>>>> >>>>
>>>>>>>>> >>>> +1 from me.
>>>>>>>>> >>>>
>>>>>>>>> >>>> Cheers, B
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>> On Tue, Jun 21, 2016 at 5:22 PM, Bauke Scholtz <
>>>>>>>>> balusc_at_gmail.com> wrote:
>>>>>>>>> >>>>> As to writer.startEval(), as per
>>>>>>>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1412
>>>>>>>>> I've added a PartialViewContext#getEvalScripts() for JSF 2.3.
>>>>>>>>> This could be used.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> I will think about encodeAjax() and reply later.
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> Cheers, B
>>>>>>>>> >>>>>
>>>>>>>>> >>>>> On Tue, Jun 21, 2016 at 4:01 PM, Leonardo Uribe <
>>>>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>>>> >>>>>> Hi
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I just wanted to repost a comment from MyFaces issue
>>>>>>>>> tracker in 2012 about the issue being discussed now:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Luciano Deiru:
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Thanks for the reply.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> I don't think it's going to be possible for me to migrate
>>>>>>>>> my app to JSF2 without a
>>>>>>>>> >>>>>> complete re-write of the frontend. I did a little more
>>>>>>>>> digging to see if richfaces was
>>>>>>>>> >>>>>> the issue and i can across this section of the richfaces
>>>>>>>>> 4.2.2 development guide...
>>>>>>>>> >>>>>> ...
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> "JSF 2 does not allow resources such as JavaScript or
>>>>>>>>> Cascading Style Sheets (CSS) to
>>>>>>>>> >>>>>> be added if the element requiring the resource is not
>>>>>>>>> initially present in the JSF
>>>>>>>>> >>>>>> tree. As such, components added to the tree via Ajax must
>>>>>>>>> have any required resources
>>>>>>>>> >>>>>> already loaded. In RichFaces, any components added to the
>>>>>>>>> JSF tree should have
>>>>>>>>> >>>>>> components with corresponding resources included on the
>>>>>>>>> main page initially. To
>>>>>>>>> >>>>>> facilitate this, components can use the rendered="false"
>>>>>>>>> setting to not be
>>>>>>>>> >>>>>> rendered on the page."
>>>>>>>>> >>>>>> ...
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> So the only workaround would be to add every possible
>>>>>>>>> richfaces and primefaces component
>>>>>>>>> >>>>>> to the login page so it loads the JS and css. That's a bit
>>>>>>>>> depressing because you
>>>>>>>>> >>>>>> can't create a "pure ajax"/dynamic application in JSF2 even
>>>>>>>>> tho i was possible in JSF1.
>>>>>>>>> >>>>>> It seems like a widely used approach and there are a lot of
>>>>>>>>> forum posts about the
>>>>>>>>> >>>>>> issue but no one is ever able to get it working without
>>>>>>>>> including the hidden components.
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> regards,
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> Leonardo Uribe
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>> 2016-06-21 15:55 GMT+02:00 Leonardo Uribe <
>>>>>>>>> leonardo.uribe_at_irian.at>:
>>>>>>>>> >>>>>>> Hi
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> I see.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> BS>> Also, to avoid duplicates and/or unnecessary
>>>>>>>>> re-rendering, all so far rendered
>>>>>>>>> >>>>>>> BS>> resources must be remembered in JSF state. AFAIC this
>>>>>>>>> is currently not the case.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Well, this is information related to the view that is
>>>>>>>>> implicit there, but you want to
>>>>>>>>> >>>>>>> avoid to put it in the state.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> That's the reason why I like the way it is working in
>>>>>>>>> MyFaces, because we just keep
>>>>>>>>> >>>>>>> track of the change, rather than store that information in
>>>>>>>>> the state.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Write the script directly into the <eval> is possible, but
>>>>>>>>> right now from spec
>>>>>>>>> >>>>>>> perspective there are not the necessary "building blocks"
>>>>>>>>> available.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Both h:outputScript and h:outputStylesheet are components
>>>>>>>>> that are supposed to be
>>>>>>>>> >>>>>>> rendered as resources, but both components have Renderer
>>>>>>>>> instances, which are
>>>>>>>>> >>>>>>> the classes who finally decide how they should be
>>>>>>>>> rendered. Even if you have a list,
>>>>>>>>> >>>>>>> this list could include javascript/css or whatever and the
>>>>>>>>> resources could be rendered
>>>>>>>>> >>>>>>> in different ways.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> For example an h:outputScript could have children that
>>>>>>>>> could be js code. Or a
>>>>>>>>> >>>>>>> h:outputStylesheet could have a "media" property set.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> So if we want a "general" solution to the problem, which
>>>>>>>>> includes script, stylesheets
>>>>>>>>> >>>>>>> or whatever, it is necessary to know the component
>>>>>>>>> instance that needs to be added
>>>>>>>>> >>>>>>> or updated, and then ask the component how it should be
>>>>>>>>> rendered.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> The problem from the "building blocks" perspective, is
>>>>>>>>> there is no way the component
>>>>>>>>> >>>>>>> can know the current request is an ajax update.
>>>>>>>>> encodeAll(...) just means encode
>>>>>>>>> >>>>>>> everything and don't ask questions.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> I would like to have a method in UIComponent/Renderer
>>>>>>>>> called encodeAjax(...) for the
>>>>>>>>> >>>>>>> component, which by default start and end an <update>
>>>>>>>>> section and call by default
>>>>>>>>> >>>>>>> to encodeAll(...). Something like this
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> public void encodeAjax(FacesContext _facesContext,
>>>>>>>>> PartialResponseWriter writer) {
>>>>>>>>> >>>>>>> try
>>>>>>>>> >>>>>>> {
>>>>>>>>> >>>>>>> writer.startUpdate(target.get
>>>>>>>>> ClientId(_facesContext));
>>>>>>>>> >>>>>>> target.encodeAll(_facesContext);
>>>>>>>>> >>>>>>> }
>>>>>>>>> >>>>>>> finally
>>>>>>>>> >>>>>>> {
>>>>>>>>> >>>>>>> writer.endUpdate();
>>>>>>>>> >>>>>>> }
>>>>>>>>> >>>>>>> }
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> This part is done in PartialViewContext implementation,
>>>>>>>>> but if we can move it here
>>>>>>>>> >>>>>>> we could ask the component in a gentle way how it should
>>>>>>>>> be rendered. Then, from
>>>>>>>>> >>>>>>> this location we could override the method and call
>>>>>>>>> writer.startEval(...), which is
>>>>>>>>> >>>>>>> something is not possible in this moment, because there is
>>>>>>>>> no way right now to
>>>>>>>>> >>>>>>> customize this step for each component.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> In this way, you could add an script to load the
>>>>>>>>> stylesheet and then use the eval
>>>>>>>>> >>>>>>> to include it in the response.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> I have already mention this improvement in this mail some
>>>>>>>>> time ago:
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> https://java.net/projects/java
>>>>>>>>> serverfaces-spec-public/lists/jsr372-experts/archive/2015-
>>>>>>>>> 04/message/41
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> It looks we have yet another use case where this could be
>>>>>>>>> useful.
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> regards,
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> Leonardo Uribe
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>> 2016-06-21 14:51 GMT+02:00 Bauke Scholtz <balusc_at_gmail.com
>>>>>>>>> >:
>>>>>>>>> >>>>>>>> Hi,
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> OmniFaces has 3 solutions to dynamically include a
>>>>>>>>> (script) resource:
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> 1: Ajax#load() (just write script straight to <eval>)
>>>>>>>>> >>>>>>>> 2: Components#addScriptResourceToHead()
>>>>>>>>> >>>>>>>> 3: Components#addScriptResourceToBody()
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> Which one to use depends on the moment (which isn't yet
>>>>>>>>> refactored into a single utility method, this is TBD). When the request is
>>>>>>>>> an ajax request with partial rendering (i.e. ajax with NO @all), then use
>>>>>>>>> #1. Else when the current phase is NOT render response, or the view is in
>>>>>>>>> BUILDING state, then use #2. Else use #3.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> This is implemented for the unload script associated with
>>>>>>>>> OmniFaces @ViewScoped and this works quite well.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> Also, to avoid duplicates and/or unnecessary
>>>>>>>>> re-rendering, all so far rendered resources must be remembered in JSF
>>>>>>>>> state. AFAIC this is currently not the case.
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> Cheers, B
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>> On Tue, Jun 21, 2016 at 2:37 PM, Leonardo Uribe <
>>>>>>>>> leonardo.uribe_at_irian.at> wrote:
>>>>>>>>> >>>>>>>>> Hi
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> I have seen this issue has been opened in the spec issue
>>>>>>>>> tracker
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> https://java.net/jira/browse/J
>>>>>>>>> AVASERVERFACES_SPEC_PUBLIC-1423
>>>>>>>>> >>>>>>>>> Dynamic resource loading in ajax requests
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> I would like to contribute with some thoughts about the
>>>>>>>>> topic, since in MyFaces there
>>>>>>>>> >>>>>>>>> is a solution that is not perfect (if PartialViewContext
>>>>>>>>> is overriden, the code will
>>>>>>>>> >>>>>>>>> not work, so some third party libraries will not be able
>>>>>>>>> to use it), but it helps to
>>>>>>>>> >>>>>>>>> identify the missing points in the spec, and specify it
>>>>>>>>> faster.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> This issue could be also relevant for portlets.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The issue has been reported long time ago in:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> - https://issues.apache.org/jira/browse/MYFACES-3106
>>>>>>>>> >>>>>>>>> Resources not loaded when using a dynamic ui:inlclude
>>>>>>>>> and rendered via ajax
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> - https://issues.apache.org/jira/browse/MYFACES-3367
>>>>>>>>> >>>>>>>>> Detect when to update head or body target when content
>>>>>>>>> has been updated dynamically
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> - https://issues.apache.org/jira/browse/MYFACES-3659
>>>>>>>>> >>>>>>>>> Conditional include of scripts and stylesheets
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The first thing to understand the problem is identify
>>>>>>>>> the possible use cases we have:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> - c:if, ui:include src="#{...}" or facelet tag that
>>>>>>>>> dynamically update the tree.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> For example:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> ...
>>>>>>>>> >>>>>>>>> <f:ajax event="onclick" render="box"/>
>>>>>>>>> >>>>>>>>> ...
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> <div jsf:id="box">
>>>>>>>>> >>>>>>>>> <c:if test="#{...}">
>>>>>>>>> >>>>>>>>> <h:outputScript target="head" library="js"
>>>>>>>>> name="help.js" />
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> ...
>>>>>>>>> >>>>>>>>> </c:if>
>>>>>>>>> >>>>>>>>> </div>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Here we have a case when the components inside the c:if
>>>>>>>>> requires some javascript file,
>>>>>>>>> >>>>>>>>> but the update comes from an ajax request. The algorithm
>>>>>>>>> just somehow put the
>>>>>>>>> >>>>>>>>> h:outputScript on the head of the document, but the ajax
>>>>>>>>> does not trigger the head
>>>>>>>>> >>>>>>>>> refresh, so the component was added to the tree, but the
>>>>>>>>> javascript file was not loaded
>>>>>>>>> >>>>>>>>> and we finally have a broken panel.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> There are variants of the same example with
>>>>>>>>> h:outputStylesheet, or ui:include but the
>>>>>>>>> >>>>>>>>> reason is the same.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> - Dynamic but the resource is added by a
>>>>>>>>> @ResourceDependency annotation.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> This is similar to the previous case, but the component
>>>>>>>>> is added indirectly when
>>>>>>>>> >>>>>>>>> Application.createComponent(...) is executed.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The important thing to keep in mind is there are 3
>>>>>>>>> possible targets: "head", "body" and
>>>>>>>>> >>>>>>>>> "form". But the only thing we can do with the current
>>>>>>>>> spec is just force a full update
>>>>>>>>> >>>>>>>>> of each of these targets.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> So, in MyFaces there is a web config param called
>>>>>>>>> >>>>>>>>> org.apache.myfaces.STRICT_JSF_2_REFRESH_TARGET_AJAX
>>>>>>>>> that when it is activated, and
>>>>>>>>> >>>>>>>>> the previous situation happens, it just enable a flag so
>>>>>>>>> the target is updated with
>>>>>>>>> >>>>>>>>> the ajax request. If the "head" needs to be updated, the
>>>>>>>>> whole "head" and the updated
>>>>>>>>> >>>>>>>>> content is sent and so on.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The processing is done on process partial render time,
>>>>>>>>> after the ajax request is
>>>>>>>>> >>>>>>>>> rendered but before write the state token. Please note
>>>>>>>>> if the target is rendered before
>>>>>>>>> >>>>>>>>> this code, the algorithm should be able to detect the
>>>>>>>>> condition and do not duplicate
>>>>>>>>> >>>>>>>>> the response.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The solution is not perfect because it force render the
>>>>>>>>> whole target, when we only
>>>>>>>>> >>>>>>>>> need to render the html fragment of the added component
>>>>>>>>> (script/stylesheet/
>>>>>>>>> >>>>>>>>> other js code). But there is no way to do it with the
>>>>>>>>> current API, because <head>
>>>>>>>>> >>>>>>>>> or <body> could not have an id and without id, you can't
>>>>>>>>> insert. PartialResponseWriter
>>>>>>>>> >>>>>>>>> contains these methods:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> startInsertBefore(String targetId)
>>>>>>>>> >>>>>>>>> startInsertAfter(String targetId)
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> But note these two are useless, because what we need is
>>>>>>>>> insert "inside" at the beginning
>>>>>>>>> >>>>>>>>> or the end.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> For example:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> <head>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> <script .../>
>>>>>>>>> >>>>>>>>> </head>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> <body>
>>>>>>>>> >>>>>>>>> <script .../>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> </body>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Please note there are some cases where the jsf third
>>>>>>>>> party library (for example
>>>>>>>>> >>>>>>>>> primefaces) provides its own rules to to render the
>>>>>>>>> script at first, middle or last. But
>>>>>>>>> >>>>>>>>> in this case it doesn't matter those rules, because what
>>>>>>>>> we really need is that the
>>>>>>>>> >>>>>>>>> resource is added.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> The code that activates the flags to render head, body
>>>>>>>>> or form target is on
>>>>>>>>> >>>>>>>>> h:outputScript and h:outputStylesheet, specifically in
>>>>>>>>> the listener attached to
>>>>>>>>> >>>>>>>>> PostAddToViewEvent. This is the best place, because here
>>>>>>>>> is the place where
>>>>>>>>> >>>>>>>>> UIViewRoot.addComponentResource is done.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> I think what's really important in this problem is
>>>>>>>>> provide the API where you can notify
>>>>>>>>> >>>>>>>>> that the resource needs to be added. In MyFaces there is:
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> class RequestViewContext {
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> public boolean isRenderTarget(String target);
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> public void setRenderTarget(String target, boolean
>>>>>>>>> value);
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> }
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Which could evolve to something more complex, including
>>>>>>>>> the UIComponent instance and
>>>>>>>>> >>>>>>>>> so on.
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> I don't really like to do a list comparison, because it
>>>>>>>>> can introduce an unnecessary
>>>>>>>>> >>>>>>>>> performance overhead. I would like an API that could
>>>>>>>>> have some methods to register the
>>>>>>>>> >>>>>>>>> component for updated on the target and others to get
>>>>>>>>> the changes and do the necessary
>>>>>>>>> >>>>>>>>> calculation in PartialViewContext.processPartial(...)
>>>>>>>>> (render response).
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> regards,
>>>>>>>>> >>>>>>>>>
>>>>>>>>> >>>>>>>>> Leonardo Uribe
>>>>>>>>> >>>>>>>>
>>>>>>>>> >>>>>>>
>>>>>>>>> >>>>>>
>>>>>>>>> >>>>>
>>>>>>>>> >>>>
>>>>>>>>> >>>
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>
>