On Mar 31, 5:06 pm, Clemens Oertel <clemens.oer...@gmail.com> wrote:
> Sorry for the delay in my response, but I only get to play with lift
> on the weekends, and I wanted to look into your suggestions in more
> I ported the toForm code from Record to Mapper (and by port, I mean
> mostly cut'n'paste). While doing so, I noticed 2 things:
> - Why not provide the same template mechanism used for forms for HTML
> output? This way I can reuse the same template for both - given that
> my records have at least dozens, if not even hundreds, of fields,
> that'd be a great help.
Well you can load templates from an html file. Please see
> - The templates require the use of <lift:field> and similar tags. I
> thought I'd be really smart, and created a HTML file A with lift-tags
> (<lift:SomeClass.add>...</lift:SomeClass.add>) to run my snippet, and
> used the <lift:field> tags as children to <lift:SomeClass.add>. This
> way, I can create my templates externally, and use the normal lift
> dispatch-from-view mechanism. And, to save me some more work, the
> actual form template is in a separate, reusable, HTML file B, to be
> embedded into A. Embedding, of course, requires eager evaluation.
> Fine. No. With eager evaluation, lift of course complains that there
> is no class "field", as referenced by <lift:field>. Now me's wondering
> whether a separate namespace would be more appropriate? (I did switch
> to a different namespace, liftf, out of necessity, but I figure that
> other people might have similar issues)
Well I can understand the urge but we do NOT recommend processing
templates outside of rendering pipeline. You can call
LiftSession.processSurroundAndInclude so that lift tags to be
processed etc. but again it is not recommended. The main reason is
that your functions that you assume to be bounded during this off-
cycle template processing, will not actually be bounded cause it i
happening in the wrong place.
The Record's form template is to allow you to shape the form in any
way you like (from markup perspective). But this template is supposed
to be very very lightweight in terms of lift's tags. It is just an
xhtml fragment and not a full blow page/(lift template).
> As to the original discussion: I still strongly believe that toForm
> and to/as(X)Html should not be in Mapper/Record. Different story for
> JSON/XML/SQL - those seem to me to be rather functionality complete,
> no problem.
> But form and html creation seem to be something that most users will
> want to adapt to their application's needs eventually - state
> the examples that I've seen so far, this functionality was dealt with
> in the snippet. So, either mapper/record eventually become this super-
> omnipotent-mega-classes that can deal with this functionality to
> form/html generation happens in multiple locations, or the user has to
> override some functions from mapper/record/fields. My beef with this
> is A) that the respective function calls, given their current
> signature, require the respective mapper/record-objects to be fully
> aware of application state for more complex applications; and B) that
> it is my understanding that overriding internal classes of a framework
> is a bad thing - I'd rather see a proper application of the Hollywood
> Just wanted to provide an outsider's feedback. Overall, I think lift's
> just fantastic.
I'm really glad you like Lift !
> Thank you for listening/reading,
> On 19-Mar-09, at 1:08 PM, marius d. wrote:
> > On Mar 18, 11:24 pm, Clemens <clemens.oer...@gmail.com> wrote:
> >> Thank you for your patience, Marius.
> >>> Well you can use different RecordMeta implementations if you need to
> >>> different representation of a record without sequential template
> >>> change. So no state dependency.
> >> , b I'm really not trying to be difficultut having multiple
> >> RecordMeta
> >> instances, for which the HTML output seems to be only one of many
> >> functionalities, seems to be shooting with canons at sparrows. Having
> >> a toForm functions that takes some template provider as input could
> >> be
> >> one option.
> > Well this is kinda already in there but it's private :) ... See:
> > private def _toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
> > so to me makes sense to relax it ... to
> > public def toForm(inst: BaseRecord, template: NodeSeq): NodeSeq
> > ... thanks for reminding me about this :)
> >> Anyways, I was not even thinking at record level, but rather at field
> >> level. See below.
> >>> 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
> >> (Btw, by "context" I meant different HTML display contexts.)
> >> I agree that a field should be able to provide hints about how it
> >> should be represented, such as max/min length, type, defaults, etc.
> >> Depending on the logical context within the app I'm working on, a
> >> record (and thus its fields) can have multiple representations: row
> >> in
> >> a table, complete record as a table, abbreviated record as a table,
> >> complete form as table, form as row in a table, form with mandatory
> >> fields only, records have to be printed out as ini-files, etc.
> >> Unfortunately, it's not me making this stuff up, it's fixed
> >> requirements.
> >> At field level, there are also different possible representations.
> >> For
> >> example, I would like to be able to represent a record as a tabular
> >> form, with every input field being shown with its preferred length.
> >> In
> >> addition to this, I would like to have a different form with a fixed
> >> with multi-column layout; for this form, no input field must be wider
> >> than 40 characters. Somehow I have to tell the fields not to make
> >> themselves wider than 40 characters, and not just use the maximum
> >> length.
> >> Again, what it boils down to is the desire to be able to have
> >> different representations for a single record, and to have different
> >> possible representations for each field. This while maintaining as
> >> much encapsulation as possible.
> > Well for both mapper and record you have the toForm function which is
> > per field thus allows you to represent the field in any way you like:
> > your own Node, augment the default node with new attributes etc. And
> > your implementation can of choose the layout based on your own
> > context.
> >> Hence my original idea to have fields provide representation hints
> >> (eg. "I'd like to be 80 characters wide"), and then have another
> >> "something" that uses these hints for the actual output, while
> >> potentially adding additional hints/constrains (eg. "No one get's
> >> more
> >> than 40 characters"), css directives, a little red star in front of
> >> mandatory fields (based on a rendering hint), .... Depending on how
> >> the record is being displayed, I would use a different "something",
> >> and neither the record nor the fields would have to know anything
> >> about "application context".
> > Well since you can override the toForm for each field you can add your
> > own "something" to it. Thus you can work with necessary abstractions
> > to make the field "unaware" of the "application context" if that's
> > what you want but it feels to me that this is an application specific
> > concern and not a framework one. Personally if I'd need to render a
> > record/field in different layouts using mapper I'd probably make the
> > fields aware of the context in which they need to render themselves.
> > Context is good ! :)
> >> If I then had a default "something", which renders fields the way
> >> they
> >> are rendered right now, and have the various record fields
> >> (StringField, etc.) call upon this default "something" whenever their
> >> toForm-function is called, no one would notice something has changed.
> >> But I could also call toForm(formRenderer) for non-default rendering.
> >>> 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 :)
> >> Agreed.
> >> Best,
> >> Clemens
> Clemens Oertel
> Clemens Oertel
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at