[Laszlo-dev] designing API which is LZX friendly and
Javascript-friendly
Jim Grandy
jgrandy at laszlosystems.com
Mon Nov 28 11:36:54 PST 2005
I imagine we could also design something that uses XSLT as an
implementation detail but has a more friendly syntax. A declarative
syntax like Dylan's would be really nice. Here's the first example in
the chapter referenced in my reply:
define macro if-else
{ if-else (?test:expression, ?true:expression, ?false:expression) }
=> { if (?test) ?true else ?false end }
end macro if-else;
I'd really like to work on a proposal for this. Tucker's reference to
JSE is intriguing -- it's based on the Dylan macro system, which
David Moon worked on -- but I think we can do something even simpler
if we stick to XML transformation.
jim
On Nov 28, 2005, at 10:34 AM, Henry Minsky wrote:
> 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 <jgrandy at laszlosystems.com> 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
> [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
>> hminsky at laszlosystems.com
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com
>
> _______________________________________________
> Laszlo-dev mailing list
> Laszlo-dev at openlaszlo.org
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openlaszlo.org/pipermail/laszlo-dev/attachments/20051128/b467a3ac/attachment-0001.html
More information about the Laszlo-dev
mailing list