Ok, I had never looked at the source for S or LiftRules, but just poked around in S and some dots connected. Assign different functions to the S var members and you change functionality. Cool! Different than what my mind defaults to, but so simple.
(You can see I have some baggage, and I am happy to let it go.) Forgive my ignorance, and this issue probably has more to do with my newness to scala rather than lift, but I don't see how your trait example allows one to "construct" the snippet. Take a payment service example. I start off with PayPal and some months later I switch my processor to CyberSource. I don't want to tie the snippet to a specific processor, so my mind, transposing java, says to write a payment service interface and implementation (of course there's a DI container that manages the wiring). In scala, if I mixin a trait that provides the payment service implementation, I still have to change the trait being mixed in if I want a different implementation. That, or have the trait itself resolve the implementation, which is plumbing that would have to be repeated per dependency-bearing trait. This sounds messy and like a maintenance headache - I feel like I'm missing your point here. I get the answer to "mocking" lift internals, but hot-swapping service implementations without incurring a maintenance hit is still unclear. Thanks again! sincerely, chris David Pollak wrote: > > > On Tue, Sep 1, 2009 at 5:56 AM, Chris Lewis <burningodzi...@gmail.com > <mailto: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 > <mailto: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 -~----------~----~----~----~------~----~------~--~---
