[Lift] Re: Modularization of Lift code

[Andrew Scherpbier]

-1 from me on this. To me that smells too much of J(2)EE and happens to be one of my personal reasons to stay away from anything that requires (custom) deployment descriptors.  I'd rather stick with configuration by convention or explicit init calls in Boot.scala. The cost of lift searching through jars is exactly 0 unless you can demonstrate it isn't...  :-)  (Premature optimization, anyone?) --Andrew Naftoli Gugenheim wrote: 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 -~----------~----~----~----~------~----~------~--~---