cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-4221) FIQL visitor to return a generic <K> instead of String
Date Tue, 10 Apr 2012 11:55:19 GMT

    [ 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

        

Mime
View raw message