Hi Bauke,
thanks for reviewing! Great findings!
I already fixed 90%. Also if the other changes makes sense, i will talk
with Leo about it :)
Regards,
Thomas
2017-01-08 13:06 GMT+01:00 Bauke Scholtz <balusc_at_gmail.com>:
> Hi,
>
> I have reviewed the pull request https://github.com/
> javaserverfaces/mojarra/pull/4
> You can find my comments over there.
>
> In spite of the comments, which are mainly quality and technical related,
> the API itself looks good! Hopefully this will get into 2.3.
>
> Cheers, B
>
> On Fri, Dec 2, 2016 at 10:50 AM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>
>> Great, go ahead.
>>
>> Cheers B
>>
>> On Fri, Dec 2, 2016, 03:52 Leonardo Uribe <leonardo.uribe_at_irian.at>
>> wrote:
>>
>>> Hi
>>>
>>> There is a new exception called ComponentNotFoundException and a
>>> SearchExpressionHint to ignore id called IGNORE_NO_RESULT.
>>>
>>> The new algorithm is based on the previous discussion about 1372, so the
>>> expression can locate clientIds inside UIData instances (through
>>> invokeOnComponent). In fact, we mixed the proposal in primefaces with the
>>> recursive algorithm I designed to fix 1372.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2016-12-01 2:40 GMT-05:00 Bauke Scholtz <balusc_at_gmail.com>:
>>>
>>> Hi,
>>>
>>> Looks definitely good, but it's not clear to me how it solves 1372. Does
>>> it throw a clear exception when the expression does not resolve to
>>> anything, regardless of the context?
>>>
>>> Cheers, B
>>>
>>> On Thu, Dec 1, 2016, 08:11 Leonardo Uribe <leonardo.uribe_at_irian.at>
>>> wrote:
>>>
>>> Hi
>>>
>>> Basically the syntax to be included is the same there is in Primefaces.
>>>
>>> AT>> I haven't studied all the technical implications of the proposal
>>> yet,
>>> AT>> but the functionality itself it absolutely great to have!
>>>
>>> I'll describe it to make it easier to understand. Sorry if it is a bit
>>> repetitive, but the idea is to provide some text about it.
>>>
>>> In few words, the API is all about search for one or many components
>>> from a
>>> specified component instance and do something with it / them.
>>>
>>> For example in this case:
>>>
>>> <h:outputLabel for="@next" value="Name">
>>> <h:inputText id="name" value="#{bean.name}"/>
>>>
>>> h:outputLabel component requires to locate another component and to get
>>> the
>>> clientId to generate this html markup:
>>>
>>> <label for="mainForm:name">Name</label>
>>>
>>> Sometimes is just one component, sometimes there are many components:
>>>
>>> <h:commandButton ...>
>>> <f:ajax render="@next anotherPanel"/>
>>> </h:commandButton>
>>> <h:panelGroup id="detail" layout="block">
>>> ...
>>> </h:panelGroup>
>>>
>>> In this case f:ajax requires to get a list of clientIds or keywords that
>>> will
>>> be passed to jsf.ajax.request(...).
>>>
>>> In f:ajax case, there are some keywords that can be resolved on the
>>> client.
>>> For example, @form or @all. So, the algorithm to resolve clientIds must
>>> be able
>>> to resolve some clientIds and return the keywords that can be resolved
>>> in the
>>> client unchanged (passthrough expression). Later, jsf.ajax.request(...)
>>> will
>>> complete the job and retrieve the remaining clientIds inspecting the DOM
>>> tree.
>>>
>>> f:ajax "execute"/"render" is the most important case, but it is not the
>>> only one.
>>> In JSF there is invokeOnComponent(...) or visitTree(...), but both lack
>>> some
>>> flexibility, because there is no easy way to locate a component without
>>> know the
>>> clientId beforehand. Sometimes what the developer has is a "clue" that
>>> helps to
>>> identify the component(s).
>>>
>>> In "vainilla" JSF there are 4 known cases where this API is useful:
>>>
>>>
>>> - h:message "for"
>>> - h:outputLabel "for"
>>> - f:ajax execute and render
>>> - composite component "targets"
>>>
>>> In third party JSF component libraries we could found more cases and
>>> that's
>>> where we need help. The syntax proposed should cover these cases and the
>>> ones
>>> in Primefaces. But we need other examples to justify the "wildcard" case
>>> proposed by Bootsfaces, because what I have seen so far is @id(...)
>>> without
>>> wilcards is good enough. Maybe extend @id to receive multiple ids.
>>>
>>> To be more specific, @id uses a visitTree(...) call from the base to
>>> search
>>> for components that has the id passed as param. For example in this case.
>>>
>>> <h:form id="mainForm">
>>> <h:dataTable id="table">
>>> <h:column>
>>> <h:inputText id="name"/>
>>> </h:column>
>>> </h:dataTable
>>> </h:form>
>>>
>>> With the expression "@form:table:@id(name)", a visitTree(...) call
>>> from
>>> "table" is executed and then apply the action defined to each component
>>> with "name" id, which means it applies the action for every row.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> 2016-11-30 9:58 GMT-05:00 Cagatay Civici <cagatay.civici_at_gmail.com>:
>>>
>>> I agree, PrimeFaces users have been enjoying these alternative search
>>> options for a long time, glad to see it as a standard.
>>>
>>> Regards,
>>>
>>> Cagatay Civici
>>> PrimeTek
>>>
>>> On Wednesday, 30 November 2016 at 15:53, Josh Juneau wrote:
>>>
>>> The search expression API would be a very welcome addition to JSF, in my
>>> opinion. Using IDs in JSF has been a pain point for many, so I think this
>>> will be very well received.
>>>
>>> Josh Juneau
>>> juneau001_at_gmail.com
>>> http://jj-blogger.blogspot.com
>>> https://www.apress.com/index.php/author/author/view/id/1866
>>>
>>>
>>> On Wed, Nov 30, 2016 at 3:59 AM, arjan tijms <arjan.tijms_at_gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I haven't studied all the technical implications of the proposal yet,
>>> but the functionality itself it absolutely great to have!
>>>
>>> Thanks!
>>>
>>> Kind regards,
>>> Arjan Tijms
>>>
>>>
>>>
>>> On Tue, Nov 29, 2016 at 7:12 AM, Leonardo Uribe <leonardo.uribe_at_irian.at
>>> > wrote:
>>>
>>> Hi Kito
>>>
>>> KM>> Leonardo, this looks awesome. One question, though: what about
>>> wildcard
>>> KM>> / partial id matching? I'm surprised that is missing.
>>>
>>> The current proposal does not have it.
>>> Please take a look at this link:
>>>
>>> http://www.beyondjava.net/blog/jsf-vs-primefaces-vs-bootsfac
>>> es-search-expressions/
>>>
>>> Primefaces implementation does not have a wildcard like this. It has
>>> something
>>> like @id(...) that matches the components with the id defined using a
>>> visitTree
>>> call.
>>>
>>> In the link, Bootsfaces propose some wildcards like **:id* or
>>> @findIdRecursive(id),
>>> With the current API proposal, you can create your own keywords. The
>>> idea could
>>> be create a custom keyword that allows wildcard / partial id matching or
>>> extend
>>> @id(...) keyword to allow complex cases.
>>>
>>> It is not hard to implement a wildcard system, but we need a good syntax
>>> and
>>> some good examples where this can be useful. Until now, I have not found
>>> examples or use cases and I only have the previous link, so it could be
>>> great
>>> if another expert could propose a good syntax for this part.
>>>
>>> The code has been already committed in MyFaces:
>>>
>>> http://svn.apache.org/repos/asf/myfaces/current23/
>>> http://svn.apache.org/repos/asf/myfaces/core/branches/2.3.x/
>>>
>>> and Thomas Andraschko is reviewing it to include it in Mojarra.
>>>
>>> Suggestions are welcome.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>> 2016-11-28 7:08 GMT-05:00 Kito Mann <kito.mann_at_virtua.com>:
>>>
>>> Leonardo, this looks awesome. One question, though: what about wildcard
>>> / partial id matching? I'm surprised that is missing.
>>>
>>>
>>> On Wed, 16 Nov 2016 at 22:09 Leonardo Uribe <leonardo.uribe_at_irian.at>
>>> wrote:
>>>
>>> Hi
>>>
>>> As some of you already know, Thomas Andraschko from PrimeFaces team and
>>> I have been working in a API that allows JSF developers to search
>>> components using an expression like the one proposed by PrimeFaces here:
>>>
>>> http://blog.primefaces.org/?p=2740
>>>
>>> This mail is to give the EG an idea about how this API could work and
>>> check if
>>> everything has been covered from spec perspective.
>>>
>>> The issues in the spec that this feature will fix are:
>>>
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1238
>>> Enhance component referencing / findComponent
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1200
>>> Search parent naming containers for component
>>>
>>> Some issues that are closed by different reasons, but are related:
>>>
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1372
>>> f:ajax doesn't validate client ID anymore - confusing to starters
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-567
>>> Clarify f:ajax execute/render id behavior (closed as fixed, but for me
>>> it is not)
>>> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1080
>>> New Component APIs to manage EL context as it applies to components.
>>>
>>> The list of cases where this could be useful are (changes must be done
>>> in
>>> these points):
>>>
>>> - h:message "for"
>>> - h:outputLabel "for"
>>> - f:ajax execute and render
>>> - converter and validator "for".
>>> - composite components "for"
>>>
>>> There is a table comparing the search expressions available by some
>>> frameworks
>>> on this link:
>>>
>>> http://www.beyondjava.net/blog/jsf-vs-primefaces-vs-bootsfac
>>> es-search-expressions/
>>>
>>> The intention is standarize a subset of the proposal there.
>>>
>>> The idea is the algorithm must comply with the following:
>>>
>>> - Support the following keywords by default: @child, @composite,
>>> @form, @namingcontainer, @next, @none, @parent, @previous,
>>> @root, @this and @id
>>> - Remember @all is valid for f:ajax and it is embedded in
>>> PartialViewContext implementation. So @all return the top level
>>> component (UIViewRoot) in other cases.
>>> - It should be possible to reference a component inside UIData
>>> instances.
>>>
>>> The syntax to support is this:
>>>
>>> <clientId>
>>> :<id>
>>> <id>:<id>:<id>
>>> @<keyword>:<id>
>>> id:@<keyword>
>>> @<keyword>(<param1>)
>>> @<keyword>(<param1>,<param2>)
>>>
>>> Some examples of possible expressions:
>>>
>>> @this
>>> @next
>>> @previous
>>> @form:name
>>> @namingcontainer:age
>>> @parent:@id(msgName)
>>> mainForm:table:3:baseText
>>> mainForm:table:3:nested:1:nestedText
>>>
>>> It is possible to create custom keywords to extend the default algorithm
>>> in
>>> a similar way ELResolver works using this class:
>>>
>>> public abstract class SearchExpressionResolver
>>> {
>>>
>>> public abstract void resolve(SearchKeywordContext expressionContext,
>>> UIComponent last,
>>> String command);
>>>
>>> }
>>>
>>> The main entry point is SearchExpressionHandler and contains the
>>> following methods:
>>>
>>> public abstract String resolveClientId(
>>> SearchExpressionContext searchExpressionContext, String
>>> expressions);
>>>
>>> public abstract List<String> resolveClientIds(
>>> SearchExpressionContext searchExpressionContext, String
>>> expressions);
>>>
>>> public abstract void resolveComponent(
>>> SearchExpressionContext searchExpressionContext, String
>>> expression,
>>> ContextCallback callback);
>>>
>>> public abstract void resolveComponents(
>>> SearchExpressionContext searchExpressionContext, String
>>> expressions,
>>> ContextCallback callback);
>>>
>>> public abstract String[] splitExpressions(String expressions);
>>>
>>> In faces-config.xml this should be possible:
>>>
>>> <application>
>>> <search-expression-handler>my.custom.SearchExpressionHandler
>>> Impl</search-expression-handler>
>>> </application>
>>>
>>> One new factory will be added:
>>>
>>> <factory>
>>> <search-expression-context-factory>....</search-expression-
>>> context-factory>
>>> </factory>
>>>
>>> And that's it.
>>>
>>> If anyone has a suggestion for improve the syntax, or some comment
>>> related to
>>> this topic, it is a good time to say something. Thanks for your
>>> attention.
>>>
>>> regards,
>>>
>>> Leonardo Uribe
>>>
>>>
>>> --
>>> ___
>>>
>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>> Web Components, Polymer, JSF, PrimeFaces, Java EE, and Liferay training
>>> and consulting
>>> Virtua, Inc. | virtua.tech
>>> JSFCentral.com | @jsfcentral | knowesis.io
>>> <http://knowesis.io/web/webcomponents> - fresh Web Components info
>>> +1 203-998-0403
>>>
>>> * See me speak this December in Orlando at Live! 360:
>>> http://bit.ly/LSPK52_Home
>>> * Listen to the Enterprise Java Newscast: *http://
>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>> <http://ww.enterprisejavanews.com>*
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>