Well, in our new theory, maybe the resource declarations can all be accumulated at updateShema time, and then processed /en masse/ at schemaDone time, and passed as a block through the appropriate writer and hence js-compressed?
On 2010-05-21, at 12:00, Henry Minsky wrote: > When the tag compiler sees one of those LZX XML resource declarations, the > DHTML writer converts it to a lzs script statement. It used to be that was > passed to the script compiler backend, but because we needed to reorder > things so that the resource declarations always come before any other script > code, we changed it to accumu late the resource lzs statements and then > shove them into the final output stream ahead of any of the user code, > without sending it through the script compiler. > > It was just easier that way, and we didn't think that the resource > declaration lzs script needed any js1-style transformations from the script > compiler, they are so simple. > > > > > > On Fri, May 21, 2010 at 11:51 AM, P T Withington > <[email protected]>wrote: > >> On 2010-05-21, at 11:11, Henry Minsky wrote: >> >>>>> 2) some resource dimensions are floating point numbers instead of >>>> integers: >>>>>> >>>> >> LzResourceLibrary.navbg={ptype:"ar",frames:['images/nav_bg.png'],width:200.0,height:600.0,spriteoffset:189}; >>>> >>>> This may be because resources are not going through the compressor. >>>> >>>> Yes we made a change in the dhtml compiler and now the resource >> declaration >>> statements are included verbatim, rather than going through >> parser/unparse >>> by the >>> script compiler. >>> >>> We could pass them through the script compiler if needed, but it didn't >> seem >>> critical, as they were just basic assignments and lists of objects. >> >> I'm a little confused here. The lzo compiler just writes out the resource >> declarations as XML, so where is this code coming from? > > > > > -- > Henry Minsky > Software Architect > [email protected]
