Leo,
Please see the updated API proposal in
https://java.net/jira/browse/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#getRendererTypeForResourceName(
>>> 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/browse/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.getClientId(_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/javaserverfaces-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/JAVASERVERFACES_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
>>>>>> >>>>>>>>
>>>>>> >>>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>
>>>>>> >>>>
>>>>>> >>>
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>