[closer-devel] slots on layers

[Attila Lendvai]

> Hi Atilla,


hello Pascal,


> Thanks a lot for your question and detailed explanation of your use case.
> Such feedback is very helpful in understanding the limitations of ContextL.


my pleasure!


> The question: I understand that you want to be able to reuse the state of
> layer-specific slots from deactivated layers when you activate such layers
> again. However, I don't quite understand how you expect to activate that
> specific layer instance. Do you expect to be able to inquire about which
> layers are currently active, and then pick out the one you're interested in?


what you wrote in your mail is consistent with my understanding of
contextl, so i think we have a misunderstanding here. what i want to
reactivate later is the instance made from the class representing the
currently active layer combination (and its slots), not just a single
layer "extracted" from it. i think dealing with specific layers in
layer context restoration would be against the whole idea of contextl.

some more background info: in our setup there are several different
layers. some are simple customizations like passive-components-layer:
it tells the gui algorithm to forget about actions below this
component; think of rendering components into transient tooltips -
there's no point in rendering actions that the user can't click
anyway...

some other layers are very specific customizations, specific to a
certain gui form _instance_!

e.g.: some action instantiates a metadata driven finder component. but
this finder will be used for selecting data instances, so we also want
to customize this finder to add a "select this instance" action into
the result of the lister component that it will instantiate when
showing the result of its search. obviously the added "select this
instance" action needs to know where it belongs to, but this action
won't even be created until some browser requests later: the layered
method adding this extra action for the search result list is called
only after the user clicks the "search" action on the finder. this
only happens some browser requests later.

this gui algorithm is recursive, so you need to "attach" this
customization to the specific finder component instance. if it's not
done, or the layer's slot is shared then if the user navigates somehow
to a different instance of the finder instantiated deeper in the
component recursion, then this customization will screw up the
workings of the two finder instances.

[i'm trying hard to make these examples clear, but unfortunately i'm
aware of the deficiencies... but keep in mind that his is a recursive
meta-gui that can display/edit a random data model in a browser, so
there are some inherent complexities...]


> class different from %l123. This automatically means that you _cannot_ reuse
> that old instance of %l123. So in other words, reusing the same class
> prototype from a previous activation state is _not_ a good idea (unless you
> perform a change-class on that instance, but I have strong reservations with
> regard to my willingness to deal with the complexities that would arise from
> this ;).


it may not be a good idea in certain situations, but in the factory
part of our lazy gui building algorithm this is just what we need: you
start out with a component representing/displaying a single instance
of your data graph. when creating the start component certain layers
are enabled to customize the view that starts our from here. the
current layer instance is stored (representing the full combination of
the current layer setup) where laziness stops the further creation of
child components using a lambda (this is the usual delay/force
laziness implemented using lambda's).

when the user later invokes an action that needs to extend the
component graph (by force-ing some delay-ed lambdas), we restore the
factory-time layer setup before calling the delayed lambda. e.g.: the
user clicks a link in the browser which is representing the remote
instance of an association. when it happens the link is replaced with
a detailed view of the target of the association (whatever the target
is... this is a component recursion point).

as of change-class: in the implementation we proposed in the previous
mail... when the layer setup is changed, then you need to _clone_ and
rebind the layer prototype instance, so i'd simply write a special
clone-layer-instance instead of change-class. of course this
interferes with certain shared-initialize customizations, but the
class defined by deflayer is private anyway.


> An alternative solution: Why don't you just use layer inheritance? You can


in short: because we need to remember such data in layered methods
that was only available in the lexical scope of with-active-layer
(several browser requests ago). this implies that anonymous layers are
not good for this, because a new layer would need to be created for
each run of the code block.


> P.S.: I don't want to avoid changes to ContextL, it's just that I want to
> make sure that changes to ContextL fit well with the rest of the design of
> ContextL, that's why I'm yet hesitating to adopt your suggested solution.


no worries, you didn't sound like that at all!


> Again, thanks a lot for your feedback, it is very valuable!


a simpler but very similar example: think of a recursive graph
traversal algorithm that can be customized using contextl and can stop
and resume the traversal at various points. say it needs to traverse
potentially infinite graphs in the background and at various nodes it
needs the user's feedback to make decisions that affect the _rest_ of
the traversal but only on the rest of _that_ path.

so it needs to be able to stop and resume the traversal at multiple
nodes at the same time. whenever its stops, it needs a way to capture
the current dynamic context (including the layer instance and its
slots), so that it can be restored when the user comes back and anwers
the question that made the traversal on this path to halt.

if you add one more requirement, that some of the customizations are
parametrized, then you get into a situation that is similar to ours.

hth,

-- 
 attila