[ 
https://issues.apache.org/jira/browse/CXF-4221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250582#comment-13250582
 ] 

Sergey Beryozkin commented on CXF-4221:
---------------------------------------

Hi, thanks for this effort, here are some comments. 

In the code example, SearchContext is completely bypassed, 
searchContext.getSearchExpression() is a utility method which is indeed can be 
handy but it's effectively the same as providing a JAX-RS QueryParam("_s"). The 
idea behind SearchContext (and SearchCondition + SearchConditionVisitor) is to 
completely hide the fact it is a FiqlParser that is being used to parse a given 
search expression, this way it is possible to transparently manage different 
search languages, something different to FIQL for example.

To be honest, I do not see why FiqlParser should depend on 
"javax.persistence.criteria CriteriaBuilder,
Predicate, Root".

I'm interested in exploring the new options for making the Search extension be 
more useful, but I'd like us to think of different options.

First let me suggest that we do not deal with the nested properties, which 
require the use of beanutils, it is a different issue altogether, so we can 
return to it later on.

The issue at hand is how to make it easier to adapt the search expressions to 
JPA handlers (CriteriaBuilder, Predicate, Root, etc) but *without* having to 
introduce the javax persistence dependencies directly into the FIQL parser, 
rather I'd prefer to introduce something like JPACriteriaVisitor or something 
like that.

SearchConditionVisitor has a 'getResult()' method returning String.
JPACriteriaVisitor may have this method unimplemented but offer it's own
getPredicate() method and be initialized with CriteriaQuery<Merchant> & Root, 
etc.

Can you consider prototyping such a visitor ? After that it will be easier for 
me to see what can be pushed to the core Search code to simplify the code for 
the JPA visitor


                
> FIQL visitor to return a generic <K> instead of String
> ------------------------------------------------------
>
>                 Key: CXF-4221
>                 URL: https://issues.apache.org/jira/browse/CXF-4221
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>            Reporter: Szu-Yu Wang
>         Attachments: FiqlParser.java
>
>
> It would be great if SearchConditionVisitor<T, K> where K was the return type 
> of the getResult() call.  This way, I can CriteriaQuery<T> instead of String.
> Also, incidentally, the operation isn't "getResult", it's more like 
> "getPredicate" or "getFilter"...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to