Thanks for the comments Philipp. I think that in my over-complex system I will go with A.2 as it looks the most natural approach. Thanks for the idea.
./alex -- .w( the_mindstorm )p. On 4/3/06, Philipp Bracher <[email protected]> wrote: > Alexandru Popescu wrote: > > Hi! > > > > I've been thinking a lot after our last discussions about how would it > > be possible to customize the modules, without needing to change the > > modules or going manually over them. > > > > Currently, the first conf files are imported from WEB-INF/bootstrap > > dir. Later on the process, the module is overridding these (if it is > > the case): > > > > [code: ModuleUtil lines: 145-148] > > if (hm.isExist(fullPath)) { > > hm.delete(fullPath); > > log.warn("already existing node [{}] deleted", > > fullPath); > > } > > [/code] > > > > I guess a better approach would be to have the mechanism work in the other > > way: > > > > if the conf is already defined, it means that the admin customized the > > system when the system first bootstrap, and so the module conf should > > not override it. > > > > The change to support this behavior is quite trivial and IMO the > > system would be easier to be configured from the pov of sys admins. > > > > What do you think about this idea? > > The thing is that you can't restrict the module to much. If a module > defines the file config.modules.mymodule.config.xml this will replace > all the already existing subcontent (else we will have an indexed node: > config[1] config[2]). This brought me to the definition that a module > deletes always in advanced the imported nodes since this is what will > happen anyway. > > It makes sense to define the following procedure: install and then > configure. For example you are not able to configure a eclipse plugin > before you install it without doing tricks. > > A solution A: if you don't like the manual part of the proposed solution > A) you could do the following: > > A.1) custom post bootstrap > - register a listener > - wait for ConfigLoader.configured > - check ModuleRegistration.restartNeeded > - if everything is ok, execute your custom bootstrap. > > A.2) deliver a already bootstrapped system > > A.3) make your application a module itself. Define the dependencies so > that it is initialized after the modules you like to customize. > > D) New Idea: We could define that all the bootstrap files with prefix > config.modules.* are loaded after the installation of the modules and > not in advanced. > > What do you think about this? > > ---------------------------------------------------------------- > for list details see > http://www.magnolia.info/en/magnolia/developer.html > ---------------------------------------------------------------- > ---------------------------------------------------------------- for list details see http://www.magnolia.info/en/magnolia/developer.html ----------------------------------------------------------------
