[cells-devel] family hierarchies

[Ken Tilton]

Andy Chambers wrote:
> Does it cause problems if a family is defined on a slot different from kids?

Yes and no. No because I generalized kids behavior so you now say (as 
you can see in the family class on the .kids slot) ":owning t"), yes 
because you might be the first to use :owning in anger on a non-.kids 
slot and thus you will be the guinea pig to find any places still 
hard-coded to look specifically for .kids, or some other code that makes 
it all work but only for kids.

So go for it but ping me right away if something goes wrong.

> 
> I ask because in a webified cells, you'd probably want to define the
> model on a :page slot or something.
> 
> (defmodel web-app (family)
>   ((page ...)
>    (request ...)
>   (:default-initargs
>        :page (c? (the-kids ....)))
> 
> I've made a few macros based on those in celtk that use cl-who to
> populate an xhtml slot.  The families
> are building up quite nicely now.  I am having one problem though.
> The web pages are constructed using
> macros like this...
> 
> (mk-page (:titile "some page")
>    (mk-div ()
>        (mk-text "hello world")))
> 
> 
> I created a definehtml macro to make a defmodel and a corresponding
> mk- macro for a few of the commonly
> used html elements (I'll do the others as and when required).

Sounds good. If you have either Celtk or Cells-GTk running (or just care 
to look at the source for key macrology such as DEFTK or some such that 
does the moral equivalent of what you are doing) you will see how these 
layers talk to Tk/Gtk to get objects built in their worlds from objects 
built in the Lisp world. I think you are doing the same thing.

>  What
> I'm not sure about is the mk-text for
> simple strings.  On the plus side, I can use a rule to escape special
> characters like & et el.  Another plus
> is that we can put all text inside addressable span elements so if
> only that bit of text updates, we can
> send the appropriate bit of javascript down to the client that
> pin-points the change we want.
> 
> Here's roughly how one of the mk- macros look at the moment.
> 
> (defmacro mk-div ((&rest inits) &body body)
>   `(make-instance
>       'div
>       , at inits
>       :fm-parent *parent*
>       :kids (c? (the-kids
> 		 ,@(loop for kid in body
> 		    when (stringp kid)
> 		     collect (mk-text kid)
>                     else
> 		     collect kid))))))  ;; not sure about the parens here, I edited
> a bit in email

Do you really mean to detect strings only at compile time (which would 
be OK, I am just trying to get this clear) or also at run time? Anyway, 
the macrology looks odd. I am expecting:

(defmacro mk-div ((&rest inits) &body body)
   `(make-instance
       'div
       , at inits
       :fm-parent *parent*
       :kids (c? (the-kids
		 ,@(loop for kid in body
		    when (stringp kid)
		     collect `(mk-text ,kid) ;; <---- backquote
                     else
		     collect kid))))))

ie, you are collecting MK forms, not actual made instances. Then (I read 
ahead some) as long as your mk-text macro adds code to capture 
*fm-parent* or whatever it is you will be ok.

> 
> What I'd really like is to examine the type of each form in body to
> see if its a string.  If so, use the mk-text
> macro to make that string into a family object.

? Did you mean "a family member"? I say that based on the next bit

>  What you see above
> does do that but it doesn't pick up the
> *parent*, presumably because the macroexpansion of the mk-text bit
> happens before *parent* has been
> evaluated.

I guess I am top-posting. :) But I think the only problem is you left 
out a backquote.

>  Maybe the easiest thing would just be to use a really
> short name for the mk-text macro and be
> done with it.

??? Well, let's sort out the other stuff, it might be nothing but a 
little work on that loop.

btw, loop is funny on how it mutates its iteration variables, I 
sometimes end up writing:

     (let ((kid kid))
        `(mk-text ,kid))

...in cases like this.

peace,k