[Osr-101] Re: [Yulup-commits] rev 23793 - in public/yulup/src/branches: . WIDGET_REFACTORING_BRANCH/yulup/src/templates/src/html.nar

[Andreas Wuest]

Hi Thomas

On 17.4.2007 8:16 Uhr, Thomas Comiotto wrote:

> Hi Andi,
> 
> Wouldn't it make sense to discuss how to approach widget bindings on 
> osr-101 beforehand?

That's why I've created the branch, I wanted to see what has to be 
changed, etc.

> Anyway some short notes re your approach:

Please note that this commit contained an old version, and I've already 
changed it heavily again (but I did not check it in until this morning, 
because I did not have the time).

>  - does not separate GUI frontend from the datatype related stuff. 
> Editor vendors should be free to and will use their own icons, labels 
> (i18n!) and so on.

But only under the assumption that there is a given minimal widget set, 
which everyone supports, and so can be referenced via Neutron.

>  - tries to model commands instead of providing data for configuring 
> commands.

What would you do instead?

>  - it's quite verbose. Can you make a complete example for a table widget?

Sure, although I do it with the most recent format I have in mind:

       <widget icon="icons/table.png">
         <name xml:lang="en">Table</name>
         <name xml:lang="de">Tabelle</name>
         <description xml:lang="en">Insert a table</description>
         <description xml:lang="de">Tabelle einfügen</description>
         <insert>
           <parameter xpath="table/attribute::border">
             <name xml:lang="en">Border</name>
             <name xml:lang="de">Rand</name>
             <description xml:lang="en">Border thickness</description>
             <description xml:lang="de">Randbreite</description>
           </parameter>
           ... add more parameters if you like
           <fragment>
             <table border="0" cellpadding="0" cellspacing="0" 
bgcolor="#DDDDDD" xmlns="">
               <tr>
                 <td>Column 1, Row 1</td>
                 <td>Column 2, Row 1</td>
               </tr>
               <tr>
                 <td>Column 1, Row 2</td>
                 <td>Column 2, Row 2</td>
               </tr>
             </table>
           </fragment>
         </insert>
       </widget>

>  - it's flexible by not implying basic methods of a particular widget. 
> Nice and well, but do we really need that? I'd rather define a fixed set 
> of widgets and take the corresponding functionality for granted: it's 
> evident that a bold command is ment to surrounds a selected range, a 
> table can basically contains rows and cells and so on. If widgets are 
> about document formatting then keep it as simple as possible.
>  - mapping fragments to widget components/commands is misleading. It's 
> about mapping *datatype declarations* to widget components/commands

Hmm, not to sure about that. Suppose we want to insert assets: in my 
proposed format, this would look like this:

       <widget icon="icons/asset.png">
         <name xml:lang="en">Asset</name>
         <name xml:lang="de">Asset</name>
         <description xml:lang="en">Insert an asset</description>
         <description xml:lang="de">Ein Asset einfügen</description>
         <surround>
           <parameter xpath="a/attribute::href" type="resource">
             <name xml:lang="en">URI</name>
             <name xml:lang="de">URI</name>
             <description xml:lang="en">Asset address</description>
             <description xml:lang="de">Assetadresse</description>
           </parameter>
           <fragment>
             <a xmlns="" href=""/>
           </fragment>
         </surround>
         <insert>
           <parameter xpath="a/attribute::href" type="resource">
             <name xml:lang="en">URI</name>
             <name xml:lang="de">URI</name>
             <description xml:lang="en">Asset address</description>
             <description xml:lang="de">Assetadresse</description>
           </parameter>
           <parameter xpath="a/object/text()">
             <name xml:lang="en">Alternative text</name>
             <name xml:lang="de">Alternativer Text</name>
             <description xml:lang="en">Alternative text which is shown 
if image display is disabled or the image could not be loaded</description>
             <description xml:lang="de">Alternativer text der gezeigt 
wird, falls das Anzeigen von Bildern unterbunden wurde oder das Bild 
nicht geladen werden konnte</description>
           </parameter>
           <fragment>
             <a xmlns="" href="">
               <object class="asset"/>
             </a>
           </fragment>
         </insert>
       </widget>

This is a mapping of fragments (because we don't have a specific asset 
datatype). Furthermore, this approach allows us to insert different 
fragments for different actions: if the user has already selected text, 
then the "surround" fragment is used, which inserts a link. If no text 
is selected at the time the user invokes the widget, the "insert" 
fragment is inserted, which inserts an image link (e.g. a paper-clip, or 
whatever you fancy).

I also have some more ideas in store, which I try to implement. I have 
an element <widgetgroup/>, which contains <widget/>'s. This gives a hint 
to the client that the widgets contained in that group should be 
visually grouped. The prime example are the XHTML h1-h6, which then get 
grouped in a dropdown.

For a complete example, see e.g. 
http://svn.wyona.com/repos/public/yulup/src/branches/WIDGET_REFACTORING_BRANCH/yulup/src/templates/src/xhtml.nar/introspection.xml.

-- 
Kind regards,
Andi