I expect you'll do something like: object MyRecord extends Record[MyRecord] with JDBCPersistance
or object MyRecord extends Record[MyRecord] with JPAPersistance As Marius said, the semantics are the same (save, add, find, etc.) but the actual thing doing the work (JDBC, JPA, XML, LDAP, etc.) varies. On Mon, Nov 3, 2008 at 5:28 AM, Derek Chen-Becker <[EMAIL PROTECTED]>wrote: > I think it would be best to keep the non-DB stuff in record separate from > the DB stuff. That would allow us to, say, easily use JPA for persistence > since you could just layer the Record trait(s) onto existing JPA entities. > > Derek > > > On Mon, Nov 3, 2008 at 5:08 AM, Marius <[EMAIL PROTECTED]> wrote: > >> >> I've been working quite a bit on it but there are more stuff to be >> implemented. I mostly implemented the "generic" aspects of Record/ >> Field etc. so they are decoupled from DB aspects. DB implementation >> still pending. For a generic record server the following is >> implemented: >> >> 1. Support for mutable and immutable records >> 2. A handful of fields implemented (more needs to be added) >> 3. Support for rendering a Record into a Form based on a a "hard- >> coded" XHTML template .. should be fine in may simple cases. (Renders >> label, input, and lift:msg for validation messages) >> 4. Support for rendering a Record into a Form based on an any given >> XHTML template - allows to model the form layout freely.(Renders >> label, input, and lift:msg for validation messages) >> 5. Support for server side type-safe validation .. a list of >> validation functions can be provided and of course a specific field >> validation can depend on the value of some other field's >> 5. Lifecycle callback called before and after validation >> >> I'm still not sure if a generic Record should have save/delete/update >> functions since a generic Record is not hooked to any backend so it >> semantics are not related to a persistence store. It just can be used >> to "model" forms etc. Currently a DBRecord (which extends a Record) >> has these functions. So what do you say ... should those be defined in >> Record or to remain in DBRecord? >> >> More for me to do: >> >> 1. Completed the list of supported fields (without DB specifics ... I >> think David will step in here ... hopefully someone else can help here >> to speed up things?) >> 2. Fix potential bugs. >> >> P.S. >> No DB specific stuff yet - remains to be added >> >> Br's, >> Marius >> >> On Nov 2, 11:18 pm, "David Pollak" <[EMAIL PROTECTED]> >> wrote: >> > I have a review on my to-do list. I'm the blocking factor here. >> > >> > On Sun, Nov 2, 2008 at 1:09 PM, Tim Perrett <[EMAIL PROTECTED]> >> wrote: >> > >> > > Hey all, >> > >> > > Just thought id drop a quick line to see how the record / field branch >> > > was progressing? I keep getting updates to that branch in my local >> > > git, so I can only guess things are moving along well? :-) >> > >> > > Cheers >> > >> > > Tim >> > >> > -- >> > 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 >> >> > > > > -- Lift, the simply functional web framework http://liftweb.net Collaborative Task Management http://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 [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 -~----------~----~----~----~------~----~------~--~---
