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
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
