I remember those discussions, but I don't see real plugin engine
availability as something that's going to happen in the near term.
There's far too many other "important" things going on like JPA, outer
joins, audit logging, and other fun things.
So I'm looking for a short-term maintainable solution. If we're
going to have real plugin support down the road, I think what I've
proposed is probably good enough for the time being, and has minimal
impact.
On 9/29/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> Mike,
>
> we have this entire big thing in the queue for 3.0 - switching
> CayenneModeler to a plugin engine. If you search the mailing list,
> you'll find long heated discussions about it throughout the summer.
>
> So I suggest to avoid checking in any ad hoc plugin functionality
> until the engine is in place. Or even better - let's get the plugin
> engine going for real.
>
> Andrus
>
>
> On Sep 29, 2006, at 3:34 PM, Mike Kienenberger wrote:
>
> > I needed to add a new feature to Cayenne Modeler yesterday. The
> > primary impact was the addition of a new menu item which called my own
> > code.
> >
> > Today, I went through and tried to figure out a reasonable way of
> > making such an extension built-in to Cayenne, so I don't have to
> > maintain it with patches.
> >
> > I'm not completely happy with what I have come up with, primarily
> > because it only supports one extension set, but this is what I've done
> > so far. I read a cayenneActionPluginFactory class from a system
> > property (yes, the property needs to be fully-qualified) as a method
> > on Application. Application seemed easily accessible and no worse
> > than anything else, but maybe a separate
> > CayenneActionPluginFactoryManager would make more sense.
> >
> > If a plugin is found, I create a new Extensions top-level menu and
> > stick the actions into it in CayenneModelerFrame. In ActionManager's
> > constructor, I register the actions, and add any to the DOMAIN_ACTIONS
> > list that are domain actions (also should provide ways to do the same
> > for project, datamap, objEntity, dbEntity, Special, etc.)
> >
> > That's the majority of the changes to support this. What I'd ideally
> > like to have happen is to figure out a way to support any number of
> > CayenneActionPluginFactory objects, and have the registration
> > automatic (maybe check each jar for a CayenneActionPluginFactory
> > config file?), but I don't know if the second option is realistic. I
> > suppose the first option could be handled by making the system
> > property a list of comma-separated classes rather than a single class.
> >
> >
> >
> > public interface CayenneActionPlugin {
> > public String getActionName();
> > public CayenneAction createCayenneAction(Application application);
> > public boolean isDomainAction();
> > }
> >
> > public interface CayenneActionPluginFactory {
> > public List getCayenneActionPluginList();
> > }
> >
> > static CayenneActionPluginFactory cayenneActionPluginFactory =
> > null;
> > public CayenneActionPluginFactory getCayenneActionPluginFactory()
> > {
> > // TODO: retrieve somehow and allow multiple factories.
> > if (null == cayenneActionPluginFactory)
> > {
> > String pluginName =
> > System.getProperty("cayenneActionPluginFactory");
> > if (null != pluginName)
> > {
> > try {
> > cayenneActionPluginFactory =
> > (CayenneActionPluginFactory)Class.forName(pluginName).newInstance();
> > }
> > catch (InstantiationException e) {
> > logObj.error("InstantiationException error
> > instantiating cayenneActionPluginFactory", e);
> > }
> > catch (IllegalAccessException e) {
> > logObj.error("IllegalAccessException error
> > instantiating cayenneActionPluginFactory", e);
> > }
> > catch (ClassNotFoundException e) {
> > logObj.error("ClassNotFoundException error
> > instantiating cayenneActionPluginFactory", e);
> > }
> > }
> > }
> > return cayenneActionPluginFactory;
> > }
> >
>
>
This archive was generated by hypermail 2.0.0 : Fri Sep 29 2006 - 15:57:17 EDT