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>*
>>>
>>>
>>
>