Dave wrote:
I think that's a good idea. And folks have to update their config
files anyway due to the package renaming.
A somewhat related issue: should the MailUtil class become the
MailManager and live in the backend? Why does the mail API live in the
front end?
I still consider it more of a utility than a manager, but maybe that's
just me. and it does live in the backend, it's in the weblogger.util
package which is part of the business layer.
If you look in your build directory you will also see it under the
compile/business directory.
-- Allen
- Dave
On 6/7/07, Allen Gilliland <[EMAIL PROTECTED]> wrote:
I hate to do this because it's annoying forcing people to update their
config files, but I think that the entry plugins should not be in the ui
code layer.
While there isn't a compile time dependency problem here there *is* a
runtime dependency problem because some of the functionality of the
PluginManager (in the business layer) requires being able to instantiate
the configured plugin classes which are bundled in the ui code layer.
So that means that technically to run the roller business layer you need
to have the ui layer as well, and that's not the intended design.
What I'd like to suggest is that we organize the plugins code in the
business layer a little bit, like this ...
business.plugins
- PluginManager
- PluginManagerImpl
business.plugins.entry
- WeblogEntryPlugin
* all the plugins currently in ui.rendering.plugins
This will properly group the plugin code together and since none of the
plugins currently rely on any code in the ui layer it's an easy switch
to make.
thoughts? comments?
-- Allen
