I think the right thing to do here is:
1) Formalize the way that the compiler passes view instantiation args, and
expose and document the methods whereby an instance stores and inflates
its childNodes. Ideally we'd do this around the LzDataNode constructor
signature.
2) Make replication explicit instead of implicit. e.g.
<view>
<replicator>
<view name="replicatedInstance">
...
rather than
<view>
<view name="replicatedInstance">
<datapath replication="normal">
...
In many ways this is simpler than what we have now. It certainly fixes a
lot of the obtuseness around getting a handle on the replication manager
which currently is usually unavailable until after certain conditions are
met at runtime.
I think instance-first development is still really important but the
magical instance->replication manager transformation is a pain in the
neck.
A
On Jun 2, Jim Grandy wrote:
> I know this is heresy, perhaps, but let me wonder for a minute whether the
> ability to replicate an inline-declared customized instance is really worth
> all the complexity it requires of the runtime. Wouldn't we get most/all of the
> bang (if a little less elegance) if we fell back to specifying classname and
> initargs, and creating each replicated view from those values, instead of
> partially creating, then cloning, a view?
>
> (Of course, this is in the context of the proposal, still on the table, to
> move to an explicit replication scheme, where replication always happens (even
> for n=1) when asked for, and never happens if not requested.)
>
> So, concretely:
>
> <class name="myview" extends="view">...</class>
>
> <replicate datapath="..." classname="myview" initargs="..."/>
>
> would replace
>
> <view datapath="..." ...>...</view>
>
> jim
>
> On Jun 2, 2006, at 2:11 PM, Adam Wolff wrote:
>
> > yeah, things definitely can get destroyed before they're done
> > instantiating. That's the purpose of the __LZdeleted flag. Another
> > possibility would be to just set this flag and not run destroy code until
> > node.initialize is done.
> >
> > A
> >
> > On Jun 2, P T Withington wrote:
> >
> > > Henry and I are debugging replication in DHTML, and found an interesting
> > > effect: When a node is initialized and is given a datapath it gets
> > > replaced
> > > by a replication manager when applyArgs happens. If pooling is off, the
> > > replication manager will destroy the node, while it is still in
> > > node.initialize. So it appears node.initialize needs to be prepared to
> > > exit
> > > early after apply args, otherwise it tries to continue initializing the
> > > node
> > > and trips over things, like LZinstantiationDone having been set to null by
> > > destroy.
> > _______________________________________________
> > 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
