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).
>>
>
>
