[OpenAjaxIDE] Nesting <properties> re-visited ...

Jon Ferraiolo jferrai at us.ibm.com
Mon Sep 14 09:36:12 PDT 2009


I am actually glad that this issue is (re-)opening. Over here at IBM, we
are working on a project that implements the OA Widget spec and has a
property editor pane. We are right in the middle of these issues.

One key problem that the IBM folks are having is that the tool wants to
have final say on how properties are grouped within the property editor
pane, not the widget. This is because sometimes you want to provide a
consistent look in the property editor pane across multiple widgets, where
particular properties always appear within a particular area in the
property editor pane. To make this concrete, suppose you have widgets A and
B, where A shows two properties (color, font) and B shows the same two
properties, except in a different order (font, color). It will not be a
good experience for the user if color and font appear in different order
depending on the widget.

There are more complex scenarios involving grouping. Suppose widget A
defines two groups, Basic (which includes color) and Styling (which
includes font), but widget B defines a single group, Common (which includes
both font and color). It will be confusing to the user that different
widgets use different groups for the same type of property.

My proposal is to re-use the <category> element, with the double-colon
syntax, but without property nesting:

*
http://www.openajax.org/member/wiki/OpenAjax_Metadata_1.0_Specification_Widget_Metadata#category_element


For example:.

<widget>
  <property name="font">
    <category name="Basic::Text"/>
  </property>
  <property name="color" format="color">
    <category name="Basic::Text"/>
  </property>
</widget>

The advantages of this approach:

(1) The widget can define its preferred groupings and orderings for
properties so that it is possible for tools to honor the
groupings/orderings, but it is also possible for tools to override and
thereby organize and group as the tool developer thinks is best.

(2) It is possible to define multiple categories for the same property.
Perhaps some tools have a "Basic" category and others have a "Common"
category. It would be best if the industry could agree on Basic vs Common,
but in case they don't, it would be good to provide an option for a
property to include both a <category name="Basic"/> and a <category
name="Common"/> sub-element.

(3) This approach allows for namespaced categories. For example, maybe
Dreamweaver could define a "Dreamweaver::" prefix which allows a widget to
include a Dreamweaver-specific <category> element. For example, <category
name="Dreamweaver::Basic::Text"/>

(4) The approach allows us to leverage the OpenAjax wiki or OpenAjax
Registry (I'm really going to do finish that some time!) to define some
industry standard categories.

Kin points out the need for a label feature on categories. Perhaps we need
to add a <label> child element to <category>, just like we did for
<option>.

Jon



                                                                                                                               
  From:       Bertrand Le Roy <Bertrand.Le.Roy at microsoft.com>                                                                  
                                                                                                                               
  To:         Lori Hylan-Cho <avocadoh at gmail.com>                                                                              
                                                                                                                               
  Cc:         "ide at openajax.org" <ide at openajax.org>                                                                            
                                                                                                                               
  Date:       09/13/2009 05:15 PM                                                                                              
                                                                                                                               
  Subject:    Re: [OpenAjaxIDE] Nesting <properties> re-visited ...                                                            
                                                                                                                               
  Sent by:    ide-bounces at openajax.org                                                                                         
                                                                                                                               





Having complex or nested properties is a different thing from grouping
properties by category. A property category is not a property.

From: Lori Hylan-Cho [avocadoh at gmail.com]
Sent: Sunday, September 13, 2009 3:51 PM]
To: Bertrand Le Roy
Cc: Kin Blas; ide at openajax.org
Subject:; Re: [OpenAjaxIDE] Nesting <properties> re-visited ...

I agree that proposal #2 is simpler when there's only one level of nested
categories, but Kin's example (both the hypothetical one in his email and a
couple real-world ones we looked over) had more than one level. In that
case, nesting <properties> tags is simpler to understand, IMHO.

On Thu, Sep 10, 2009 at 10:21 PM, Bertrand Le Roy <
Bertrand.Le.Roy at microsoft.com> wrote:.
  The second (group-based) approach is what exists in Visual Studio: there
  is only one level of nested categories so that's sufficient and much
  simpler.

  -----Original Message-----
  From: ide-bounces at openajax.org [mailto:ide-bounces at openajax.org] On
  Behalf Of Kin Blas
  Sent: Friday, September 04, 2009 2:36 PM
  To: ide at openajax.org
  Subject: [OpenAjaxIDE] Nesting <properties> re-visited ...

  I noticed that the "::" approach for an alternate approach to nesting
  <properties> was added to the 1.0 spec:


  >> Some tools may have multiple levels of tabs within a property editor.
  >> For example, perhaps there will be a first-level tab which shows
  "Basic"
  >> properties, and then a sub-tab within the "Basic" tab for "Sizing"
  >> properties. The recommended convention for identifying hierarchical
  >> property groups is to use a double-colon sequence ("::") as the token
  >> separate string. For example, name="Basic::Sizing".


  This was a suggestion I made while trying to work with "what we have" and
  avoid introducing new attributes since we are trying to wind down the 1.0
  spec, and avoid introducing our own vendor-namespaced attributes into OAM
  files to enable this feature. One problem we still have with this
  approach, is that we still need the concept of a label to express the
  relationships to the end-user. This requires us to add a @label attribute
  or <label> child anyways. Since we need an extra attribute anyways, I
  would rather see formal metadata semantics introduced to support nesting
  properly and pull the suggestion of the '::' convention from the 1.0 spec
  so we don't get stuck with having to support it forever once we declare
  OAM 1.0.

  We have 2 proposals we'd like to put forth for consideration for the next
  revision of the spec. The first is to actually allow the nesting of
  <properties> tags and introduce the @label attribute for <properties>:


         <properties name="A" label="##A##">
                 ...
                 <properties name="B" label="##B##">
                         ...
                 </properties>
                 <properties name="C" label="##C##">
                         ...
                 </properties>
                 ...
         </properties>

         <properties name="D" label="##D##">
                 ...
                 <properties name="E" label="##E##">
                         ...
                 </properties>
                 <properties name="F" label="##F##">
                         ...
                 </properties>
                 ...
         </properties>


  In this proposal, there is no limit to the nesting level of <properties>.

  If folks don't like this approach, an alternate would be to keep the
  flattened <properties> approach, but introduce the @label attribute, as
  well as a @group attribute that allows you to group one or more
  properties underneath a specific named <properties> element:


         <properties name="A" label="##A##">
                 ...
         </properties>
         <properties name="B" label="##B##" group="A">
                 ...
         </properties>
         <properties name="C" label="##C##" group="A">
                 ...
         </properties>
         <properties name="D" label="##D##">
                 ...
         </properties>
         <properties name="E" label="##E##" group="D">
                 ...
         </properties>
         <properties name="F" label="##F##" group="D">
                 ...
         </properties>


  In this scenario, the value of the @group attribute is the @name of the
  <properties> tag it should be nested underneath. There is no limit to the
  grouping, so if you really wanted to express a nesting of A>B>C>D>E>F, it
  would look something like this:


         <properties name="A" label="##A##">
         ...
         </properties>
         <properties name="B" label="##B##" group="A">
         ...
         </properties>
         <properties name="C" label="##C##" group="B">
         ...
         </properties>
         <properties name="D" label="##D##" group="C">
         ...
         </properties>
         <properties name="E" label="##E##" group="D">
         ...
         </properties>
         <properties name="F" label="##F##" group="E">
         ...
         </properties>


  Thoughts? Is there a place to put proposals like this?

  --== Kin ==--

  _______________________________________________
  IDE mailing list:
  IDE at openajax.org
  http://openajax.org/mailman/listinfo/ide


  _______________________________________________
  IDE mailing list
  IDE at openajax.org
  http://openajax.org/mailman/listinfo/ide
_______________________________________________
IDE mailing list
IDE at openajax.org
http://openajax.org/mailman/listinfo/ide

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openajax.org/pipermail/ide/attachments/20090914/6c6db479/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090914/6c6db479/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://openajax.org/pipermail/ide/attachments/20090914/6c6db479/attachment-0003.gif 


More information about the IDE mailing list