[ome-devel] Re: OME GUI Development

[Josiah Johnston]

Michael and I have been talking about the Web search page. I'm moving 
the conversation to the list so others can have a chance to weigh in on 
these design decisions. I know how folks don't like being left in the 
dark.He implemented an extension that gives the user one search box to 
search through all the image fields. Then he put this search box on the 
Home page (see attached screenshot). His code is available at 
http://skyking.microscopy.wisc.edu/mike/ome.tar.gz

We're working out how to integrate this into the codebase. Michael's 
implementation does the search programatically. I spent an afternoon 
last week extending factory and DBObject to push this down to the 
database.
	my @images = $factory->findObjectsOpenSearch( 'OME::Image', 'search 
fragment' );
It searches through all the fields of image with an ilike operator, and 
appends wild cards to either end of the search fragment. The 
implementation is factory expands the search fragment into standard 
search terms, and passes them to DBObject's __makeSelectSQL, along with 
a flag to use 'OR' to join instead of 'AND'. That code is committed if 
anyone wants to know more details.

Michael suggested some tweaks to this. Once the interface to it settles 
down, we'll need corresponding functions to count and work with 
attributes. The second tweak involves the structure of the search. 
Michael would like to specify some fields and search across the rest. 
In his words:
I see that this could be valuable for a "Dr. Smith" who wants to see 
"Dr. Rodriguez"'s work on "spicule."  Now, Dr. Smith knows that Dr. 
Rodriguez has some images named "spicule," but he also has some other 
images that tie into "spicule", where the only evidence of that tie is 
in the description.  So, he can do a search of "spicule" in Dr. 
Rodriguez's data and bring up all relevant data.

I propose modifying the search interface to use a asterisk wildcard 
operator as a search field. This would amount to
	my @images = $factory->findObjects( 'OME::Image', '*' => 'spicule', 
experimenter => $dr_rodriguez );

This could be done with a fairly straightforward and minor change to 
__makeSelectSQL. Factory would blow up the search, then pass a separate 
list of or_parameters. The loop in __makeSelectSQL that iterate through 
all search parameters and puts together the join clause (line 2585 in 
CVS-HEAD) would pay attention to the or_paramerters and mark which 
entries of join_clauses are intended for or and which for and. Down 
where the SQL gets generated, this would be used to make a clump of 
'AND'ed paramerter and 'OR'ed parameters.
So the findObjects above would get translated to:
	Select ... from images ... where ( experimenter_id = 3 ) AND ( name 
ilike '%foo%' OR description ilike '%foo' OR ... ) AND ( [ACL 
clauses]);
If there were more than one structured search parameter, it would be 
AND'ed in the block with experimenter.

I think this keeps with the intention of factory to provide a simple 
search interface instead of replicating SQL.

Michael also wondered about wildcard search parameters reaching into 
other objects. Until recently, the search page has had text boxes for 
searching for many referenced object. A MEX's dataset for example.

Reference fields don't translate into text searches anymore. Instead 
Search makes a dropdown list if there are a few things to choose from, 
and gives a "select" link if there are many things to choose from. This 
was part of a complicated bug fix I did about a month ago.
	http://bugs.openmicroscopy.org.uk/show_bug.cgi?id=480
We had been talking about that change in behavior for a while, and it 
simplified the process of how to construct urls to the search page. The 
bug came about because Category's search page tied "Category" to a 
search path of "CategoryGroup.Name" and the URL construction method 
used by CategoryGroup's display page assumed "CategoryGroup".



For future work in search, IICBU needs to search based on metadata. 
Check out the attached diagrams of our driving example and the FISH 
search page. In the search template for that page,
	the gene box would be requested by <TMPL_VAR 
NAME="ImageProbeMapList.Probe.ProbeGeneMapList.Gene">
	the Probe type would be requested by <TMPL_VAR 
NAME="ImageProbeMapList.Probe.ProbeType.Name">
	the Probe type would be hardcoded by <input type="hidden" 
Name="ImageProbeMapList.Probe.ProbeType.Name" Value="anti-sense">
	the embryonic stage box would be requested by a line <TMPL_VAR 
NAME="ImageEmbryonicStageMapList.EmbryonicStage">

This requires extending the search framework to allow multiple 
templates to allow "FISH" in addition to "basic" and "advanced". If 
"basic" uses ids for reference fields, it remains easy to construct 
incoming links from elsewhere in the codebase.
This also means extending the parsing of the Search class.

Does anyone have other specific use cases to factor into design?

-Josiah

-------------- next part --------------
A non-text attachment was scrubbed...
Name: NewSearch.pdf
Type: application/pdf
Size: 107865 bytes
Desc: not available
Url : http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20051122/99cb1183/NewSearch-0001.pdf
-------------- next part --------------


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic2.pdf
Type: application/pdf
Size: 15696 bytes
Desc: not available
Url : http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20051122/99cb1183/pastedGraphic2-0001.pdf
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pastedGraphic4.pdf
Type: application/pdf
Size: 19005 bytes
Desc: not available
Url : http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20051122/99cb1183/pastedGraphic4-0001.pdf
-------------- next part --------------