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