And one correction for the logical structure @sprite.__LZdiv <!-- Reference to lzclickdiv for the view -->
should of course be @sprite.__LZdiv <!-- Reference to div for the view --> The confusing thing indeed was the fact that for the DHTML runtime the ActionScript Sprite is the visual implementation/display object. On Thu, Jul 14, 2011 at 12:18 AM, Raju Bitter <[email protected]> wrote: > I'll close the JIRA. > > On Thu, Jul 14, 2011 at 12:17 AM, Raju Bitter > <[email protected]> wrote: >> Thanks, Tucker. I ran into this when I implemented drag&drop file >> upload for the DHTML runtime (which works, by the way). I thought that >> - similar to the SWF runtime - I could use the view.sprite object to >> attach the drop event handler, but that didn't work. I assumed that >> __LZdiv is the clickdiv. That means, for this LZX code: >> <canvas debug="false"> >> >> <view id="y1" x="200" y="10" width="100" height="100" bgcolor="yellow" >> clickable="true"> >> </view> >> >> </canvas> >> >> the following HTML element/object structure will be generated: >> <div id="appcontainer"> >> <div class="lzappoverflow"> >> <div class="lzcanvascontextdiv"> >> <div class="lzcontext"></div> >> </div> >> <div class="lzcanvasdiv"> >> <div class="lzdiv" style="background-color: rgb(255, 255, >> 0); height: 100px; width: 100px; left: 200px; top: 10px; z-index: 2; >> "> >> @sprite: LzSprite >> @sprite.__LZclickHTMLDivElement (reference to clickdiv for y1) >> @sprite.__LZdiv <!-- Reference to lzclickdiv for the view --> >> </div> >> </div><!-- lzcanvasdiv --> >> <div class="lzcanvasclickdiv"> >> <div class="lzdiv" style="left: 200px; top: 10px; z-index: 2;"> >> <div class="lzclickdiv" style="width: 100px; >> height: >> 100px; "></div> >> </div> >> </div> >> </div><!-- lzappoverflow --> >> </div> >> >> Thanks a lot for your detailed answer! >> >> Raju >> On Wed, Jul 13, 2011 at 6:48 PM, P T Withington <[email protected]> wrote: >>> I should also add that in the swf10 runtime, the sprite _happens_ to be a >>> subclass of the Flash sprite so it _is_ the platform-specific display >>> object. >>> >>> The two implementations are not parallel, but the implementation of >>> getDisplayObject is correct. I can see that it is a little confusing >>> because one is a subclass implementation and the other is a delgating >>> implementation. >>> >>> We could have made a more parallel implementation by making the swf >>> implementation also delegating, but the choices were made for efficiency >>> and, in the case of DHTML, because you can't subclass DHTML elements in >>> Javascript. >>> >>> On 2011-07-13, at 09:43, P T Withington wrote: >>> >>>> On 2011-07-13, at 06:55, Raju Bitter wrote: >>>> >>>>> When I make a call to view.getDisplayObject() in the DHTML and mobile >>>>> runtime, the call returns the LzSprite.__LZdiv object. Is that the >>>>> expected behavior, or should it not return the view.sprite instance? >>>>> >>>>> Given the following code: >>>>> <canvas debug="true"> >>>>> >>>>> <view name="y1" x="200" y="10" width="100" height="100" >>>>> bgcolor="yellow"> >>>>> >>>>> </view> >>>>> >>>>> <button text="y1.getDisplayObject()" onclick="Debug.info( >>>>> y1.getDisplayObject() )" /> >>>>> <button y="30" text="y1.sprite" onclick="Debug.info( y1.sprite )" /> >>>>> >>>>> </canvas> >>>>> >>>>> Debug.info( y1.getDisplayObject() ) gives me: >>>>> INFO: «HTMLDivElement#0| >>>>> #y1/@sprite/@__LZdiv/div.lzdiv[@style="background-color: rgb(255, 255, >>>>> 0); height: 100px; width: 100px; left: 200px; top: 10px; z-index: >>>>> 4;"]» >>>> >>>> I should explain how to read this psuedo-xpath/css syntax (invented by >>>> Oliver). >>>> >>>> #y1 means y1 is a global (like an id, like # in css) >>>> @sprite means sprite is an attribute of y1 >>>> @__LZdiv ditto >>>> div.lzdiv says this is an HTML div element with class lzdiv >>>> [@style=...] describes the local css bindings on this element >>>> >>>>> And Debug.info( y1.sprite ) gives me: >>>>> INFO: «LzSprite#3| #y1/@sprite [100 x 100]*[1 0 200, 0 1 10, 0 0 1]» >>>> >>>> LzSprite is the kernel object that has different implementations for >>>> different platforms that implement the kernel API the generic OL code >>>> talks to >>>> >>>>> Here are my questions: >>>>> 1) What is the additional div __LZdiv used for? >>>> >>>> That is the actual platform-specific HTML element that implements the >>>> sprite in DHTML >>>> >>>>> 2) If I want to add HTML objects created through JavaScript to a view, >>>>> should I attach them to the sprite, or to the __LZdiv instance? >>>> >>>> The __LZdiv. That is the platform 'displayObject'. The sprite is not the >>>> actual display object. >>>> >>>> Bottom line: getDisplayObject is giving you the element where you can >>>> attach custom HTML or directly manipulate the platform object representing >>>> the sprite (at your own risk, of course). >>>> >>> >>> >> >
