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