I was trying to make a change the other day to consolidate the
"datapath" and "$datapath" init attributes. I think the right thing would
be to have the compiler pass a single "datapath" attribute which would
always be a "initobj" hash table to specify a <datapath> element.
(see the email thread "proposed fix
for LPP-4386, making <datapath> element and datapath attribute more
equivalent" message...)
I ran into trouble just trying to pass a list value in the "datapath"
attribute, as Andre pointed out, because setDatapath is used in a
number of places, and overriden, and generally doesn't want to be
passed anything but a string.
Maybe the solution would be to use a different name for the datapath
initializer attribute from the compiler, like "_lzinitialdatapath" or
something, which the compiler uses to pass in the datapath
initializer. I still have the change to NodeModel.java that consolidates
the "datapath" and "$datapath" values, so we should try and
solve this issue while we're in here.
On Fri, Feb 8, 2008 at 9:59 AM, P T Withington <[EMAIL PROTECTED]> wrote:
> What I'm working on right now is unifying attribute initialization.
> Rather than having separate lists of initial values, initial
> expressions/constraints, and style constraints, I am creating a single
> list and using classes to distinguish what type of initialization (or
> constraining) happens to each attribute. This should solve the
> problems we have with literal overriding a constraint, etc., which all
> stem from the runtime not being able to compute how the separate lists
> interact up the inheritance chain. This is part of the groundwork to
> have LZX classes output as JS2 class declarations at compile time,
> rather than the current 'template' that the instantiator reads to
> create classes at run time.
>
> As part of this work, and part of the JS2 work, I am changing the tag
> compiler to, instead of outputting constraints as free-floating
> functions that get call/apply-ed to specific instances, to output them
> as methods on the correct class. This is mostly an efficiency thing.
> We still could move these constraint methods around if we had to, I'd
> just like not to have to, because method calls should be more
> efficient than applying a random function to an instance.
>
> Finally, I think I have a fix to make `releaseConstraint` actually
> work, that falls out of the above changes. That code had totally
> rotted, as you will see in the comment, yet there are a number of
> places that either expect it to work or should be using it. (For
> example, if you try to change the `align` or `valign` of a view, you
> probably get really unexpected results -- the current code applies a
> constraint for the new value, but the old constraint is not released.
> If it works at all, it is through serendipity of the order in which
> the constraints are fired.)
>
> So, states: I think for a state, if there are constraints in the
> state, the constraint method will be defined on the parent class/
> instance, and the constraint apply/released as the state is applied or
> not.
>
> And for implicit replication, yes, I agree, it is probably a matter of
> moving the constraint method to the instance/class it will be applied
> to (at compile time), and at run time, you may or may not actually
> instantiate the replication manager.
>
>
>
> On 2008-02-08, at 08:41 EST, André Bargull wrote:
>
> > What do you actually plan to do for states, because through states
> > you'll get dynamic constraints, so dynamic method attachment/
> > detachment, too.
> > You've wrote once about a LzConstraint-class, but I can't quite
> > remember in which context. If you had this LzConstraint-class,
> > couldn't you add/remove constraints more easily at runtime?
> > So specifically for implicit replication, you'd only remove the
> > datapath-/xpath-constraint from the source-node's datapath and
> > attach it to the replication-manager and that's it.
> >
> > Also keep in mind, that currently constraint datapaths aren't fully
> > "bug-free", i.e. LPP-4209 or LPP-5353.
> >
> > On 2/8/2008 1:46 PM, P T Withington wrote:
> >> True. And this I think is one of the complaints about implicit
> >> replication, that it is unpredictable.
> >>
> >> The alternative is that implicit replication will just have to be
> >> slower than explicit (because it needs to do this dynamic method
> >> detachment and attachment at runtime, rather than being able to be
> >> analyzed at compile time). That would certainly be another way to
> >> deprecate implicit replication! :)
> >>
> >> On 2008-02-07, at 17:24 EST, André Bargull wrote:
> >>
> >>> But you need to consider, that the constraint does not apply to a
> >>> replication-manager in every case! If the xpath-expression points
> >>> to a single node, replication isn't triggered and therefore no
> >>> replication-manager will be created. If you just replace all
> >>> constraint datapaths with explicit replication, many programs will
> >>> break, because people don't expect to get a replicator-node in
> >>> this cases.
> >>>
> >>>> Delving into making constraints class methods, we have some tag-
> >>>> compiler work to do.
> >>>>
> >>>> Apparently you can say:
> >>>>
> >>>> <view datapath="${...}" />
> >>>>
> >>>> or:
> >>>>
> >>>> <view>
> >>>> <datapath xpath="${...}" />
> >>>>
> >>>> In both cases, the constraint really applies to the (invisible)
> >>>> replication manager, not to the view or the datapath. Right now
> >>>> this constraint is picked up at run time, ripped off the clone
> >>>> template and smashed onto the replication manager. That is not
> >>>> going to work in modern (JS2) runtimes.
> >>>>
> >>>> I think the right approach here is to have the tag compiler re-
> >>>> write implicit replication into explicit replication, so:
> >>>>
> >>>> <view datapath="${...}" />
> >>>>
> >>>> becomes:
> >>>>
> >>>> <replicator datapath="${...}">
> >>>> <view />
> >>>> </replicator>
> >>>>
> >>>> etc.
> >>>>
> >>>> Does this seem feasible? Could we even spit out a deprecation
> >>>> warning suggesting that explicit replication be used?
> >>>
> >>
> >>
>
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
