Derek, they are separated. Record itself has no idea about DB. Nevertheless save/update/delete semantic applies for any possible backend (LDAP, JDO, RDBMS ... you name it). So I wonder if save/delete/ update should exist in Record as "dummy" or as they are today only on DBRecord. Personally I prefer them the way they are today (in DBRecord) ... but other people may feel different so I'm opened for valid arguments.
Br's, Marius On Nov 3, 3:28 pm, "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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
