Hi all!
Sorry if I'm way off topic, but do I understand right, that the need is
for sort of a templating thingy that consumes XML and produces
XML/Java(ECMA)Script?
After having suffered badly from xslt-poisoning (Debugging xslt
templates speeds up the floating of time by factor 200, i.e. you start
before it get's dark and when you next look out of the window it's
noon) I started to use FreeMarker (http://www.freemarker.org) to
transform xml, because it's syntax is very familiar to people who
develop web apps (jsp'ish including the capability to use taglibs) and
it has a powerful XML support (including xpath
http://www.freemarker.org/docs/xgui.html) and it has ant tasks.
As said before, this is no macro language, but maybe it's worth a
thought?
Cheers,
Mika
Henry Minsky schrieb:
You can't hate it as much as I do.
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
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
|
