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

[Jim Grandy]

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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.openlaszlo.org/pipermail/laszlo-dev/attachments/20070116/45a34527/attachment.html