I've been having a think about this, and are we overlooking something stupid here?.... Perhaps OSGi could yield a good solution?
Thoughts? Cheers, Tim On 28/07/2009 20:04, "glenn" <gl...@exmbly.com> 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 <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 -~----------~----~----~----~------~----~------~--~---
