On Mar 18, 8:54 pm, Clemens <clemens.oer...@gmail.com> wrote:
> > Yes I am referring to toForm but note that you can provide your own
> > template. Please see formTemplate.
> I did, thanks for the pointer. formTemplate applies to the record as a
> whole, right? If I want to render a record differently, I could set
> different templates one after the other - even though this introduces
> more evil state dependence.

Well you can use different RecordMeta implementations if you need to
different representation of a record without sequential template
change. So no state dependency.

> Just trying to figure out how to how to solve my case where a field is
> supposed to be rendered differently in different contexts - a single
> asXHtml variable doesn't seem to allow this.
> Also, all the formatting happens in what I thought was the DB
> abstraction layer, which still makes context-sensitive formatting
> difficult (again, as I understand things right know) - it's just
> personal style, but I like to keep control flow and view stuff outside
> my data models.

Well keeping close view representation and backend abstraction makes a
lot of sense as it reduces lots of complexity. Having records/mappers
that know how to represent themselves in different contexts (DB,
xhtml) brings a lot of benefits an simplicity. I admit thought that
it's quire a paradigm shift from ... say MVC mindset. But let's not
get into a "patterns" debate now .. we had plenty of those :)

> But record promises to give me a lot more flexibility than mapper,
> that's great.
> > I think the existent scaladocs can
> > be quite helpful.
> Point taken ;-)
> > Nevertheless for youimediate needs the Record is probably not very
> > relevant yet as DB for Recrd is not yet implemented. I was just
> > pointing out that forms&form validations are consistently provided by
> > Record. I think there is still some level of validation in mappers but
> > I haven't played with it yet ...
> Oh, the validation is working just fine with mapper. It's only the
> lack of flexibility with respect to automated output that's I'm
> talking about.

I'm sorry maybe I'm missing something but can you give a Minimalistic
example that would yield the lack of flexibility of Mapper for your
needs? Perhaps we can improve things or perhaps certain things are
already there waiting to be discovered.

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

Reply via email to