Excellent. It's good to hear that you've already started to deal with the issue.
Unfortunately, it's difficult for me to work with the very latest code as we're still stuck in 2.1.5 land. We're not changing until after 3.0 Enterprise is available, though if you guys are interested, we'd be happy to help alpha/beta test the Enterprise version---which might also expedite some of our development to 3.0, in general. We're really interested in OWFE and the portal features. It's our intention that as soon as Magnolia 3.0 comes out and we get the ground work laid, to start contributing our improvements back. We'd really like to increase the value of Magnolia through our contribution. Cheers, Andrew -- Andrew Sterling Hanenkamp Interaction Developer Boomer Consulting, Inc. [EMAIL PROTECTED] 1-785-537-2358 x17 1-888-266-6375 x17 610 Humboldt St. Manhattan, KS 6502 http://www.boomer.com -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 06, 2006 2:46 AM To: [email protected] Subject: Re: [magnolia-dev] Enhancing the advanced search > 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 ---------------------------------------------------------------- ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
