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