Tim, My last post may be dismissed as adding more complication than simply editing Boot.scala. But keep in mind that a consistent, uniform and robust procedure for modularization across the Lift universe is to be favored over the ad-hoc approach, as exists now. In my view, opening a project and editing source files should always be a last-resort option.
Glenn... On Jul 28, 9:36 am, Timothy Perrett <timo...@getintheloop.eu> 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 -~----------~----~----~----~------~----~------~--~---
