On Mar 19, 7:08 pm, "marius d." <marius.dan...@gmail.com> 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
I used <public> here on purpose ... :)
> ... 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
> > 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
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at