On Wed, Jul 29, 2009 at 4:31 AM, Ryan Donahue <donahu...@gmail.com> wrote:

>
> -1 for adding modules by "dropping in" a jar


Dropping in JAR files that automatically become part of your app is not
going to happen.  I've seen too many horror show situations where people
have stuff on their classpath that magically becomes part of the app.  A
single line init in Boot is simple enough.


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


It does because the module can specify its own templates as part of the Loc


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


-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

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

Reply via email to