| I'm very interested in these questions, as well. Max and I have discussed making the components purely data-driven, that is, implemented so that list items (for example) are always instantiated by replicating from a dataset. Max believes this would simplify the design of the components significantly. The issue is how to support this syntax:
<menu> <textlistitem>a</textlistitem> <textlistitem>b</textlistitem> </menu>
We need the same sort of magic you are describing, to transform that syntax into essentially this:
<menu> <dataset name="ds"> <item text="a"/> <item text="b"/> </dataset> <textlistitem datapath="local:parent.ds:/item"> </menu>
Then the replication timing can be controlled, things moved around, etc., during the transform step.
So in your case, the transformation would implement the declarative syntax in terms of an imperative (script-y) syntax.
Would it be going to far to propose a compile-time pattern-matching transform stage? Kind of like hygienic macros in Scheme ([1] or [2]) or Dylan [3], but perhaps more XSLT-arific. I imagine something like that could be used in lots of other ways.
jim
On Nov 28, 2005, at 8:29 AM, Henry Minsky wrote:
Here is a design issue that I am having with the context menu stuff,
which I'd like some developer feedback on. It is a general issue of
how to build an API that works well for both LZX (XML) style coding,
and also works well for scripting style coding.
PTW suggested something like the following API for LZX for the right click menu:
<view width="100" height="100" bgcolor="#cccccc" name="v1">
<contextmenu name="mycmenu" hidebuiltins="true">
<contextmenuitem name="item1" >
Item 1
</contextmenuitem>
<contextmenuitem name="item2" >
Item 2
</contextmenuitem>
</contextmenu>
</view>
Now, if I implement something like that, there are a number of things
that need to happen automatically when the classes are
instantiated. The "contextmenuitem" needs to place itself into the
parent "contextmenu" instance, and the "contextmenu" needs to install
itself into the parent view.
However, if you are creating and manipulating menus and menu items at
runtime, my feeling is that you do not want these things to happen
automatically for you, you want to have manual control over
instantiating menu items, setting their callbacks, installing them
into menus, and installing the menu itself onto a view.
I have a scripting API that looks like this:
<view width="100" height="100" bgcolor="#cccccc" name="v1">
<method event="oninit">
var cm = new LzContextMenu();
var item1 = cm.makeMenuItem('my item1', new LzDelegate(this, "handlerightclick1"));
var item2 = cm.makeMenuItem('my item2', new LzDelegate(this, "handlerightclick2"));
cm.addItem(item1);
cm.addItem(item2);
this.setContextMenu(cm);
Debug.write(cm);
</method>
I don't necessesarily want to have the contextmenu items install
themselves automatically into the parent menu when they are
instantiated; I might want to put them in a different order that the
instantiation order. And I don't necessarily want to install the menu
as soon as I create it, I may want to pre-instantiate the menu object,
but wait until some other event to actually install it on a view.
So the question is, how do you suppress the "automatic" behavior of
the menu item objects when you are instantiating from script. This
seems like a general issue, which must come up in other cases, where
people want to instantiate list menus, comboboxes, etc, at
runtime. Are there a set of guidelines for designing APIs which are
friendly both for LZX and _javascript_?
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list
|
