[Silva-general] navigation by tags/metadata

bdsilva at knowledgeworks.plus.com bdsilva at knowledgeworks.plus.com
Mon Dec 7 20:29:49 CET 2009


Hi Wim and Andy

As Andy's response is a comment to Wim's I hope you don't mind if I
respond to them both here.  Thanks to both of you for your suggestions.

Andy wrote:
> I don't think Wim's suggestion is quite
> what you're looking for.

I'm trying to think through what might be missing from Wim's suggestion. 
Saving the search results is an unusual idea for me, but now that I've
heard of it, it seems logical.  However, I can't see how one would save
the search results page to display as a list of documents within a
category. Unless it means having hyperlinks that call the URL I see when
I've clicked on the 'search' button from the interface created by the
SilvaFind object (i.e. kind of like submitting the search for the user, so
that they do not need to fill out the search terms within the SilvaFind
object).

> Your thoughts of using a SilvaMetadata field are
> right on target. The challenge is knowing your taxonomy ahead of time.  If
> you
> want a flat taxonomy (e.g. starters has a list of recipes) and not a
> hierarchical taxonomy (e.g. starters > chicken > chicked quesadillas) then
> it's much simpler to implement.  With SilvaMetadata, it will be a
> challenge to
> implement a hierarchical taxonomy -- it would be possible, but a new type
> of
> SilvaMetadata element (and Formulator Field / Widget) would be required.

For the moment I'm thinking of this keyword navigation as supplemental to
a traditional hierarchical navigation.  It may well end up being the
primary navigation, but I can see I might want to offer the traditional
folder/document navigation too.

> What I would suggest is this:
>
> Establishing the alternate taxonomy:
>
> 1) if your flat taxonomy is known, create a new silva metadata set and add
> an
> element using a formulator listfield.  Editing the list field, add your
> flat
> list to it.  Make sure the element is indexed, probably using a keyword or
> field index.  If a content object can be associated with multiple names in
> the
> taxonomy, then use a MultiListField.
>
> 2) in service_metadata/ct_mapping/manage_workspace, add the new metadata
> set
> to the desired Silva content types
>
> 3) now in the SMI properties tab for you will be able to add values for
> this
> metadata field to each object

Thanks for the above suggestion.  It will ensure consistency in adding the
searchable metadata to the content objects.  I hadn't realised something
like that was possible.  I suspect that there you are suggesting
establishing the taxonomy beforehand for other reasons though (see
'petrification' below).

> Generating a menu based on this taxonomy:
>
> Depending on which technology you are using for your layouts (SilvaLayout
> or
> the old-style using the ZMI-based index_html/layout_macro, etc)  this will
> be
> slightly different.  Because of this I won't suggest any code for you, but
> I
> will outline what you need to you.

So far, I'm not using SilvaLayout, as by default Silva seems to be using
index_html/layout_macro.  I will do some reading around SilvaLaout and see
if it is going to be more appropriate for my skill level and needs. Am I
right in thinking that SilvaLayout is about doing layout in a way that is
more in the style of Zope3?

> In your layout, in addition or as a replacement to the standard navigation
> links, you will put in place rendering code for your alternate taxonomy.
> You
> will need to have a page template and some helper python code.  The page
> template will use the helper python code to get the flat taxonomy list.
> For
> each name in the taxonomy, you will get query the silva catalog for all
> objects having that name for the value of the new taxonomy metadata field.
> You will then loop over these objects in your pt, rendering a link for
> each.

Again, thanks for that.  I'm not very clear on the use of the Catalog
within Silva.

> There will be a challenge to sustaining this taxonomy.  There is no
> facility
> in SilvaMetadata to allow fields containing a strict list of values (i.e.
> a
> List or MultiList) to change over time.  Once a content object is
> associated
> with a value, you cannot remove or rename that value without first
> removing
> the association.

Am I right in thinking that the above petrification between the metadata
and the content object is a feature of the fact that the content objects
(and their metadata) are published.  That is, if one was to update the
metadata one would need to re-publish the content object?

> Please share if you figure this out.  As I said, this is something we've
> been
> interested in.

Andy, I'll be delighted to share anything I can.  But it is going to take
me some time to get up to speed with Silva.  I'm very impressed by it, and
the initial documentation is good, but there's a lot more to learn.  I
think that I'm only scratching the surface.

Regards, Bernard





More information about the silva-general mailing list