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

Reply via email to