I see, could you post an example of your "ExampleConfig" so I can grab an idea?
The actionpack I'm needing to write is going to only change in two ways, so that what I was thinking of doing... Writing a config that tells the app which option to use... any thoughts? On Sep 5, 6:59 pm, denstar <[EMAIL PROTECTED]> wrote: > On Fri, Sep 5, 2008 at 1:39 PM, salomoko wrote: > > > All, > > > I'm needing to create a modular actionpack to integrate with a current > > MG:U app, as well as future apps... So one quick question I have is, > > do I just create a regular MG app, then when I need to integrate it, > > just point to the xml file from the existing app via <include>? > > > Is that all there is to it? > > > any thoughts? > > I wanted to say some stuff about the usermanagement actionpack in MG3, > I can roll it into this response. > > First off, it's good to separate what mostly stays the same from what > will change. > > Like, in the current MG3 userman actionpack, the per-application > UserManagementConfiguration bean (which is different for each > application) is included with the other, "probably not changing per > application" beans. > > What I do, is a simple include for the "probably not changing" > actionpack beans, and then use a separate file/bean for the > configuration, which I store with each application. I keep an > "exampleConfiguration" with the actionpack, that I can copy into my > application and then modify. > > So I've got one general include to most the actionpack stuff that > stays the same, and then another for the configuration options of the > actionpack, that is pointing at a per-application config file. > > Yup, that's mostly it, I guess. Split out the stuff that changes > per-app into it's own file. > > Heh. Coulda sworn I had some other ideas too, but can't remember right now. > > Oh, abstraction-- for my personal user actionpack, I did some stuff > like having the DAO table/column names be configurable. Made it easy > to plug into the various existing apps I had, which all had basically > the same data, but called different things. Again, what [mostly] > stays the same, vs. what changes often. > > Guess they're both sorta about abstraction or encapsulation. Eh. > > -- > Love consists in giving without getting in return; in giving what is > not owed, what is not due the other. That's why true love is never > based, as associations for utility or pleasure are, on a fair > exchange. > Mortimer Adler --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "model-glue" 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/model-glue?hl=en For more about Model-Glue, check http://www.model-glue.com . -~----------~----~----~----~------~----~------~--~---
