Rolf Kulemann wrote:
Hello,
I set up a small cocoon app which uses the Repository interface. I'm now up to a point where would use a kind of property query in order to receive all resources/paths matching the query.
Currently the repository does not support a property "search" method.
IMHO this is an important feature and should be a concern of the RepositoryPropertyHelper.
Another question is, what kind of queroes should be supported? DASL queries???
Oh, queries... well, I really appreciate your enthousiasm, but my advice is not even dare to think that querying is going to be solved just by an email thread. JSR170 people have been fighting over it quite a while, and overall searching is _really_ a PITA.
Besides, DASL isn't really a query language but rather a query wrapper: you're free to insert whatever query language you want (DAV:basicsearch being the most prominent one) inside DASL (which boils also to an HTTP method + a bunch of headers).
Consider also that it's not just the query language, but even how results are reported.
MHO? I really feel uncomfortable with the repository abstraction as a whole since, after all, it has to be somehow modeled into webdav. I'm fine with it as long as it's lightweight enough, but for more serious needs I'd much rather wait for JSR170 to come out.
Hmm, I'm also looking forward to JSR170. Don't you think there is place for wrappers/abstractions of higher level (better mapping to Cocoon concepts)?
I think/hope the repository is not modeled after WebDAV-only and may account for JSR170 as well.
However it shouldn't be modeled after JSR170-only either (in which case you would be better off just dropping in the JSR170impl.jar) as the major point is to be simple to use from the flow layer and based around some higher level concepts such as (XML?) documents.
Yes, it should be leightweight. I didn't think of incorporating searching as this seems to be better covered by a different component.
Please don't consider it another approach but rather an expansion of the SourceRepository interface (which may be merged in at some point). I thought of having some samples operating on this component (and maybe others), that may easily be "ported" to other repositories.
If JSR170 becomes Cocoon's one and only interface to repositories (of all sizes and needs) then this particular component may be mostly redundant as having a portability layer becomes pointless.
Guido
--
Guido Casper
-------------------------------------------------
S&N AG, Competence Center Open Source
Tel.: +49-5251-1581-87
Klingenderstr. 5 mailto:[EMAIL PROTECTED]
D-33100 Paderborn http://www.s-und-n.de
-------------------------------------------------