Here's the problem: We already have <script href="">. Due to the
magic queued instantiation scheme we have for our nodes, the script
node has to have a kludge so that its contents get executed in
lexical order. This is usually what LZX programmers expect.
In the case Henry is talking about, we don't want no stinkin' queued
instantiation. We just want to define a bunch of Javascript that
will be loaded when our library gets loaded.
We can't used <script type="Javascript"> to help, since that is the
only type we support anyways.
So, I really do think Henry is right. This is an <include>, but it
is not an include of LZX it is an include of Javascript, and we want
the Javascript includes to just go straight through to the script
compiler, with no funny LZX instantiation semantics.
[Another approach, which Henry and I discussed but dismissed is to
examine whether we still need the magic instantiation semantics, or
whether we need as many. In particular, do we really want user-
defined classes to be queued for instantiation? This seemed like too
big a change to tackle at this point.]
On 2007-01-16, at 12:22 EST, Jim Grandy wrote:
Wouldn't <script href=""> be more descriptive, and more in line
with what other markup languages do?
On Jan 16, 2007, at 8:21 AM, Henry Minsky wrote:
There's some code which Pablo wrote for the RPC libraries which
basically just wants to include
straight javascript code, in the same way that the LFC is written.
He had to wrap these files in <library><script> tags to get them
to work with <include> in LZX.
I propose an option to <include> which is a "type=script"
attribute. If the tag compiler encounters this, it
will just inline the contents of the included file directly at the
top level, just like LFC code.
So the library code which declares the <javarpc> class would say,
for example
javarpc.lzx:
<library>
<include href="rpc/rpc.lzx" />
<include href="rpc/library/javarpc.js" type="script" />
And the javarpc.js file is straight javascript.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
