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-bootsfaces-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-bootsfaces-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.SearchExpressionHandlerImpl</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>*
>
>
>
>
>
>
>
>