[Laszlo-dev] designing API which is LZX friendlyand Javascript-friendly

[Henry Minsky]

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 <enw at laszlosystems.com> 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 <dhopkins at donhopkins.com> 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
> > hminsky at laszlosystems.com
> >
>



--
Henry Minsky
Software Architect
hminsky at laszlosystems.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://openlaszlo.org/pipermail/laszlo-dev/attachments/20051130/ca2974d3/attachment.html