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