Naftoli, I agree - it should be possible to break this stuff out into traits so that we have a tight record library... for the most part, I cant see myself using Record for anything other than custom backends so it makes sense to break out the things that are not mandatory.
Cheers, Tim On 29 Sep 2009, at 16:44, Naftoli Gugenheim wrote: > > Besides for actual dependencies, Mapper and Record were designed for > web apps, which is why they have asHtml and toForm etc. Personally I > don't like that design very much. DPP says it's more convenient for > the application programmer if it's all in one place, but if it's not > too late to make a fundamental change, wouldn't it be possible to > achieve that with traits? > The least breaking way to do it that makes sense from a library > design perspective that comes to mind, is to have classes with the > same names with a HtmlMapper trait already mixed in. So > net.liftweb.mapper.web.LongKeyedMapper, says, has the same API as > the current LongKeyedMapper, but it's achieved by mixing in a trait. > Or leave it in the same package and put the core parts of mapper in > a mapper-base module / mapper.base package. > This will also have the advantage of allowing other objects to > provide toForm/asHtml etc., by having HtmlMapper extend a base trait. > > > > ------------------------------------- > Timothy Perrett<timo...@getintheloop.eu> wrote: > > Tim, I couldnt agree more! > > However, Record also has a dep on lift-webkit from S.funcMap which we > really need to refactor / remove. Likewise for asJS methods which pull > a dep on lift-webkit. > > Cheers, Tim > > On 29 Sep 2009, at 14:39, Tim Nelson wrote: > >> Aren't most of the dependencies that Record relies on coming from >> the RDBMS code? >> >> Would it make sense to move that code to a separate module (lift- >> record-rdbms)? >> >> I don't like all of the dependencies that Record relies on because >> I'm not using the RDBMS code, I'm using a custom Record back end. >> >> It would be nice to have Record a completely separate module, but I >> think at least moving the RDBMS and therefore the Mapper dependency >> to a separate module would be very easy and remove most of the >> dependencies. >> >> Tim >> >> On Tue, Sep 29, 2009 at 8:01 AM, Timothy Perrett <timo...@getintheloop.eu >>> wrote: >> >> This is my point - record should be more abstract... we dont want it >> depending on all that stuff.... its pointless. >> >> @dpp or @marius... what are your thoughts? >> >> Cheers, Tim >> >> On 29 Sep 2009, at 12:44, Indrajit Raychaudhuri wrote: >> >>> >>> lift-record depends on lift-mapper and since lift-mapper is heavily >>> dependent on lift-webkit, lift-record ends up depending on lift- >> webkit >>> as well. >>> >>> So at the moment, lift-record would end up depending on lift-webkit >>> (and >>> lift-widget!) indirectly even if you remove reference to lift-webkit >>> (superfluous) from lift-record pom. >>> >>> lift-widget part is simpler (just one reference in MappedInt, intend >>> to >>> take up later if somebody else don't beat me) but lift-webkit looks >>> lot >>> of work. >>> >>> Cheers, Indrajit >>> >>> >>> On 29/09/09 3:12 PM, Timothy Perrett wrote: >>>> >>>> Guys, >>>> >>>> I just noticed that lift-record depends on lift-webket because of >>>> some >>>> calls to S... IMHO, we need to remove this because thats simply too >>>> tight a coupling between the webkit and an abstract persistence >>>> interface like record. >>>> >>>> For instance, one record abstraction I wrote isn't even used in >>>> webapps... >>>> >>>> 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 liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
