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