I like the Lift framework. It has its rough edges, but it's a great way to get into web app development using scala. It borrows many good ideas from other frameworks, most notably its convention over configuration structure (rails) and its scriptless view layer (wicket).
One thing I'm not a big fan of is its baked-in database layer, the Mapper (now in flux and being reborn as Record), and so was pleased to find the JPA archetype in the 1.1 tree. Using this archetype, you get a barebones but functioning lift app using pure JPA. This is a great start, but when I poked around the snippets I saw two things that troubled me: The underlying entity manager API leaks directly into what would be the service layer API; a single object exposed as Model. The snippet code is hardwired to Model, which uses it directly as a global DAO. This archetype is still in development, and it very well may change. It's carries a nature of being experimental; showing you how it can be done, but probably not how it should be done. However, it highlighted an issue I have with Lift, one that the boring enterprise crowd has solved: dependency injection. I have an admittedly specific idea in mind for what I want to implement in my would-be Lift app: I want to be able to declare a few fields and annotate them so that a layer above will provide me with acceptable instances. Yeah, I want to inject DAOs in the oh-so-familiar Guice/Spring/T5 IoC way. I like this partially because it's familiar, but also because it provides me with loosely coupled code. There's been some good discussion on the subject of implementing dependency injection in Scala using mere language constructs. I dove into this subject, starting with chapter 27 of [http://www.artima.com/shop/programming_in_scala]: "Modular Programming Using Objects." It's a good read, and I recommend the book. After that I found my way to some relevant posts in the blogs of Debasish Ghosh and Jonas Boner, respectively: http://debasishg.blogspot.com/2008/02/scala-to-di-or-not-to-di.html http://jonasboner.com/2008/10/06/real-world-scala-dependency-injection-di.html Very cool indeed, but I've slightly digressed. What I want to explore is how to loosely couple the persistence implementation (be it JPA, JDO, or a baked in model) with the accessing of persistent objects. I don't see how the aforementioned technique (the "cake" pattern) would help in the case of lift snippets, because we don't have any kind of hooks where we can provide configuration of snippets (at least, not that I know of). This is exactly the issue that DI solves. So what are the thoughts of the lift-power users? Is there a way to get this in lift, or would you say that I am doing it wrong? sincerely, chris --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
