I saw your comment about that tag rewriting step
// TODO: [2006-09-28 ptw] Surely we can do this at compile-time and
// eliminate this ridiculous overhead?
The LzNode.makeChild method now does this lookup in the constructor map, right? So we could just eliminate// eliminate this ridiculous overhead?
the FixTags step now I think.
On 9/28/06, P T Withington < [EMAIL PROTECTED]> wrote:
> Change change.1uZRTnwsB.txt by [EMAIL PROTECTED] /Users/ptw/
> pending-changes/ on 2006-09-28 19:36:44 EDT
>
> Summary: Move tag constructors out of global
>
> New Features: Tags created with <class name="tagname"> now define
> lz.tagname, rather than global.tagname. (global.tagname will still
> exists so long as there is no conflict with the underlying runtime,
> but will give a deprecation warning when used as a constructor.) All
> built-in tags now have an alias to their constructor as lz.tagname.
>
> Bugs Fixed:
> LPP-2757 Defining a user class named `top` breaks DHTML in Safari
>
> Technical Reviewer: hminsky (pending)
> QA Reviewer: max (pending)
> Doc Reviewer: jsundman (pending)
>
> Documentation: The documentation for instantiating a tag dynamically
> needs to be updated to say you use `new lz.tagname`.
>
> Details:
>
> Make it so our node instantiator can find node classes without
> them having to be globals. Global constructors still are defined
> when they do not conflict with runtime globals, but using them
> will give a deprecation warning to use lz.whatever in the future.
> There is also a warning for the case where you define a tag that
> would clobber a runtime global, telling you that you won't have a
> global constructor for that tag and that you will have to use
> lz.whatever. Finally, while `new LzNode` will continue to work
> without a warning, `new lz.node` will also work, eliminating that
> source of complexity.
>
> LzLibrary, LzScript, LzInputText, LzText, LzDrawView, LzView,
> LzCanvas, LzSelectionManager, LzDataSelectionManager, LzState,
> LzAnimatorGroup, LzAnimator, LzLayout, LzConnectionDatasource,
> LzDatapointer, LzDataset, LzDatapath, LzHTTPDatasource, LzParam :
> define tagname for class
>
> LzCSSStyle, LzNode, LzView : global -> ConstructorMap
>
> LzNode: the class initializer will install the constructor in
> ConstructorMap if the class defines static tagname.
>
> LzUserClass: Use tagname to install class, implement deprecated
> global constructor, warn on global conflict, continue
> UserClassPlacementObject kludge with a big FIXME
>
> Class: Add override diagnostics (off for now), apply static
> initializer to class, demote trait overrides to debug rather than
> warn (for now).
>
> LzDefs: Define empty ConstructorMap here, so it can be filled in
> as LzNode subclasses are created. Alias lz to ConstructorMap.
>
> LaszloInitiator: Remove hand-generated ConstructorMap, obsolete
> TagFunctionMap, unnecesary FixTag tag name adjustment
>
> LzReplicationManager, LzDataset: be more careful about global
> adjustmenst, use the correct tag name for datapath
>
> ClassCompiler: use correct tag for class
>
> Tests:
> LZPIX still works!
>
> Files:
> M lfc/kernel/swf/LzLibrary.lzs
> M lfc/services/LzCSSStyle.js
> M lfc/core/LzNode.lzs
> M lfc/core/UserClass.lzs
> M lfc/core/Class.lzs
> M lfc/core/LzDefs.lzs
> M lfc/glue/LaszloInitiator.lzs
> M lfc/views/LzScript.lzs
> M lfc/views/LzInputText.lzs
> M lfc/views/LzText.lzs
> M lfc/views/platform/swf/LzDrawView.lzs
> M lfc/views/LaszloView.lzs
> M lfc/views/LaszloCanvas.lzs
> M lfc/helpers/LzSelectionManager.lzs
> M lfc/helpers/LzState.lzs
> M lfc/controllers/LzAnimatorGroup.lzs
> M lfc/controllers/LaszloLayout.lzs
> M lfc/controllers/LaszloAnimation.lzs
> M lfc/data/LzReplicationManager.lzs
> M lfc/data/platform/swf/LzConnectionDatasource.lzs
> M lfc/data/LzDatapointer.lzs
> M lfc/data/LzDataset.lzs
> M lfc/data/LzDatapath.lzs
> M lfc/data/LzHTTPDatasource.lzs
> M lfc/data/LzParam.lzs
> M server/src/org/openlaszlo/compiler/ClassCompiler.java
>
>
>
>
> _______________________________________________
> Laszlo-dev mailing list
> [email protected]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>
>
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
