one clarification .. by "by which the only benefit that I see is that
*this* and MyType are actually of the same type sometimes leading to
ease of writing expressions" are really meant that *this* and a that :
MyType having the same type can give certain clarity of the
expression. Just like SLS example 5.3.5


Br's,
Marius

On Sep 22, 11:14 pm, Marius <[EMAIL PROTECTED]> wrote:
> I'll do some noodling on this  ... starting first with understanding
> of the design intent (which I assume it is founded on *ease of use*)
>
> I see that Record follows the same parametrization paradigm ...
>
> trait Record[MyType <: Record[MyType]] {
>   self: MyType =>
>
> ...
>
> }
>
> or
>
> trait MetaRecord[BaseRecord <: Record[BaseRecord]] { self: BaseRecord
> =>
> ...
>
> }
>
> by which the only benefit that I see is that *this* and MyType are
> actually of the same type sometimes leading to ease of writing
> expressions. Is there another benefit?
>
> The non benefit is that user needs to type somehow redundant stuff.
>
> class MyRecord extends Record[MyRecord] {
>
> ...
>
> }
>
> or
>
> class MyMetaRecord[Rec <: MyRecord[MyMetaRecord]] extends
> MetaRecord[Rec] {
>
> ...
>
> }
>
> ... see I already typed MyRecord/Rec twice leading to a certain
> redundancy. To me it is not really a drawback ... but I need to
> understand if this paradigm is buying us a whole lot.
>
> Br's,
> Marius
>
> On Sep 22, 9:05 pm, "David Pollak" <[EMAIL PROTECTED]>
> wrote:
>
> > Folks,
>
> > For those who want to help, but are not yet Lift committers, please contact
> > me off-list and let's chat about you contributing to this project.
>
> > If you're a committer, please look at the the wip-record2-dpp branch.  What
> > I've been doing to start is to try to decompose the Mapper and Mapped*
> > classes in Lift into composable traits in the net.liftweb.record package.
> > Once we have a reasonable set of components we could compose together, then
> > we can start filling in the pieces.
>
> > So... step 1, finish the decomposition of the Mapped* stuff into the Record
> > stuff.  Clean up the stuff that doesn't make sense (e.g., getSingleton ->
> > meta... although this is on Mapper, but you get the idea).  How do we
> > convert the field to/from String, XML, HTML Form, etc.?  What are the
> > validation rules?  What are the access control rules (yes, this is already
> > built into Lift's Mapper stuff)?
>
> > Step 2, decompose the Mapper and MetaMapper stuff in the same way... what's
> > necesssary to map to/from XML, HTML forms, different storage mechanisms etc.
>
> > Step 3, fill in the core functionality... copy and paste whatever valuable
> > code there is from Mapper (note than only about 20% of mapper is JDBC
> > related).
>
> > Step 4, build an abstraction layer for JPA so you can compose a JPA
> > persisted Record just by mixing in the JPA adaptor... and the same for the
> > JDBC adaptor, etc.
>
> > Step 5, write a translation guide from Mapper -> Record
>
> > Questions?
>
> > Thanks,
>
> > David
>
> > PS -- on the validation front, currently, Mapper fields have a
> > List[Function[T, List[ValidationIssue]]] that is the access to the
> > server-side validation rules.  There exist a bunch of functions on
> > MappedString, etc. to do common validations (min len, max len, regex, etc.)
> > In order to get client-side validation, we can have a subclass of Function
> > that implements jsValidation: JsExp  That will be the cue to include the
> > client-side validation in the form as it's being composed.  Cool, huh?
>
> > On Mon, Sep 22, 2008 at 10:42 AM, Alex Cruise <[EMAIL PROTECTED]> wrote:
>
> > > David Pollak wrote:
> > > > I think the stuff that marius has done is interesting, but it is at
> > > > odds with the long promised record/field stuff.
>
> > > > This morning, I figured out how to ask the right questions in order to
> > > > manage the record/field project. If I can get one or two volunteers, I
> > > > think we can get the project done in a few weeks.
>
> > > > Volunteers?
>
> > > I would love to get involved in this, as it's one of my recurring pet
> > > projects.  Unfortunately, like most of us, I don't have a lot of spare
> > > time and my days are pretty much spoken for.  Maybe one way to start
> > > would be for me to spew some of the design ideas I've had in this
> > > department over the past year or so, and see if they resonate?
>
> > > -0xe1a
>
> > --
> > Lift, the simply functional web frameworkhttp://liftweb.net
> > Collaborative Task Managementhttp://much4.us
> > 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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to