Hi, Ross,

So, with the changes, where would templates need to be placed in jar
files in
order to be found - or can they be put in any directory as long as the
resource
is noted in ResourceServer?

Glenn...

On Jul 28, 9:39 am, Ross Mellgren <dri...@gmail.com> wrote:
> http://github.com/dpp/liftweb/commit/0f60807dd64b7fe1430919738b46f2eb...
>   ...
>
> From:   feeder.of.the.be...@gmail.com
> Subject:        [Lift] Re: ResourceServer problem
> Date:   July 22, 2009 12:07:14 PM EDT
> To:     liftweb@googlegroups.com
> Reply-To:       liftweb@googlegroups.com
>
> On Tue, Jul 21, 2009 at 9:55 PM, Naftoli Gugenheim  <naftoli...@gmail.com> 
> wrote:
>
>  > Now a direct call to ResourceServer does work, but the template is  
> still not being found. Any ideas?
>
> Templates are looked up simply by using the ServletContainer Context's  
> resource locator.  I've expanded the lookup process so that stuff in  
> JAR files will be found.  I'll commit the changes up in 10 minutes or  
> so.
>
> -Ross
>
> On Jul 28, 2009, at 12:36 PM, Timothy Perrett wrote:
>
>
>
> > Glenn,
>
> > You have my full attention - this is something I've been sitting on  
> > for
> > quite some time but just not quite sure what the best route forward  
> > is.
>
> > When im creating these modules, I essentially just build a normal jar
> > project with maven, and as you say, if I have JS or whatever that I  
> > need to
> > use I just specify that with ResourceServer (in the module JAR init).
>
> > To date I've not actually needed to pull a template from another  
> > JAR, but
> > looking at ResourceServer.findResourceInClasspath I think it could  
> > do it...
> > If memory serves DPP checked in a change to make this work about 2  
> > weeks
> > ago...
>
> > In terms of having a defined loading pattern, its possible, but  
> > would need
> > outlining with some very specific details... IMO, adding one line of  
> > code to
> > Boot.scala is not a big deal so we would really need a good reason  
> > to add a
> > bunch of reflection which can sometime feel like voodoo because its  
> > not
> > clear what its loading and why (one of the reasons I went off ruby).
>
> > Cheers, tim
>
> > On 28/07/2009 17:00, "glenn" <gl...@exmbly.com> wrote:
>
> >> Hi, Tim,
>
> >> So, what you do is put all new LiftRules, Schemifier and
> >> ResourceServer stuff
> >> in an init function and run it after the Boot.scala defaults. Sounds
> >> simple enough.
>
> >> When creating your modules, do you just strip out all the stock  
> >> webapp
> >> files (those
> >> that come with the maven lift archetypes), and put all your new
> >> resources in a
> >> "toserve" directory, then just jar it up?
>
> >> And what about any new template files? Where do those go in you  
> >> module
> >> jars?
> >> You can't put them in the "toserver" directory. My understanding is
> >> that that would
> >> install them in the WEB-INF/classes directory of your final war file,
> >> when they
> >> need to go into the root webapp.
>
> >> I still see loose ends here.
>
> >> Also, what if you didn't have to modify Bool.scala for every
> >> module you add. Some hook function in an object that Boot.scala runs
> >> each time that
> >> would iterate through all your init functions that followed a pre-
> >> defined
> >> signature, would be a nice feature to add to Lift.
>
> >> Glenn...
>
> >> On Jul 27, 4:01 pm, Timothy Perrett <timo...@getintheloop.eu> wrote:
> >>> Hi Glen...
>
> >>> I actually do a lot of this - we have a product at work and i've  
> >>> just
> >>> written a bunch of abstractions for work which just require me to  
> >>> do:
>
> >>> MyLib.init
>
> >>> In the boot file of a new application and then everything wires up  
> >>> - I
> >>> couldn't think of anything more straightforward?
>
> >>> The vast majority of stuff in lift is done with PF's, so you can
> >>> pretty much just write them in external jars, and import them - my  
> >>> 3rd
> >>> part stuff usually has a lift-webkit dependency so that I can just  
> >>> do
> >>> the LiftRules.disptach.append stuff directly in the init method, but
> >>> its really no biggy and saves boilerplate.
>
> >>> So given your example, this scheme should work right?
>
> >>> Cheers, Tim
>
> >>> On Jul 27, 11:52 pm, glenn <gl...@exmbly.com> wrote:
>
> >>>> I'm interested in abstracting out useful features from my Lift
> >>>> applications for ease of reuse, but I haven't found an easy way  
> >>>> to do
> >>>> it. I find myself creating a new Lift aplication for each feature,
> >>>> with all the baggage (bootstrapping, etc.), and I then have to do a
> >>>> lot of code modification to the application I'm adding the  
> >>>> feature to
> >>>> in order to get it to work.
>
> >>>> For example, suppose I want to add role-based user login to an
> >>>> application that already has a User model just by dropping in a jar
> >>>> file with the new feature. I don't see how to do it without some
> >>>> boostrapping modifications.
>
> >>>> Has anyone really tried to modularize their Lift development. I'd  
> >>>> be
> >>>> very interested in some suggestions.
--~--~---------~--~----~------------~-------~--~----~
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