[Bese-devel] :template options referring to data within the "current" component

[marco]

Anthony Juckel <ajuckel at gmail.com> writes:

> I'm still relatively new to the internals of UCW, so the following may
> be a very simple question.

not really no. it's something i would never have thought about doing,
but sounds pretty cool now that you mention it.

> Is there a way to refer to the current component when supplying
> :template options?

for the name of the template, no, for the environment yes.

> For example, I have a set of classes: foo, bar and baz.  The basic
> interaction for dealing with each of these objects is the same, I only
> wish for the template to be different depending on which is being
> edited.
>
> What seems reasonable, would be to have a component defined as such:
>
> (defcomponent editor (standard-component)
>    ((object :accessor object :initarg :object))
>    (:template (get-edit-template-for-object _object_)))
>
> Then, I have get-edit-template-for-object defined for any object that
> I can safely pass to this editor component.  The problem is, _object_
> in the above is an unbound symbol.

the second form in the :template option (the one which creates the
template's environment) _can_ access the current component via the
symbol <name-of-component-class>, however i had always assumed the
template file name would be a string so i didn't consider adding this
to the entire :template option.

> I see that gen-component-default-render-on (from
> standard-component.lisp) generates a defmethod form which gives the
> default render-on implementation when :template is used.  This
> defmethod uses gensyms for the response and component parameters. 
> Would it be reasonable to make one or both of these standard symbols? 
> Users would have to be aware that, for example, 'response and
> 'component are already bound within the body of their :template form,
> but that seems a rather small price to pay to be able to have
> components using templates refer to themselves when deciding on a
> template (or tal environment bindings).  I've made this change
> locally, and in simple tests nothing seems to break.  Does anyone see
> any problems with this approach?

it seems ok with me, but i would continue binding the component to a
symbol of the same name as the component class.

> On the other hand, perhaps I'm reading this all wrong and what I want
> is already available some other way...

what i'd immagine you'd do in this case is something like:

(defcomponent editor (standard-component)
  ((object :accessor object :initarg :object)))

(defmethod rendor-on ((res response) (editor editor))
  (render-template *context* 
                   (get-edit-template-for-object editor)
                   (get-edit-environment-for-object editor)))

that said i see nothing wrong with your solution, though i would like
to think about it a bit more. i'm currently entertaining the idea of
rewriting some the defcomponent stuff to use a much more functional
API, currently there are lots of things the defcomponent macro does
for you which you simply can't do on your own without cut 'n pasting
code from standard-component.lisp.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen