Kees Jongenburger <[EMAIL PROTECTED]> wrote: > > I think testing and time from the release manager are the two most import > > issues. > > Ok that would mean that we need to stop "developing" in mmbase 1.7 > and finish implementing the new features. >
> query project-> the searchquery has just made it to the bridge > we really need to be shure we are doing it the right way > > taglib2->do we want te wait for taglib 1.2 For me, these two are linked a bit now. I created the SearchQuery bridge implementation mainly to have the tool to progress the taglib further. I will start with 'listcontainer' tags soon. This will creating complex queries (search-forms and so on) with taglib easier. Also much-wanted features as the 'complete' size of a list (also 'outside' the list) and so on can be implemented. After that I would suggest to start with the 'related-nodes speedup', for which a query object would also be needed. These kind of things I would like to be finished before 1.7 release because they will give 'proof of concept' of the bridge version of SearchQuery. More advanced new ideas for taglib2 (tree-tag and so on) need not necessarily be finished before the release. If taglib2 is not completely finished when the release approaches, it will simply be feature-frozen for a while. The current bridge version of SearchQuery is very straight-forward and simple (perhaps a bit more so than we actually interconsented). For now I consider it only a begin, nearly still an experiment. It now works like this: 1. I added a 'Query' interface to the bridge. This one interface extends the 'SearchQuery' interface from org.mmbase.search. I did not name it 'SearchQuery' in the bridge too, because that would be very confusing (I foresee that often you would import org.mmbase.bridge.* as well as org.mmbase.storage.search.*) 2. I added 'BasicQuery' implementation to org.mmbase.bridge.implementation, which is a wrapper around a BasicSearchQuery object. 3. To the Cloud interface I added a 'Query createQuery()' function. 4. In the core you compose queries by doing a lot of 'new Basic-' constructors, and we decided that this is very 'un-bridge like', so we need a kind of 'factory' object for this. Just to keep things simple, I decided for now, that this factory object is the Query object itself. This is conventient too, because it has direct access to the 'BasicSearchQuery' which is modified (it is a member), so you need not pass it as an argument. So, inspired by the BasicSearchQuery implementation Query has functions like 'addStep(NodeManager)' etc. According to the interface such a function returns org.mmbase.storage.search.Step but actually it is a BasicStep from org.mmbase.storage.search.implementation. It seemed silly to copy the complete org.mmbase.storage.search.* interfaces to bridge. In practice this package now simply is a part of the bridge too. Also the implementation is not wrapped. This made it a lot simpler to made, but the disadvantage is that you can simply cast the result to a BasicStep and then have access to functions like getBuilder (which are core objects). I do not think this is a big problem, because if you really want to hack, it is no problem acquring core objects any way (org.mmbase.mode.core.MMBase.getMMBase()...) I suppose this principally could be protected by security managers. Of course you should not want this. So, for now the idea was that you need not 'modify' this kind of objects yourself, and that you create them right immediately, like e.g. query.addSortOrder(stepField, SortOrder.ORDER_ASCENDING); which is a bit different from the way of working in core. But is is still very similar. 5. Because I foresee that I would like to 'extend' queries, even after using it. (for the above-mentioned taglib improvements), I introcuded the following members in bridge.Query: boolean isUsed(); boolean markUsed(); Every atempt to modify a Query object after is has been marked 'used' will fail. This is because the result lists (of e.g. taglib) will remember a reference to the query object. (which perhaps has to be extended). Of course, then you should not change things in this object, because the result will then not accord with the query object any more. Also, Query object are used as cache keys in org.mmbase.cache.QueryResultCache, so you do not want them to be modified as soon as they are actually used as key. To extend a query then, you first need to 'clone' it, so in the Query object from bridge there is a method: Query clone(); Which is a deep copy, but still 'unused'. For this to implement I needed to make a copy-constructor in BasicSearchQuery. The SearchQuery/MMCI1.2/Taglib1.2 projects need decide what has to be changed in the above, _before_ the release of 1.7. Michiel -- Michiel Meeuwissen Mediapark C101 Hilversum +31 (0)35 6772979 nl_NL, eo, en_US mihxil' []()
