I definitely was thinking about some kind of def-macro facility when
trying to come up with ways to do this. I don't have any experience
with macros except for in LISP, so I don't really know what such a
facility would look like. It occurred to me that if you
had a Rhino javascript interpreter in the compiler, you could write
some kind of macro
in Javascript, which would probably be a better idea than coming up
with yet another
syntax for people to try to learn. XSLT is probably a much better
match for XML, but it's syntax is so yucky that I would hate to force
people to use it for anything.
I guess if we have the E4X stuff (XML APi for Javascript), then
writing XML transformers in Javascript would not be so bad. Maybe we
could punt the XML compiler phase of the existing compiler and write
all the LZX language stuff as javascript macros...
On 11/28/05, *Jim Grandy* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
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.
[1]
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%25_sec_4.3
<http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-7.html#%25_sec_4.3>
[2] http://www.scheme.com/tspl3/syntax.html#./syntax:h0
[3] http://www.gwydiondylan.org/books/dpg/db_329.html
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"
onselected="parent.parent.showSelectItem('item1')">
Item 1
</contextmenuitem>
<contextmenuitem name="item2"
onselected="parent.parent.showSelectItem('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] <mailto:[EMAIL PROTECTED]>
_______________________________________________
Laszlo-dev mailing list
[email protected] <mailto:[email protected]>
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
<http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
_______________________________________________
Laszlo-dev mailing list
[email protected] <mailto:[email protected]>
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
