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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
