/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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
On Thu, May 8, 2008 at 11:34 AM, André Bargull
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> 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 [EMAIL PROTECTED] 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
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>