Hi,
i corrected everything, so it should be fine now :)
I even removed a SearchExpressionHint, which is not required actually.
So please proceed with reviewing/merging.
Thanks!
Regards,
Thomas
2017-01-08 15:15 GMT+01:00 Thomas Andraschko <andraschko.thomas_at_gmail.com>:
> 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/javaserverf
>> aces/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-c
>>>> ontext-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>*
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>