On Tue, Mar 31, 2009 at 7:06 AM, Clemens Oertel <[email protected]>wrote:
> Hello, > > 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 detail. > > 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. > - 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) > > > 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 dependent css > classes, javascript validation, AJAX form updates... In 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 > (field.toJavaScriptValidatingAndIncrementallyAjaxUpdatingForm ...), or > 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 principle. > Most web sites I've worked on, there's a default way to display a form and that default is encapsulated in the model itself. This encapsulation does not bar you from building your own form renders, but it does give you nice default behavior. > > Just wanted to provide an outsider's feedback. Overall, I think lift's just > fantastic. > > Thank you for listening/reading, > Clemens > > On 19-Mar-09, at 1:08 PM, marius d. wrote: > > > > > On Mar 18, 11:24 pm, Clemens <[email protected]> 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 > [email protected] > > > > > > Clemens Oertel > [email protected] > > > > > > > -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
