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

Reply via email to