Well, that's just confusing. Who would expect that <include
type="script" href=""/> doesn't have the same semantics as <script
href=""/>? I certainly wouldn't.
Can you explain how this relates to the <script when="immediate"/>
option Henry added last week?
Can this particular problem be resolved by moving the code into the
LFC, rather than introducing a new LZX language feature?
jim
On Jan 16, 2007, at 10:14 AM, P T Withington wrote:
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]