move entry plugins to business package?

[Allen Gilliland <al...@sun.com>]

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

Re: move entry plugins to business package?

[Dave <sn...@gmail.com>]

On 6/8/07, Allen Gilliland <al...@sun.com> wrote:
> 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.

With methods like sendPendingEntryNotice() and sendWeblogInvitation()
it's starting to look more like a MailManager rather than a MailUtil.

weblogger.util is technically part of the business layer, since it
goes into the business jar but when I think "business layer" I think
of Roller and the managers. That's just me.

I guess I don't have a strong enough urge to move it around right now
so I'll drop the topic.

- Dave

Re: move entry plugins to business package?

[Allen Gilliland <al...@sun.com>]

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 <al...@sun.com> 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
>>

Re: move entry plugins to business package?

[Dave <sn...@gmail.com>]

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?

- Dave


On 6/7/07, Allen Gilliland <al...@sun.com> 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
>