Okay, yes, let's go with this.

On 2007-01-16, at 13:41 EST, Jim Grandy wrote:

It's more intuitive to me: it says, drop this script code directly into the output stream, so that it is processed as the stream is brought into the runtime. I suppose this would mean that in HTML, the <script> tag effectively has a when="immediate" annotation.

Right?

jim

On Jan 16, 2007, at 10:31 AM, Henry Minsky wrote:

Well,perhaps we could get the same end result if we said to use

<script href="foo.js" when="immediate"/>

Is that more intuitive? I can't tell anymore...

The issue is that we don't want to fatten up the LFC with a module that few people are going to use. So how should people add code which is essentially LFC extensions, or more generally, straight javascript like we use in the LFC, to their apps?

On 1/16/07, Jim Grandy <[EMAIL PROTECTED]> wrote:
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]
>>>
>>
>




--
Henry Minsky
Software Architect
[EMAIL PROTECTED]



Reply via email to