Sounds good! Any ideas how class lookups (snippets at least) could be delegated to various modules. Currently Lift is using the *global* classpath in a fashion that makes it really hard / impossible for OSGi.
Heiko 2009/7/29 Ryan Donahue <donahu...@gmail.com> > > More spitballing... > > Tim, > I really don't know which LiftRules stuff would need to be included. > For other types of environment changes, the trait could have onLoad > and onUnload methods. > > Heiko, > Maybe it is possible to make such a change without breaking API, > though I am still fairly new to Lift and not at all familiar enough > with LiftRules yet. All the LiftRules public methods could simply > manipulate a default internal LiftModule that is always in > LiftRules.modules. > > These are probably big changes, but I see great benefit to well- > defined modules. It would facilitate sharing functionality with each > other. Could even set up a LiftModule site where you can share and > find modules. > > -Ryan > > On Jul 29, 7:55 am, Heiko Seeberger <heiko.seeber...@googlemail.com> > wrote: > > 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 <timo...@getintheloop.eu> > > > > > > > > > > > > > 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" <donahu...@gmail.com> 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 <naftoli...@gmail.com> 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<timo...@getintheloop.eu> 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" <naftoli...@gmail.com> > 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 > > > > -- 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 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 -~----------~----~----~----~------~----~------~--~---