On Nov 28, 2005, at 4:00 PM, Henry Minsky wrote: You can't hate it as much as I do.
Speaking as the guy who wrote most of the XSLT that Henry is currently hating (the HTML wrapper templates):
If E4X and its implementation in Rhino had existed when I wrote that code, I would have used that instead. It's more readable, it's sufficient for everything we're using it for, and it would bring the number of languages down since we're using _javascript_ anyway for the client code. I used Rhino+E4X for the latest page generation system I needed, and it was a joy. On 11/28/05, Max Carlson <[EMAIL PROTECTED]> wrote: Remember, we now have a CSS preprocessing phase on the server. I've
been advocating an XSLT transformation phase for both LZX and
LPS-proxied data for a while. But I _hate_ xslt syntax...
-Max
Jim Grandy wrote:
> 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* < [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"
>>> >
>>> 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] <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
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list
|
