On Tue, Sep 1, 2009 at 5:56 AM, Chris Lewis <burningodzi...@gmail.com>wrote:
>
> David,
>
> I'm still investigating options, but I wanted to restate my main issue
> simply. It is the requirement snippets have on global data; that is it.
> The way they receive data from and expose data to templates is really
> nice. However, without the use of global objects (including lift
> infrastructure like S, as well as application-level services), a snippet
> cannot do anything useful. Instead of expressing dependencies via
> constructor or function arguments, snippets must reach out.
And where do these constructor parameters come from?
How is:
class Foo(snippetConstructors: XX) extends Snippet {
}
Any more abstract than:
class Foo with MyProjectState {
}
where:
trait MyProjectState {
def snippetConstructor: XX
}
> Calls to
> factories provide a way to ask for dependencies, but again binds the
> snippet to a specific factory (which in turn requires dependencies be
> configured such that a specific factory can provide them).
>
> I see this as problematic. I don't want spring in the mix, and I share
> the disdain for java annotations in scala - but there has to be a better
> way than globals.
>
S is not global. Sure, it appears to be global, but it's not.
There's nothing magic about S. You can create your own.
You can also have a trait that configures itself on construction and you can
mix that trait into your snippets.
Either of these solutions gives you the ability to achieve your goals...
I'm not sure why you object to the S/factory paradigm. At some point, the
turtles end and you have to provide a mechanism for associating the
abstraction (trait/interface) with some concrete implementation. Why do you
view DI magic as a more satisfying mechanism for resolving abstract to
concrete? Personally, I find anything that's magic (rather than concrete
code that I can control, e.g., factory functions, partial functions, etc. to
be much more maintainable.)
>
> Thanks so much for your work and continued engagement.
>
> sincerely,
> chris
>
> Jeppe Nejsum Madsen wrote:
> > David Pollak <feeder.of.the.be...@gmail.com> writes:
> >
> >> Chris,
> >>
> >> I agree with Marius' comments. By using Scala's functions and partial
> >> functions, I have not found any need for Dependency Injection or many of
> the
> >> other Java limitation workaround patterns.
> >>
> >> Snippets are not associated in any way with persistence. Snippets can
> work
> >> any way you want and are not tied to a particular mechanism for storing
> >> data. Snippets are simply a way to transform XML to XML.
> >
> > David. I'm also struggling with some of these issues, mostly due to the
> > fact that I need to supply mocks for testing and not so much because I
> > crave another layer of indirection :-)
> >
> > I think what Chris was talking about was not so much that snippets are
> > tied to any specific persistence mechanism, but more that many (most?)
> > snippets, to do something useful, needs to access some functionality in
> > the business logic. An using a static reference for this makes it
> > difficult to swap BL implementations (ie with mocks). In an IoC
> > container, those dependencies would be injected automatically to the
> > snippet.
> >
> > I'm unsure how this could be implemented in Lift/Scala but would prefer
> > to use the language itself. Chris already showed one possible solution
> > with implicits, but I think there may be better solutions out there. I
> > agree with you on your view on annotations :-)
> >
> > I feel I have a pretty good grasp on using FP "in the small" e.g for
> > algorithms and data structures, but can't yet see how FP constructs
> > (partial functions etc) can be used "in the large" e.g. for composing
> > whole applications. Even more so when combining this with scala's
> > powerful type system.
> >
> >> Scala's traits used in conjunction with runtime logic singletons (e.g.,
> >> LiftRules and S in Lift) mean that you don't need DI or other stuff.
> How
> >> can these things be used together?
> >
> > One of my issues wrt to testing lift apps is actually the use of these
> > singletons. Much of my application code relies on these and requires an
> > elaborate setup to test properly. I can of course extract my own traits
> > for all the functionality that I use in S, LiftRules etc. but this seems
> > like something that could be integrated into lift proper. I'll spend
> > some more time on this and get back when/if I have some suggested
> > improvements :-)
> >
> >
> >> I don't believe snippets need this kind of configuration if you follow
> the
> >> same patterns as we've followed with LiftRules and S.
> >
> > Could you briefly mention these patterns (or point to the code :-)?
> > There's a lot of code in there and, while readable, I don't think I can
> > distill the patterns yet....
> >
> > /Jeppe
> >
> >
> > >
> >
>
> >
>
--
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
-~----------~----~----~----~------~----~------~--~---
