I'm trying to duplicate the search engine approach used on the Zope.org site, find the /view_source a wonderful tool for poking about. [1] Some areas I'm having trouble on are the metadata and index fields used in DTML that accesses the SiteIndex zcatalog object. They use search fields like 'date', 'url', 'title_or_id' and 'text_content' which don't exist in a default zcatalog instance. I can add them via the management interface and re-catalog the site but nothing ever shows up in those index fields. Is Zope.org using some pluggable-brain technology to wrap a zcatalog and provide these attributes on normal, unchanged objects like DTML Documents and DTML Methods? [2] When I provide a searchForm (using Z Search wizard) that invokes a search DTML method wherein I call searchResults(REQUEST=REQUEST), it seems that searchResults() uses too much from REQUEST, pulling in default/invalid values for fields that the user decided not to supply, say not picking a meta_type from a drop-down list or leaving the date_usage value to 'modified since ever'. This causes searchResults() to return every item in the zcatalog, since -every- item has been modified since 'ever'. ;-) [3] I see in the Python source that I can invoke Python methods to wrap/assign a pluggable-brain class to a catalog -- is there a way to do this via DTML, or at least via the management interface so I can define the brain to use when I initially create the catalog instance? [4] The Zope.org site uses a sort_link() method in the SiteIndex search method, but I cannot find it anyplace on Zope.org. Is it an external method I can't reach? It seems a simple enough method that constructs links on the column headings to allow a user to re-sort the records on different columns. It's worth a HOW-TO. [5] There is also an icon_for_meta_type method in the SiteIndex container that maps a meta_type string to the appropriate icon. It uses an explicit if-then list for this however, meaning that when new products are added to a site, their icons won't get picked up. To avoid the messiness of such, can we get a new method added to the next Zope release that globally maps any meta_type to whatever icon the management interface would use for that type? HE knows what icon to use, even for the OFSP product. [6] When I catalog the DTML Documents/Methods on my site, the textindex of the PrincipiaSearchSource value (the DTML source) is difficult to use because it takes the DTML source rather literally i.e. if I have <B>C++</B>, that is parsed and indexed as a single word, so searches for "C++" won't find it (at least that's what my tests seem to indicate). I suppose one solution is to define a PrincipiaSearchSource method for my objects that somehow filters out the xTML and returns just the raw text, but how can I do that for existing types like DTML Document/Methods? -Jeff Rush
Jeff Rush <jrush@timecastle.net> travelled for many days to ask:
I'm trying to duplicate the search engine approach used on the Zope.org site, find the /view_source a wonderful tool for poking about.
[1] Some areas I'm having trouble on are the metadata and index fields used in DTML that accesses the SiteIndex zcatalog object. They use search fields like 'date', 'url', 'title_or_id' and 'text_content' which don't exist in a default zcatalog instance. I can add them via the management interface and re-catalog the site but nothing ever shows up in those index fields. Is Zope.org using some pluggable-brain technology to wrap a zcatalog and provide these attributes on normal, unchanged objects like DTML Documents and DTML Methods?
No, it is a completely plain-jane ZCatalog. Those are external methods. In the cases of the Z Classes, they are members of the class. Vanilla Zope objects like DTML Documents are acquiring those methods from a parent folder.
[2] When I provide a searchForm (using Z Search wizard) that invokes a search DTML method wherein I call searchResults(REQUEST=REQUEST), it seems that searchResults() uses too much from REQUEST, pulling in default/invalid values for fields that the user decided not to supply, say not picking a meta_type from a drop-down list or leaving the date_usage value to 'modified since ever'. This causes searchResults() to return every item in the zcatalog, since -every- item has been modified since 'ever'. ;-)
I'm not sure I understand. Are you saying that even if the user fills in some text to search for, if 'modified since ever' is part of the criteria it will return all objects in the catalog? That is not the way it aught to work. Make sure the name of the body text input tag on your form is typed correctly. If you mean you get all objects in the database when you hit 'submit' before filling _anything_ in, well, yes. That's the way it aught to work. If you don't like that behaviour, you'll have to catch it in the search results page.
[3] I see in the Python source that I can invoke Python methods to wrap/assign a pluggable-brain class to a catalog -- is there a way to do this via DTML, or at least via the management interface so I can define the brain to use when I initially create the catalog instance?
I don't think so, not at the moment. I'm pretty sure it has to be done from Python.
[4] The Zope.org site uses a sort_link() method in the SiteIndex search method, but I cannot find it anyplace on Zope.org. Is it an external method I can't reach? It seems a simple enough method that constructs links on the column headings to allow a user to re-sort the records on different columns. It's worth a HOW-TO.
Amos wrote this. I think it's really keen. I haven't looked at how it works yet, but I want to. A How-to would be a good excuse. I think I'm way overdue to write one anyway.
[5] There is also an icon_for_meta_type method in the SiteIndex container that maps a meta_type string to the appropriate icon. It uses an explicit if-then list for this however, meaning that when new products are added to a site, their icons won't get picked up. To avoid the messiness of such, can we get a new method added to the next Zope release that globally maps any meta_type to whatever icon the management interface would use for that type? HE knows what icon to use, even for the OFSP product.
I agree, it would be very handy. It'll be more likely to show up in a future release if you file a feature request with the Collector: http://www.zope.org/Resources/Collector
[6] When I catalog the DTML Documents/Methods on my site, the textindex of the PrincipiaSearchSource value (the DTML source) is difficult to use because it takes the DTML source rather literally i.e. if I have <B>C++</B>, that is parsed and indexed as a single word, so searches for "C++" won't find it (at least that's what my tests seem to indicate). I suppose one solution is to define a PrincipiaSearchSource method for my objects that somehow filters out the xTML and returns just the raw text, but how can I do that for existing types like DTML Document/Methods?
You will have to index a different attribute. I don't think you'll be able to override DTML Document/Method's PrincipiaSearchSource. You can create an external method in the root of your Zope server called something like 'filtered_body', which returns self.PrincipiaSearchSource with all the tags stripped out.
-Jeff Rush
Have fun, Mike.
participants (2)
-
Jeff Rush -
Mike Pelletier