Thanks David,

I hacked together some auth/restriction code built on JPA, based on the 
ProtoUser source (pretty simple). I've said before that I didn't really 
like Mapper (haven't played with Record), but my real concern, as seen 
in other threads, is a that snippets are explicitly coupled with their 
world. If I want to load entities, I must directly call a service, or 
directly call a factory to get the service - either way there's an 
explicit tie between the snippet and the outer world (either the service 
or its factory).

I put together a simple example to achieve DI in pure scala, using a 
function on the snippet with an implicit parameter. It's Ok, but because 
an implicit value must be in scope to satisfy the compiler, the implicit 
value still has to live in the snippet. This is my most significant 
gripe about snippets - there's no way to get dependencies without asking 
for them directly. I'm still chewing on this, and while I won't advocate 
a full on IOC container, some way to provide deps would be nice. Maybe 
some kind of partial function list designated for snippets, which can 
provide deps in a kind of callback manner. Maybe that's too dirty, but 
I'm just thinking of possibilities.

thanks again,
chris

David Pollak wrote:
> 
> 
> On Sun, Aug 30, 2009 at 8:21 AM, Chris Lewis <burningodzi...@gmail.com 
> <mailto:burningodzi...@gmail.com>> wrote:
> 
> 
>     Thanks David,
> 
>     That does help, yes. My first toy app, which I wrote for a company demo,
>     used lift 1.0 and mapper. I dug into the MegaProtoUser source and
>     remember how it worked (providing its own site menu configurations with
>     access control there). Role-based restrictions could be done much the
>     same way. Part of my issue with that is probably invalid - I'm
>     accustomed to the practice of such configurations being stored outside
>     of application code (XML).
> 
>     Having known that, I guess my question was focused more on how lift
>     remembers the user. I think it was using the S object, which ultimately
>     stores keyed objects on the session, right?
> 
> 
> The MegaProtoUser keeps the primary key of the current user around in a 
> SessionVar.
> 
> SessionVars are a strongly typed layer on top of a hashtable that's 
> secretly stored in the LiftSession.
>  
> 
> 
> 
>     Thanks again for your dedication and commitment to the lift community.
> 
> 
> Sure thing... I'd great to have lots of people learning Lift and 
> building cool things and driving the requirements...
> 
> 
>  
> 
> 
>     chris
> 
>     David Pollak wrote:
>      >
>      >
>      > On Thu, Aug 27, 2009 at 6:42 PM, Chris Lewis
>     <burningodzi...@gmail.com <mailto:burningodzi...@gmail.com>
>      > <mailto:burningodzi...@gmail.com
>     <mailto:burningodzi...@gmail.com>>> wrote:
>      >
>      >
>      >     Lift users,
>      >
>      >     I'm curious what you all are using for user access control
>     (Mapper users
>      >      excluded). I'm seriously evaluating lift for a project that
>     will use
>      >     JPA. My full time job uses Spring Security, which while nice
>     in that it
>      >     stays out of the way, is too clunky for my tastes. I haven't
>     dissected
>      >     how lift implements it with Mapper, but wanted to ask the
>     group first.
>      >     Thanks!
>      >
>      >
>      > For HTML access control, Lift's SiteMap offers URL level
>     protection of
>      > pages (and menu generation based on the access control rules.)
>      For each
>      > Loc (location) in your sitemap, you can chain together If() and
>     Unless()
>      > clauses to define what rules are applied to each page.  These
>     rules are
>      > based on invoking functions (e.g., User.superUser_?) and can be
>      > arbitrarily complex.
>      >
>      > For protecting non-sitemap resources (stuff that's served up via a
>      > custom dispatch [DispatchPF]), it's best practice to put a guard
>     in the
>      > partial function:
>      >
>      > {
>      >   case Req("api" :: "accounts" :: Nil, _, GetRequest) if
>      > currentUserCanViewAccounts_? => renderAccounts _
>      > }
>      >
>      > Hope this helps.
>      >
>      >
>      >
>      >
>      >     chris
>      >
>      >
>      >
>      >
>      >
>      > --
>      > Lift, the simply functional web framework http://liftweb.net
>      > Beginning Scala http://www.apress.com/book/view/1430219890
>      > Follow me: http://twitter.com/dpp
>      > Git some: http://github.com/dpp
>      >
>      > >
> 
> 
> 
> 
> 
> -- 
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> 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 
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to