If the xml is in the jar file then it would only require the user of the library to drop thr jar in. It would only be an extra step for the library author. The question is whether the extra line saved in Boot is worth the time it takes for Lift to search the jars whenever you deploy.
------------------------------------- glenn<[email protected]> wrote: 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
