On May 25, 2008, at 8:18 PM, Artem Melentyev wrote:
> Hi, Vincent.
>
> Vincent Massol wrote:
>> 2) Only use the methods that you need now and add methods as they are
>> needed in the future. For ex if there's no need right now for named
>> queries we should probably not use it (Of course we should think
>> about
>> all use cases so that we have a solution should they arise).
> Ok
>
>> 3) Why do we still need a QueryPlugin? I don't think it's needed
>> anymore with the QueryManager. For me the Query Plugin should be
>> modified to be one of the Query implementation (HQL, XPath - this one
>> -, JCRSQL, etc).
>
> We need also some secure query (ex: QueryPlugin's xpath for
> Hibernate is
> secure, so it checks "query" right if query contains some non public
> fields), but yes, it can be some language in QueryManager.
see below.
>> 4) I'd really like that we try to remove any velocity-specific API so
>> that we have only 1 Java API for all. Maybe we can introduce some
>> velocity tools to handle the cases where you think it is required.
>> What would be those cases?
>
> Main issue are check rights for returned documents
We should probably have 2 Java APIs: one with restricted rights and
one with unrestricted rights. Some of our org.xwiki components will be
able to call the unrestricted rights api (we need to define how that
will work - security policy?). But this is not related to Velocity.
For example if, as a user, I write a new component I should only be
able to call the restricted rights API, unless I have some extra
rights set up or unless I modify the "container security policy".
> and shorter API (ex:
> QueryManager#xpath(""), Query#setParams(List)).
>
> We can expose QueryManager as the QueryPlugin (ex: xwiki.getQuery()
> returns QueryManager, without plugin api), add some shorter methods
> and
> protect #createQuery by our @Programming annotation.
I'd prefer that we don't add "shorter" methods (whatever that means -
I'm still unsure) but that we have pure Java API as if the API was
only called from Java.
However, in order to make it simpler from Velocity we could do 2 things:
* Offer some velocity tools for easier access.
* Possibility create some @velocity annotations or something that
would generate some velocity-based api in some cases where we could
not find a good way of doing it. However I'd like to start reviewing
the cases one by one to see if they can really not be called easily-
enough from Velocity.
>
> WDYT?
>
>> 5) Why do we need to write Language.HQL.name() and not Language.HQL?
>
> Because "Language" is Java5 enum, but QueryManager#createQuery require
> String (for adding new Languages without modify the Language enum).
> Ok. This is not good, so I propose to:
>
> public interface Query {
> static final String HQL = "hql";
> static final String XPATH = "xpath";
> ...
> }
btw you don't need static final in an interface ;)
Actually I wouldn't do it like this. Since we're now using components
I would create a Query interface and create each implementation as a
component. That component will be registered with a <role-hint> of
"hql", "xpath", etc.
Thanks
-Vincent
> And use qm.createQuery("...", Query.HQL);
> As well as in the JCR. (JCR don't use enums because targets at
> Java1.4)
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
