[Laszlo-dev] For Review: Change 20080508-hqm-o Summary:, remove obsoleted LzDataNode class, update docs
André Bargull
a.bargull at intensis.de
Sun May 11 05:42:42 PDT 2008
/All these problems just because LzDataset needs be a data-node and a
LzNode.../
Concerning my previous proposal:
I was thinking in Java where I can have constants in an interface. But
this won't work for AS3 (ES4, too?).
If you want to be the most possible backward compatible, you'd have the
following class scheme:
> base classes:
> LzMiniNode
> LzNode extends LzMiniNode
>
> mixins:
> LzDataNodeMixin
> LzDataElementMixin
>
> LzDataset extends LzNode with LzDataNodeMixin, LzDataElementMixin
>
> LzDataNode extends LzMiniNode
> LzDataElement extends LzDataNode with LzDataNodeMixin,
> LzDataElementMixin
> LzDataText extends LzDataNode with LzDataNodeMixin
pros:
- constants stay on LzDataNode (bwcompat)
- foo instanceof LzDataNode still works (except for LzDataset instances)
- looks more like the DOM-Model with Node and Element
At the moment, we force three code changes:
i) "LzDataNode.stringToLzData(..)" needs to be updated to
"LzDataElement.stringToLzData(..)"
ii) "LzDataNode.ELEMENT_NODE" needs to be updated to
"LzDataElement.ELEMENT_NODE" (same for TEXT_NODE, DOCUMENT_NODE)
iii) "foo instanceof LzDataNode" needs to be updated to "foo is
LzDataNodeMixin" (because instanceof only looks at prototype chain [1])
Especially iii) makes me worries, because I don't think the
"is"-operator is wide-spread among the lzx-developers yet.
[1] From
"http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/migration.html"
> Although the instanceof operator is available, it only checks the
> prototype chain, which is not the primary inheritance mechanism in
> ActionScript 3.0. Use the is operator to check whether an object is a
> member of a specific data type.
On 5/8/2008 6:48 PM, Henry Minsky wrote:
> I think maybe the simplest thing for back compatibility is to leave
> LzDataNode as a kind of placeholder shell of a class, with copies of
> the constant declarations for ELEMENT_NODE, TEXT_NODE, while also
> making copies of them on LzDataElement, and recommending that
> LzDataElemenet.TEXT_NODE, etc , be the approved usage.
>
> Then we can figure out some way in the future to inform people that
> referring to LzDataNode.ELEMENT_NODE is deprecated.
>
> On Thu, May 8, 2008 at 12:03 PM, Henry Minsky <henry.minsky at gmail.com
> <mailto:henry.minsky at gmail.com>> wrote:
>
>
>
> On Thu, May 8, 2008 at 11:34 AM, André Bargull
> <a.bargull at intensis.de <mailto:a.bargull at intensis.de>> wrote:
>
> Ok, the only public function in LzDataNode is
> "LzDataNode.stringToLzData(..)"...
>
> So I'd like to propose:
> - move "LzDataNode.stringToLzData(..)" to "LzDataElement"
> - rename LzDataNodeMixin (back) to LzDataNode
> - move ELEMENT_NODE, TEXT_NODE, DOCUMENT_NODE to LzDataNode as
> const
> (this is where they actually belong to [1])
> (and it is more compliant to 4.0.12 [2])
>
>
> Oops, there's only one problem with putting the constants on
> LzDataNode, because of the
> way mixins are implemented, there isn't really any class called
> LzDataNode to put the
> constants, ELEMENT_NODE, TEXT_NODE, DOCUMENT_NODE, on.
>
> At compile time, for each class which uses mixins, we generate a
> bunch of intermediate classes as
> $lzsc$mixin$LzDataElementMixin$LzDataNode$LzMiniNode.as which simulate
> the mixin by merging all the methods and properties into these
> 'interstitial' classes,
> so there is no actual LzDataNode class on which to hang the
> constants. Maybe we should be emitting one?
> Is there a way to make a class which is also a mixin?
>
>
>
>
>
>
>
> => that way, the only API-change is about "stringToLzData" and
> user programs which use
> - "LzDataNode.ELEMENT_NODE" etc.
> - and "p is LzDataNode" will still continue to work.
>
> Just my 2 cents.
>
> [1]
> "http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#ID-1950641247"
> [2]
> "http://svn.openlaszlo.org/openlaszlo/tags/4.0.12/WEB-INF/lps/lfc/data/LzDataNode.lzs"
>
>
>
>
> On 5/8/2008 4:46 PM, André Bargull wrote:
>
> This is a public-API change, sure you still want to do
> this? Will <strike>possibly</strike> surely break user
> applications.
>
> Change 20080508-hqm-o by hqm at badtzmaru.home on
> 2008-05-08 09:28:35 EDT
> in /Users/hqm/openlaszlo/trunk5
> for http://svn.openlaszlo.org/openlaszlo/trunk
>
> Summary: remove obsoleted LzDataNode class, update docs
>
> New Features:
>
> Bugs Fixed:
>
> Technical Reviewer: ptw
> QA Reviewer: pbr
> Doc Reviewer: (pending)
>
> Documentation:
>
> Release Notes:
>
> Details:
>
> The LzDataNode class had pretty much all it's
> functionality moved to lzDataNodeMixin, and there
> were just a couple of static properties left on
> LzDataNode. I moved these to lzDataElement, and updated
> the table of contents to not point to LzDataNode anymore.
>
>
>
>
> Tests:
>
> smokecheck
> ant lztest
> test/lfc/data/alldata.lzx
>
>
>
> Files:
> M WEB-INF/lps/lfc/kernel/swf/LzLoader.lzs
> M WEB-INF/lps/lfc/services/LzBrowser.lzs
> M WEB-INF/lps/lfc/helpers/LzCommand.lzs
> M WEB-INF/lps/lfc/data/LzDatapointer.lzs
> M WEB-INF/lps/lfc/data/LzDataText.lzs
> M WEB-INF/lps/lfc/data/LzDataNode.lzs
> M WEB-INF/lps/lfc/data/LzDataElement.lzs
> M WEB-INF/lps/lfc/data/LzDataset.lzs
> M docs/src/nav/toc.xml
> M lps/components/rpc/ajax.lzx
> M lps/components/rpc/library/swf/rpc.js
> M lps/components/rpc/library/rpc.js
> M lps/components/lzunit/lzunit.lzx
> M lps/components/utils/replicator/replicator.lzx
>
> Changeset:
> http://svn.openlaszlo.org/openlaszlo/patches/20080508-hqm-o.tar
>
>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
>
>
>
>
> --
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com <mailto:hminsky at laszlosystems.com>
>
More information about the Laszlo-dev
mailing list