On Aug 30, 9:03 pm, Chris Lewis <burningodzi...@gmail.com> wrote:
> I am specifically talking about decoupling my web logic, ie, event
> handlers for forms in lift snippets, from the persistence layer. As
> currently implemented, snippets know exactly what persistence mechanism
> is in use because there is no intermediary API. If I'm using Mapper, my
> snippets must use the Mapper api. If JPA, the global EM wrapper "Model."
> The same, I imagine, holds true for the Record api.
Why do you say this holds true about Record? ... Recourd is not bound
to any persistence technology. If you are concerned about Mapper,
means to me that you want a complete abstraction such that you can
replace JDBC with something totally different. Ok, but what stops you
from invoking the Mapper from layer abstracted by application specific
traits?
This makes the
> persistence layer a Leaky Abstraction
> (http://en.wikipedia.org/wiki/Leaky_abstraction), and I want to avoid that.
>
> > Most of DI of Lift is currently done using PartialFunction-s and
> > Function lists that people can set in Boot or for snippets in case on
> > binding functions usign SHtml helpers etc.
>
> Ok, but how does that help me decouple my web logic from the persistence
> details?
The statement was about Lift's DI beyond the context of persistence.
If you want your snippets to not know about Mapper abstract the Mapper
wok with your own traits ... could use a Factory pattern or something
similar.
>
> > What we've learned with Lift is the it is OK to give to persistence
> > objects understanding of rendering. Having dumb objects that carry on
> > just data and rely of layers that can do different jobs (render,
> > persist) is IMO not a very good design approach.
>
> I disagree. An entity, like "Author", is nothing more than an expression
> of a real-world concept modeled in code. It should know about itself,
> its direct constituents (like a "Book" collection), anything else that
> defines its own semantics, and nothing more. How it is stored is none of
> its business.
I didn't quite expect that you would :). We found Lift's approach to
be quite productive in real life apps.
>
> Don't misunderstand me - I accept that I may be missing something. We
> agree that the concept of DI is valuable because it helps us keep
> abstractions loosely coupled. I don't see the problem with annotations,
> but I am not at all married to them.
No worries I think your approach for a debate is a very healthy one.
Having different opinions is OK. I explained one of the problems with
annotations in Scala
***** "The other problem with annotations is that we can't currently
build annotations in Scala to be visible at runtime, so we'd probably
have to code them in Java or use some existent Java annotations ...
but this already smells hacky IMHO. "****
>
> You point at partial functions and traits to implement abstractions over
> the persistence layer, but what is missing is how to apply that to
> snippets. Yes, I could abstract the layer however I want, but my
> snippets we still be required to get at the layer by calling it
> directly, instead of having it provided. Can you share some input on
> that part?
def mySnipetFunc(xhtml: NodeSeq) : NodeSeq = {
val persistence = MyPersistenceFactory.getPersistence();
...
persistence.getBy( --- some predicate ---)
...
}
This is a trivial model ... but in most cases this would be enough. In
many cases I don't really need something that injects a reference to
an annotated class member.
One other approach would be to use a RequestVar or a SessionVar to
hold a Persistence reference and you can access it from different
places. You could set the proper context for such var-s from from our
LoanWrapper added in boot by calling S.addAround.
>
> Thanks for the discussion,
>
> chris
>
> marius d. wrote:
> > Most of DI of Lift is currently done using PartialFunction-s and
> > Function lists that people can set in Boot or for snippets in case on
> > binding functions usign SHtml helpers etc.
>
> > Personally I'm not at all a fan of Pojo/Poji DI by annotations
> > especially in Scala realm where there are other artifacts such as
> > function composition, monads, mixin composition, higher order
> > functions etc. The other problem with annotations is that we can't
> > currently build annotations in Scala to be visible at runtime, so we'd
> > probably have to code them in Java or use some existent Java
> > annotations ... but this already smells hacky IMHO.
>
> > If enterprise folks solve one problem by DI by annotation it doesn't
> > mean that this fits in all contexts.Persistence loosely coupling can
> > be achieved in many ways:
>
> > 1. Implement your own persistence semantic on top of Record
> > 2. Implement your own traits hence your own abstractions
> > 3. etc
>
> > What we've learned with Lift is the it is OK to give to persistence
> > objects understanding of rendering. Having dumb objects that carry on
> > just data and rely of layers that can do different jobs (render,
> > persist) is IMO not a very good design approach.
>
> > Having snippets invoking the persistence layer is ok, in fact it is
> > natural for applications. Of course with a proper level of persistence
> > abstraction IF there are chances for the application to use a
> > different persistence mechanism then say JDBC. But many application
> > don't really need such a rigorous decoupling so using mapper/record
> > from snippets makes a lot of sense.
>
> > Br's,
> > Marius
>
> > On Aug 30, 6:21 pm, Chris Lewis <burningodzi...@gmail.com> wrote:
> >> 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.htmlht......
>
> >> 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
-~----------~----~----~----~------~----~------~--~---
