talmdal and jmullan chatting (paraphrased):
Talmdal: I would like to break the core module into two components: one component is the basic management and a set of defined interfaces. The Gallery core would have no gui functionality at all. It should have a set of standard interface definitions and the code to manage and interact with these interfaces.
The rest of the "core module" (as it is defined today) would be broken into a separate plugin to provide the gui application. The core module as it stands today is trying to be both. The benefit is that the framework would change very little once set up and that the application core functionality could be treated as any other plugin and be upgraded by DP.
All the admin controllers and views could be pulled out. GalleryDataCache could be a separate plugin that could be replaced... if the core suppled a caching interface. i.e. spring/struts is a framework and they make no assumptions about what model, view, or controllers are available
With php5 we can really start to use and enforce interfaces, which really lets us get into this approach.
My other thought is changing GalleryStatus to be more 'java like' exceptions (another change for R2.4) that's the $ret in ($ret, $value) ? I know that bharat is chomping at the bit to replace that with straight up exceptions
jmullan said: What if we replaced the smarty object with our own template wrapper? We would still set variables in the wrapper, but then it would just include php template files. Debugging templates would become about a million times more straightforward -- being able to dump variables and do other hacky things (while still having controls set by php through scoping and member protection) would be quite useful.
private, protected, final abstract, interface
We will need to rewrite these codex pages to reflect PHP5.
