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