[Lift] Re: http://mvnrepository.com/ - In case you didn't know.
mvnrepository.com is listed in http://liftweb.net/index.php/Maven_Mini_Guide mvnrepository.com only index central repo, it is also obscure how to define tag, ... (after migration, some groupId will be mirrored into central repo, included net.liftweb if you're OK) /davidB On Mon, Nov 3, 2008 at 4:39 AM, David Pollak [EMAIL PROTECTED] wrote: Why is Lift itself not listed? On Sun, Nov 2, 2008 at 5:00 PM, TylerWeir [EMAIL PROTECTED] wrote: I was looking for the appropriate definition for the Envers library and I found nothing about it, so I had to poke around the maven repository looking for the right groupId and artifactId. That's because I didn't know about http://mvnrepository.com/. Had I used it, it would have taken 5 seconds instead of 20 minutes. So, learn from my mistakes. :) -- 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 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 -~--~~~~--~~--~--~---
[Lift] Re: How's the record / field branch coming along?
+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 On 3 Nov 2008, at 13:33, Marius wrote: 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[Lift] Re: How's the record / field branch coming along?
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 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 -~--~~~~--~~--~--~---
[Lift] Extending lifts template loader...
Hey guys,
Myself and Ty have just been chatting about lifts template loader...
right now, is there a way of adding additional places to look for lift
templates?
I see this being of use for two reasons:
- loading page content from a database (which a lot of apps do). The
only thing with this would then be how to cache the pages in a
lift'esq manner (as i know the lift rational doesnt like caching)
- loading page content from elsewhere on a filesystem other than the
webapp folder
Just a bit of sudo code, but something like this would be good:
object MyDatabaseLoader { ... }
LiftRules.templateLoaders = List(MyDatabaseLoader,
defaultTemplateLoader)
Thoughts?
Cheers, Tim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[Lift] Re: Extending lifts template loader...
Well .. findTemplate first splits the name argument and does a lookup
for that path. If template is not found then it looks in templates-
hidden.
But besides that LiftRules.addTemplateBefore/After would not suffice?
See type TemplatePf = PartialFunction[RequestState,() = Can[NodeSeq]]
so you should be able to load the template from virtually anywhere ...
Br's,
Marius
On Nov 3, 6:19 pm, Tim Perrett [EMAIL PROTECTED] wrote:
Hey guys,
Myself and Ty have just been chatting about lifts template loader...
right now, is there a way of adding additional places to look for lift
templates?
I see this being of use for two reasons:
- loading page content from a database (which a lot of apps do). The
only thing with this would then be how to cache the pages in a
lift'esq manner (as i know the lift rational doesnt like caching)
- loading page content from elsewhere on a filesystem other than the
webapp folder
Just a bit of sudo code, but something like this would be good:
object MyDatabaseLoader { ... }
LiftRules.templateLoaders = List(MyDatabaseLoader,
defaultTemplateLoader)
Thoughts?
Cheers, Tim
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
