[Laszlo-dev] new language feature proposal: <include type="script" .../>

[Jim Grandy]

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
>>> hminsky at laszlosystems.com
>>>
>>
>