How's the record / field branch coming along?

[Tim Perrett]

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

[David Pollak]

I have a review on my to-do list.  I'm the blocking factor here.

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

[Marius]

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" <feeder.of.the.be...@gmail.com>
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 <he...@timperrett.com> 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

[Derek Chen-Becker]

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

[Marius]

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" <dchenbec...@gmail.com> 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
>

[David Pollak]

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.

Lift, the simply functional web framework http://liftweb.net

Collaborative Task Management http://much4.us

[Tim Perrett]

+1.

Any given persistence provider back-end (like yo say, LDAP, JPA etc)
should be required to implement these as part of there implementation.
I don't think they should have a default behavior however...

Now wanting to open another pandora's box, but out of interest, how
will the validation stuff tie into the Record?

Sounds like things are moving on swimmingly. Great work guys!

Cheers, Tim

[Marius]

On Nov 3, 5:15 pm, Tim Perrett <he...@timperrett.com> wrote:
> +1.
>
> Any given persistence provider back-end (like yo say, LDAP, JPA etc)
> should be required to implement these as part of there implementation.
> I don't think they should have a default behavior however...
>
> Now wanting to open another pandora's box, but out of interest, how
> will the validation stuff tie into the Record?

The best answer would be to look at the code :) ... but in a glance
here it is:

1. For each Field you can add virtually any number a validation
functions. Each validation function takes parameter the type of the
field (Int, Long String etc.) and returns a Can[Node]. If Can is Empty
the validation passed. Otherwise the Node impersonates the error text
that will be shown as validation message.
2. In the validation function you have access to all other Record
fields if you have fields dependency validation.
3. When you call validate on a record it will subsequently call all
validators for each field and Return a List[FieldError]. having this
list you can pass it to S.error for example in order to set the
validation messages into the form

I could probably send you off line later on today a code example.

[Tim Perrett]

Sounds great Marius.

Sounds like this is all coming together very nicely! Excellent work
chaps.

[Tim Perrett]

Marius,

The example you sent me was super sweet. Thats awesome work guys - im
so glad to see this kind of functionality coming into lift; IMO, this
is the kind of thing that will give lift mainstream appeal.

One thing I got to thinking on and wanted to pose the question - were
talking about having backend providers as traits right? If this is the
case, im guessing that I could create a backend which was a pure api
client (i.e. a lift app that has no direct persistence mech like
mapper or JPA, but rather, creates some kind of soap/rest/other api
call) and just made the relevant calls for the crud operations and
still get all the validation functionality?

Cheers

Tim

[Marius]

Right as currently you just call validate on a Record whenever you
need. Now a backend can mean anything even a B2B bus.Of course the
specific of such backend integration can determine if some specifics
on fields are needed.

P.S.
Just please bare in mind that current stuff is subject for reviews and
perhaps some more modeling.

>
> Cheers
>
> Tim

[Tim Perrett]

> Right as currently you just call validate on a Record whenever you
> need. Now a backend can mean anything even a B2B bus.Of course the
> specific of such backend integration can determine if some specifics
> on fields are needed.

Awesome.

> P.S.
> Just please bare in mind that current stuff is subject for reviews and
> perhaps some more modeling.

I know its mainly your good self and DPP who've been working on this,
so even if its reviewed and changed, I have every faith that whatever
you guys come up with will be absolutely top draw.

Cheers

Tim