This discussion has gotten beyond a simple solution for Lift plugins.
Most Lift apps now don't use OSGi, and
modularization means something different in a non-OSGi environment.
For one thing, it's not dynamic. You still
have to code to use the new module. A well-mannered Lift/OSGi marriage
is a good thing, where modularization
is the rule, not the exception, but that doesn't take the place of
statically dropping in code/jars during development.
That is what needs to be addressed foremost, I think.
Glenn...
On Jul 29, 4: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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
