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

Reply via email to