Re: [rgui-dev] Tom's yaml interface definition

[Tom Sawyer]

been playing around with some various ideas on this theme. one of the first 
things i realized is that my examples are not technically correct yaml. the 
reason is that i am definishing hashes with the same key value over and over. 
ie:

        action:
                name: whatever
        action:
                name: somethingelse

this defines a hash in Ruby as:

   { 'action' => 'whatever', 'action' => 'somethingelse' }

problemo! to fix, either we use the name as the key:

        whatever:
                type: action
        somethingelse:
                type: action

this makes more sense b/c the names should never be the same anyway. so this 
is probably how it should be notated. but then again, i find this a bit 
harder to read when applied to larger examples. the other option is to use 
yaml arrays:

        - action:
                - name: whatever
        - action:
                - name: somethingelse

the - denotes an ordered list (array), yet this would be considered rather 
sloppy. at this point i'm tempted to say, "who cares about the yaml, don't 
worry about being technically correct",  but eventually i think we should 
have a markup form of our interface definition language, and of them i 
prefere yaml. so we might as well get it set now.

anyway i've been playing with the idea of reuable interfaces. and it seems to 
me that the way to maximize this is to seperate the general interface 
structure from the actual binding definitions. so you'd have two files. a 
very simple simple simple sample of what i mean:

        # interface.yaml
        whatever:
                type: action
                label: WhatE
        somethingelse:
                type: action
                label: SomeE

        # binding.yaml
        whatever:
                callback:       model.do_whatever
        somethingelse:
                callback: model.do_somethingelse

this way i could easily reuse the interface and create different binding files 
depending on what model i wanted to use. the idea has some merit, but after 
playing with it a bit, i'm not quite sure how useful it would really be.

with both of these combined in one file, as we have been doing, the interface 
is reusable as long as the model has the required methods called by the 
interface definition. in this way it is very much like how Ruby defines type, 
i.e. an object is of the right type as long as it has the methods required of 
it.

-transami



On Monday 16 December 2002 06:58 am, Thorsten Roggendorf wrote:
> Hi,
>
> it needed some time to sink in ... what you wrote there really looks
> amazing.
> Various confused thoughts:
>
> Should toplevel not be on the next indention level?
> model: eclipse
> toplevel:
>
>
> I wanted to test how extensible your concept is and started modularizing
> our eclipse app to get reusable parts:
>
> model: file_dialog
>   toplevel:
>     name:
>       entry:
>         name: file_dialog_title
>         value: 'Please enter filename:'
>     container:
>       name: file_selection
>       [... tree view, file selection and entry]
>     container:
>       name: action
>       action:
>         name: ok
>         label: Ok
>         callback: file_dialog.ok
>       action:
>         name: cancel
>         lable: Cancel
>         callback: file_dialog.exit
>
> model: file_menu
>   name: file_menu
>   uses: file_dialog
>   attribute:
>     name: file_name
>     type: string
>   type: menu
>     action:
>       name: open
>       lable Open
>       callback:
>         function: file_menu.open
>         attribute: file_menu.file_name
>     action:
>       name: save
>       lable: save
>       callback:
>         function: file_menu.save
>         attribute: file_menu.file_name
>     action:
>       name: save_as
>       lable: Save as ...
>       callback:
>       function: file_menu.save_as
>         attribute: file_menu.file_name
>     action:
>       name: exit
>       lable: Exit
>       callback: file_menu.exit
>
>
>
> [...]
>     container:
>       name: filemenu
>       type: menu
>       label: File
>       module:
>         include: file_menu
>         extension:
>           between: save_as, exit
>           action:
>             name: close
>             lable: Close
>             callback:
>               function: eclipse.filemenu.close
>               attribute: eclipse.filemenu.file_name
> [...]
>
> So far I did not encounter something that could not be expressed that
> way. However there might be room for simplification.
>
> What I called function in calllback might be generated automatically.
> Having to write it out might add flexibility though. This is a tradeoff
> we will often have to face. The attribute or return parameter or
> whatever could turn out to be essential though.
>
> The seperate attribute in the file_menu is needed to allow the client
> app to determine the filename by other means and have filemenu generate
> the file_menu.save event without instantiating file_dialog first.
> The uses clause in filemenu might be simplified away too. The file_menu
> will decide for itself if it needs to invoke file_dialog on a save
> event. If the attribute file_name has a value it will skip the
> file_dialog.
>
> I also used callback without defining function and attribute. That way
> the argument becomes the argument of function. The thing starts becoming
> messy already. We have introduced a dozen keywords and now I start
> messing everything up. Damn.
>
> General remarks. The event clause is indeed very interesting. I don't
> know if this a problem, but if you have more than one action bound to an
> event, the execution order is undefined. This problem does not occur in
> the gui-toolkits I know.
>
> I can't imagine that what we are talking about has not been tried
> before. Once you think into it the whole thing becomes so obviously
> useful - indeed an essential technology - that I can't imagine other
> people have not already tried it. This smells of university project.
> A prominent technology that lies in our target direction is IDL, the
> Interface Definition Language. That one only targets APIs and component
> models (CORBA) though, without addressing GUIs or other interface types.
> I googled a (tiny) bit, but if other people tried the same as we, their
> signal is lost in the IDL noise.
>
> Language choice:
> What I really like about your choosing yaml is its supreme readability.
> For this stage of communicating ideas, it seems well suited (maybe I
> should learn it before evaluating it though ...). However, if this ever
> gets beyond the stage of enthusiastic brainstorming, we should think
> about other options too.
>
> Cheers
>
>    Thorsten
>
>
>
> _______________________________________________
> Gutopia-dev mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/gutopia-dev