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.
I'm really not trying to be difficult, but 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. 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. 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". 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 "Lift" group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
