Sounds good!

Any ideas how class lookups (snippets at least) could be delegated to
various modules. Currently Lift is using the *global* classpath in a fashion
that makes it really hard / impossible for OSGi.

Heiko

2009/7/29 Ryan Donahue <donahu...@gmail.com>

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


-- 

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

Reply via email to