Hi Mark,
Am 04.10.2012 um 00:06 schrieb Mark Cox:
Hi Frank,
Thanks for your example. My apologies for requiring you to repeat your answer from last month. I found your post not long after I posted.
From your example, and other examples that use the FAMILY class, the KIDS are instantiated at the same time as the FAMILY instance. In my case, the KIDS are instantiated at different times and then "connected" in the future. I have an attempt at the end of the email which is based off your example. It does not work, and I am not sure why.
I noticed in your examples that you use macros. Is there something significant about that?
Thanks Mark
From looking at your code there are a couple of points to be noted:
1. Use of macro c?
This is a macro. As such it is evaluated at macro-expansion time. Using it as a value to be bound to a slot value (as you do in #'make-controller) is not of any meaning - it will return a cell slot that is then assigned as a value to slot item-index in the view instance.
So: You cannot use c? at runtime as a value-returning form.
2. Assigning / creating cells or cell rules via c? and the likes
There are two points in time where these can be used: At macro expansion time and at instance creation time (when initargs are being evaluated). This is based on how Cells acts on slot definitions. The macros (!) defmodel and defmd (which is just a short version of defmodel) are examining the class definition when the reader seas the defmodel / defmd form.
If you look at the output of the observer then it is clear that the value of the slot item-index is not a "normal" value but a cell definition/cell instance.
This means: Assigning cell rules at execution time is possible but not via c?.
3. Use macros
Points 1 and 2 lead to the "style" I showed using macros to create means for making instances with cells-enabled slots. You may want to use macroexpansion to look at what defmodel creates. The macro defmodel is defined in file defmodel.lisp in the cells source code.
Note to other readers of this message: Yes, this is a simplified if not, strictly speaking, incomplete answer. I hope, though, that it makes clear some principles and provides enough guidance to overcome initial Cells hurdles.
4. Dependency pattern design
The Controller is not really a "bridge" between model and view. You try to implement a direct dependency between the model and view via
(setf (item-index view) (c? (let ((m (model (fm^ :root)))) (item-index m))))
in #'make-controller.
If you created a slot view-item-index and also a slot model-item-index in the controller class then you would, with a bit more effort, be able to express dependencies between those two new slots at controller level. In the view then you'd have to create a cell rule that forms a dependency on view-item-index in the controller. All in all a different pattern that would require a different sequence of instance creation: model -> controller -> view. The view then would have to register itself with its parent, the controller.
Hope this helps! (Have you looked at the examples provided by Kenny ?)
Frank