[Zope-Moz] PropertyView - The story so far

[Shalabh Chaturvedi]

Hi all:

This is a copy of a 'help!' message I had sent to the
netscape.public.mozilla.xpfe mailing list. I am reposting it here
so that everyone knows what we're upto.
Chris Waterson (from the mozilla team) has responded to this query. His
response is also appended.

If anyone has comments, suggestions or ideas - please let everyone know!

----- Original Message -----
From: Shalabh Chaturvedi <shalabh@pspl.co.in>
To: <mozilla-xpfe@mozilla.org>
Subject: Apps that dance with RDF and XUL
>
> Apps that dance with RDF and XUL - Part I : A Property Editor
>
> A Zope Object may have various properties of different types (string,
> boolean, text, selection, multiple-selection etc. ). Each property has
> a name and value - sometime more - for example a selection type
> property has a list of all possible values also.
> The user needs an interface to inspect and edit the properties.
>
> So I can have a URL for each object which returns the
> properties of the object in RDF. Now if I create a properties.xul with a
> <box> element containing a template and point the datasource of the box
> to the correct url - it should work. But wait - here come some issues:
>
> 1. Different types of properties need different widgets (boolean = checkbox,
>     string = textbox, text = textarea). How can this be done using the
>     datasource-template mechanism?
>
>     Options are:
>     a.  Use rule elements - one for each kind of property. This means
>          repeating
>          the common portion in each rule written. Also, how can a widget
>          with non-atomic values (html:select) be created? We don't have
>          'nested' templates.
>
>     b.  Use template to create many empty boxes. Put the property type, name
>          and value in attributes of the box. Call a js function onload to
>          'fill out' each boxes with the appropriate widgets using DOM.
>
>     c.  XBL. Use tempate to create empty boxes like in (b) but let XBL do
>          the hard work of filling out each box depending on the propertytype.
>          This has sevaral problems:
>          - Can't create a html:select widget with options
>          - Existance of an attribute ('selected' for checkbox) cannot depend
>            on
>            value ('true'/'false') of an attribute of the container box.
>
>          Clearly, something more than 'inherits' would be needed here.
>
>     Currently (b) is being used. It is the only option that works.
>
>
> 2.  How should a non-atomic property be represented in RDF ?
>      For example : The value of a selection property is one of
>      a specific set. The value of a multiple-selection is a subset
>      of a specific set. These map directly to <html:select> with
>      multiselect on or off..
>
>      Ideally (IMO) such properties should themselves be
>      RDF resources containing a sequence of nodes, each node
>      representing one possible value and having an attribute 'selected'
>      which is either true or false. Rendering such RDF as html:select
>      becomes impossible unless javascript is used to walk the RDF
>      graph (ouch!)
>
>      The current simple workaround is to keep the value as one string
>      which is a comma separated list. Another similar string is there
>      for the list of all possible values. These are easily 'split' using js
>      and converted to html:options using DOM calls.
>
> I'll stop here now. I may come up with more such stuff unless someone
> on this list reads this mail and shoots me for it.
>
> I believe similar issues may come up for many applications that may be built
> using mozilla.
>
> Comments and suggestions are welcomed.
>
> Thanks,
> Shalabh


What follows is the response from Chris. It has proved to be very helpful and
we're
investigating further.

----- Original Message -----
From: Chris Waterson <waterson@netscape.com>
To: Shalabh Chaturvedi <shalabh@pspl.co.in>
Cc: <mozilla-xpfe@mozilla.org>
> Shalabh Chaturvedi wrote:
>
> >     Options are:
> >     a.  Use rule elements - one for each kind of property. This means
> >          repeating
> >          the common portion in each rule written. Also, how can a widget
> >          with non-atomic values (html:select) be created? We don't have
> >          'nested' templates.
>
> ...but I think you should be able to do what you want with a single
> "flat" template that uses the (undocumented?) "parent" attribute. See,
> for example,
>
> http://lxr.mozilla.org/mozilla/source/xpfe/browser/resources/content/
> navigator.xul#272.
> The value of "parent" is matched against the enclosing content tag.
>
> > 2.  How should a non-atomic property be represented in RDF ?
> >      For example : The value of a selection property is one of
> >      a specific set. The value of a multiple-selection is a subset
> >      of a specific set. These map directly to <html:select> with
> >      multiselect on or off..
> >
> >      Ideally (IMO) such properties should themselves be
> >      RDF resources containing a sequence of nodes, each node
> >      representing one possible value and having an attribute 'selected'
> >      which is either true or false. Rendering such RDF as html:select
> >      becomes impossible unless javascript is used to walk the RDF
> >      graph (ouch!)
>
> Why? I think that the folks working on the browser's charset menu are
> facing a similar problem. Can't you just do something like:
>
>   <template>
>     <html:option selected="urn:whatever:am-i-selected" />
>   </template>
>
> And have the "urn:whatever:am-i-selected" property's value be the
> literal "true" or "false"?
>
> chris

Cheers,
Shalabh
____________________________________________
>>>  print reduce(lambda c,d:chr(ord(d)-2)+c,
     '>pk0qe0nrurBjdcncju>\"kfgxtwvcjE\"jdcncjU\014')
____________________________________________