On 28 Nov 2005, at 14:36, 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]> 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 thingsthat need to happen automatically when the classes are instantiated. The "contextmenuitem" needs to place itself into theparent "contextmenu" instance, and the "contextmenu" needs to installitself into the parent view.However, if you are creating and manipulating menus and menu items atruntime, 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 theinstantiation 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 [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev-- Henry Minsky Software Architect [EMAIL PROTECTED] _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
