I know this is treading on thin ice, but is it possible to destroy
and then recreate the movieclip hierarchy when re-parenting?
(recognizing that the perf implications of such a move are less than
ideal.)
The reason I ask is not because I'm overly concerned about re-
parenting, but I'm considering what happens as you build out a DHTML
target. Re-parenting is trivial in DHTML, it seems like a shame to
disallow it because it's not easy in Flash.
On Nov 30, 2005, at 4:24 PM, Adam Wolff wrote:
that's right. it'd be easy to move the laszlo view object, but
movieclips
can not be moved.
A
On Nov 30, Henry Minsky wrote:
My understanding, and Adam can correct me, is that because we use
movieclip's parent child relation for views, and they cannot be
reparented,
you'd have to recreate the whole child movieclip hierarchy if you
reparent
a view?
On 11/30/05, Elliot Winard <[EMAIL PROTECTED]> wrote:
It sounds like this "script" way of instantiating objects would also
provide a
way to re-parent objects.
I'm not too experienced regarding the internals of our LzView
system's
Flash
implementation. Would it be very difficult to allow re-parenting?
-e
On Tue, 29 Nov 2005, Henry Minsky wrote:
What I am beginning to think is that there need to be two different
instantiation APIs
for components, one which is designed to be called from LZX
(XML), which
does
a lot of "automagic" setup, and one designed to be called from
script,
which
exposes all
the individual steps as much as possible. So you can decide for
example
to
instantiate a
menu item before there is a parent to add it to, or if you need
to add
it to
a place in
the parent which isn't at the end of the current list of items.
Tucker has proposed using something besides "new" to create new
components
in script. I think that is a good idea, but maybe we need to go
one step
further and have some conventions for two different standard
ways to
instantiate a component:
One way is the "LZX" way, where you pass a parent view, and an
arglist,
so
that "new MyFrob(...)" behaves as much as possible like using
<MyFrob>
in
LZX; as much magic as possible is done to install the object
into it's
parent environment.
And the other would be the "script" way, which behaves in a more
modular
fashion, so you would expect to manually instantiate an
object, then add it to a parent or not at your discretion, and set
callbacks
and event handlers, etc, manually.
On 11/29/05, Don Hopkins <[EMAIL PROTECTED]> wrote:
What are the advantages of dynamically creating user interface
components
through xml data binding, instead of using a JavaScript api?
I've been playing around with pie menus for Laszlo, trying to
come up
with
a Laszlish way to dynamically create and configure them.
http://www.donhopkins.com/drupal/node/40
http://www.donhopkins.com/lzxnet/my-apps/PieTest.lzx
http://www.donhopkins.com/lzxnet/my-apps/PieTest.lzx?lzt=source
http://www.donhopkins.com/lzxnet/my-apps/piemenu.lzx?lzt=source
The Laszlo pie menus don't currently support an API for
modifying the
menus dynamically, but I've been thinking about how that should
work,
and
how it could support user-editable menus that knew how to write
themselves
back out as XML.
Some pie menus are dynamically generated from data, so all
items are
usually handled the same (or from a small set of pre-defined
handlers
based
on the dataset), but other pie menus are designed by hand with
custom
handlers, tracking feedback and graphical resources associated
with
each
item.
One problem with only defining widgets from XML, is how do you
attach
custom methods and event handlers to widgets?
Including custom JavaScript handlers and constraints in the
widget xml
definition would require a JavaScript compiler in the Flash player
(but it
would be possible in the DHTML version of Laszlo). You have to
pre-define
all the handlers and constraint expressions as named functions,
refer
to
their names in the xml, and look them up at run-time.
-Don
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
