Currently, if we want to add a new control to the advanced search, we
have to add a control class, an expression class, and modify
info.magnolia.cms.gui.controlx.search.QueryBuilder. We shouldn't
have to
modify an existing class to add a new control.
In the pro version of the DMS (talking about 3.0 here). You can
define additional controls in the dialog definition of the documents
dialog. You can mark any matadata as searchable. If no special
rendering is needed (text, select, date are supported) you should not
need to extend any kind of class.
But if you add special new kind of controls (you are talking about
that if I understood you right), it can get tricky.
Proposed Solution:
I've been looking over the advanced search components and think the
search could be implemented better by dumping most of
info.magnolia.cms.gui.controlx.search.QueryBuilder. Instead, an
Interpreter design pattern could be implemented by adding a
getSQLStatement() (or another method that returns a serialized SQL
version of the expression object) to the SearchQueryExpression
interface.
Then, the build(SearchQueryExpression) method of QueryBuilder would
just
iterate over the SearchQueryExpressions to build the SQL statement.
This is more or less what we did already. The form builds the
expression consulting the controls:
for (Iterator iter = this.getChildren().iterator();
iter.hasNext();) {
SearchControl control = (SearchControl) iter.next();
SearchQueryExpression expr = control.getExpression();
if(expr != null){
expressions.add(expr);
}
}
The expression returned can be any complex construct. We look at this
as a metasearch definition as you proposed. Then any kind of
interpreter can take the expression to process. It is the
responsibility of the list to execute this query.
Since we made the later part in a hurry it can be that we missed
parts like the search for integer values. Therefore I think we should
better refactor this QueryBuilder (meant to interpret the expression
to a jcr query) and to finalize the primer set of expressions (text,
integer, date). Sure the QueryBuilder and it's use should be
extendable just in case, but it makes sense to restrict the set of
atom expressions to the set supported by jcr.
Resolution:
If we wanted to add a new kind of search control, such as a popup to
pick price ranges on products, we could just write the
SearchControl and
SearchQueryExpresion implementation and be done.
The control can already return this kind of expression: price > x and
price < y.
I may be making some enhancements to the advanced search over the next
few weeks and would contribute a fix that does this back, if anyone
else
is interested.
Would be cool if you could work on the latest code (will send you the
pro part of the code). A better implementation of the QueryBuilder is
very welcome. But the concept is:
- The form builds the metaquery asking the controls to build the
metatquery (expressions)
- The list model takes the metaquery and executes it
- The QueryBuilder is used by the RepositorySearchListModel (the jcr
implementation)
Regards,
Philipp Bracher
obinary ltd.
-----------------------------------------------------
[EMAIL PROTECTED] http://obinary.com
magnolia content management http://magnolia.info
-----------------------------------------------------
----------------------------------------------------------------
for list details see
http://www.magnolia.info/en/magnolia/developer.html
----------------------------------------------------------------
