What I was suggesting is that instead of having to write Lib.init in Boot, Lift should look in Lib.jar for say /boot.xml which would tell Lift to execute Lib.init for you on startup. I think that would accomplish what you want, at the cost of lift searching through the jars.
------------------------------------- Glenn Silverman<gl...@exmbly.com> wrote: Hi, Naftoli, I assume what you are asking is whether your module should include it's own xml configuration file. I know GWT uses a main configuration file where module entry-points are defined. And modules, themselves can depend on other modules with their own configuration files. You could enforce a rule that all Lift modules contain their own configuration files, along with the main webapp, just for this purpose. I guesss what I am suggesting is some way for modules (jar files) to be distinguished from normal jar files or a complete Lift webapp, in order to standardize and simplify their design and creation. After all, modules that contain reuseable Lift features are different in kind from a Lift application. Glenn... Naftoli Gugenheim wrote: > In xml in the library jar? > > ------------------------------------- > glenn<gl...@exmbly.com> wrote: > > > Tim, > > Here's a thought. GWT uses <entry-point class="some fully qualified > class name" /> to > identify and initialize modules. Perhaps something similar could be > hooked into LiftFilter and an entry point > class identified in web.xml. There should be little objection to xml > configuration, as opposed to using Java reflection. > > 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 -~----------~----~----~----~------~----~------~--~---
