Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Do not change way Roller is configured
    • Do not introduce any additional configuration files for those installing Roller, i.e. don't change the fact that the only customization file users should ever have to touch is roller-custom.properties.
    • Do not introduce any additional configuration files for developers, i.e. developers should not have to deal with any new XML or property files.
    • Maintain the same level of back-end pluggability, i.e. it should still be possible to switch back-end implemenations by setting a single property in the Roller configuration file.

Issues

These issues were raised and responded to during mailing list discussions of this proposal:

  • "I think it is most appropriate that any instance of the Roller interface should be treated
    as immutable. "
    • We use constructor injection so that Roller implementations do not have to expose setters and can remain immutable.
  • "To truly enforce the singleton pattern we should only provide private constructors and the single instance of the class should be created statically and returned via a public static method."
    • Guice can call private constructors, so we full enforce the singleton model.
  • "From my perspective Spring is more mature, well-documented and tested, has a more open contribution model, and is in wider use amongst a broader community. Plus we have at least two committers that are using it in other settings."
  • Responses
    • Guice documentation is excellent and Guice is "simple and easy. It took me no time at all to figure out – no books or extra docs necessary."
    • "Guice now powers Google Adwords. You'd be hard pressed to find a more massively distributed, scalable, etc. Java app out there. So, I'm not particularly worried about Guice maturity and testing."
    • Spring does not accept external committers and has no plans to do so, that's hardly an open contribution model.
  • "I hope we won't be asking users to modify distributed code in order, for example, to add plugins or to swap a rendering model implementation."
    • We won't require that. If you want to extend Roller's back-end you simply provide your own module class that injects the classes you want.
    How far should we go with DI in the 4.0 release?

Design

List and describe new manager methods, Struts actions, JSP pages, macros, etc.

...