On Tue, Mar 31, 2009 at 7:06 AM, Clemens Oertel <clemens.oer...@gmail.com>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 <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
> clem...@oertel.ca
>
>
>
>
>
> Clemens Oertel
> clem...@oertel.ca
>
>
>
>
> >
>


-- 
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 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
-~----------~----~----~----~------~----~------~--~---

Reply via email to