One follow up question, relating to the contexts I mentioned earlier:  
Following my approach mentioned below, let's assume I have a template  
for embedding. This template contains  the HTML code for a tabular  
list of data entities. Depending on where the template is embedded,  
some of the entities' fields should appear as links: There are 2  
linkable reference fields A and B, and depending on the context,  
either A, B, or A and B should be rendered as links to the referenced  

This logic obviously can't go into the template. Also, the model's  
toForm method is unsuitable (having the model referring to a  
RequestVar seems evil to me). No no, this should go into the snippet,  
where such logic belongs. But this would mean having to go through the  
templates XML tree before calling Site.toForm(site, form), enclosing  
all affected liftf:field elements with the respective links. This  
sounds very, very wrong.

Thus, from my current understanding, this context-sensitive rendering  
of fields is best done using the explicit lift-tag/bind approach. So  
I'll probably have to have explicit bind calls anyways, and won't be  
able to use my initial approach of having the mapper class (or it's  
companion object) fill out the forms itself.

I'd be happy if someone could prove me wrong ...


PS: Exercise for the reader: Instead of selective linking, have only  
either A or B be displayed, depending on the embedding context.

On 31-Mar-09, at 3:59 PM, marius d. wrote:

>> ---- Outer Template ----
>> <lift:surround with="default" at="content">
>>    <h2>Create a New Site</h2>
>>    <lift:snippet type="SiteOps.add" form="post" eager_eval="true">
>>      <table>
>>        <tfoot>
>>          <tr>
>>            <td colspan="3"><site:submit>Submit</site:submit></td>
>>          </tr>
>>        </tfoot>
>>        <lift:embed what="/sites/_site" />
>>      </table>
>>    </lift:snippet>
>> </lift:surround>
>> ---- End Outer Template ----
>> ---- Embedded Template ----
>> <tbody>
>> <tr>
>>      <td><liftf:field_label name="name">Name</liftf:field_label>:</ 
>> td>
>>      <td><liftf:field name="name">A Hospital Site</liftf:field></td>
>>      <td><liftf:field_msg name="name" /></td>
>> </tr>
>> </tbody>
>> ---- End Embedded Template ----
>> ---- SiteOps ----
>>    def add(form: NodeSeq): NodeSeq = {
>>      val invokedAs = S.invokedAs
>>      val site = Site.create
>>      def newSite(form: NodeSeq): NodeSeq = {
>>        def saveMe(): Unit = {
>>          site.validate match {
>>            case Nil => ; S.notice("Added " +;
>> S.redirectTo("/sites/")
>>            case xs => S.error(xs) ; S.mapSnippet(invokedAs, newSite)
>>          }
>>        }
>>        bind("site", Site.toForm(site, form), "submit" ->
>> submit("Save", saveMe))
>>      }
>>      newSite(form)
>>    }
>> ---- End SiteOps ----
>> The Site.toForm function is pretty much the same as found in
>> MetaRecord. It will eventually call each fields' toForm function
>> (which are the original Lift 1.0 mapper versions, no changes there).
>> Am I really doing things outside the rendering pipeline (this is  
>> not a
>> rhetorical question)?
> Nope sorry ... I misunderstood your case. By bad entirely.
> It all seems to work, incl. validation.
>> Also, the eagerly evaluated template, which will be passed to toForm,
>> contains only field tags, no other lift tags.
>> Again, imagine a few dozen different entities, each with a ton of
>> fields. I'm sure you'll understand that I'm hesitant to bind each
>> field manually (once for the list page, once for the display page,
>> once for the add page, and again once for the edit page, even though
>> the last 2 can surely be combined into one bind call in the code).
>> I obviously have to declare each field in the model, and refer to it
>> in the view. I really wouldn't mind not having to mention it anywhere
>> inbetween.
> This is actually a nice thing to do. Sorry that I misunderstood your
> intentions :)
>> Thank you for all your help,
>> Clemens
>> Clemens Oertel
> >

Clemens Oertel

Clemens Oertel

You received this message because you are subscribed to the Google Groups 
"Lift" group.
To post to this group, send email to
To unsubscribe from this group, send email to
For more options, visit this group at

Reply via email to