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

[P T Withington]

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 <jgrandy at openlaszlo.org> 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
>> >>> hminsky at laszlosystems.com
>> >>>
>> >>
>> >
>>
>>
>>
>>
>> -- 
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>>
>