Just a quick and dirty reply: In order to get OSGi support LiftRules should delegate *everything* to a Collection of LiftModules. LiftModules can be added to and removed from this collection anytime.
Heiko 2009/7/29 Timothy Perrett <[email protected]> > > Ryan, > > I agree with you for the most part - certainly making it explicit would be > my preference also. > > Im not 100% sure that we would need to replicate all the LiftRules > functionality as a trait for plugins, as that's just one aspect of how a > plugin could change the environment. > > Your point about making the developer aware what the plugin actually did is > a good one though - no one likes black boxes. Perhaps the plugin developer > would need to implement some kind of descriptor trait... Meaning that their > actual code just uses the normal LiftRules infrastructure, but during the > loading process perhaps just Log.debug it to death showing exactly how the > environment has been modified or something? > > Just spitballing... > > Cheers, Tim > > > On 29/07/2009 12:31, "Ryan Donahue" <[email protected]> wrote: > > > > > -1 for adding modules by "dropping in" a jar > > > > Suppose the jar supplies multiple Lift modules and I only want to use > > one, or suppose I want to use some other class in the jar and don't > > want to use any of its Lift modules. > > > > Adding a module to a Lift app really should be an explicit action by > > the developer, closer to what Tim does by putting MyModule.init in > > Boot. However, this does have a couple shortcomings: (1) Does not > > provide a mechanism for supplying templates in the module and (2) > > Hides the LiftRules additions from the developer which could result in > > confusion when troubleshooting (did this module prepend or append to > > dispatch? which module's dispatchers are executing first? etc.) > > > > So what about putting something like this in Boot: > > LiftRules.modules.append(MyModule) or LiftRules.modules.prepend(new > > MyModule) where MyModule extends LiftModule and LiftModule is a trait > > like: > > > > trait LiftModule { > > > > /* > > * Specify where to search for snippets, views, etc > > */ > > def lookupPackage : String > > > > /* > > * Specify where to search for templates > > */ > > def templates : Box[String] // or maybe this has a nice default > > value > > > > /* > > * Override this to provide LoanWrappers that will be added by > > S.addAround > > */ > > def SWrappers : List[LoanWrapper] = List() > > > > /* > > * Override this to provide dispatchers that will be added by > > * LiftRules.dispatch.append > > */ > > def dispatchers : List[LiftRules.DispatchPF] = List() > > > > /* > > * Override this to provide dispatchers that will be added by > > * LiftRules.statelessDispatchTable.append > > */ > > def statelessDispatchers : List[LiftRules.DispatchPF] = List() > > > > > > // Etc. Basically there would be an overrideable method for each > > type of > > // thing you can add to LiftRules with nice defaults where > > possible. A module > > // developer only overrides the methods needed for their module. > > > > } > > > > On Jul 28, 4:18 pm, Naftoli Gugenheim <[email protected]> wrote: > >> The first suggestion was reflection... > >> I'm not pushing the idea, just throwing in an alternative. > >> But the xml route doesn't have to be xml--it could be a plain text file > like > >> /META-INF/.liftboot etc. > >> Or you could search all jars for net.liftweb.BootXX or net.liftweb.XX > that > >> implements a trait OnBoot... > >> The point is, there's no shortage of ways (if there's a will :) ) but > they > >> all have a certain cost of course. Dynamic loading _means_ searching for > >> Something. That takes time, and it puts some requirement on the library > >> author--but it takes the requirement off the user. > >> > >> ------------------------------------- > >> > >> Timothy Perrett<[email protected]> wrote: > >> > >> Hey Naftoli, > >> > >> Lift has a general aversion to xml configs... Is there another route? > >> > >> Cheers, Tim > >> > >> On 28/07/2009 20:47, "Naftoli Gugenheim" <[email protected]> wrote: > >> > >> > >> > >>> What I was suggesting is that instead of having to write Lib.init in > Boot, > >>> Lift should look in Lib.jar for say /boot.xml which would tell Lift to > >>> execute > >>> Lib.init for you on startup. I think that would accomplish what you > want, at > >>> the cost of lift searching through the jars. > > > > > > > > > > > > > -- My blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: www.scalamodules.org Lift, the simply functional web framework: liftweb.net --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
