cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Modeler extensions point
Date Fri, 29 Sep 2006 21:55:12 GMT
I am all for Platonos, just don't have any spare bandwidth now ...  
sigh :-/

Andrus

On Sep 29, 2006, at 5:49 PM, Evert Tigchelaar jr wrote:

> One of the plugin engine that where discussed was the Platonos  
> Plugin Engine, I am one of the two developers thats working on it.
> We currently have a stable version 1.5 and on 2.0 I am working on  
> but this one should be allready quit stable, its not a drop in  
> replacements for the 1.5 but it shouldn't be to hard to move, after  
> you fix the imports for the plugin engine it should work the same  
> as with 1.5 of the plugin engine.
>
> I didn't seen the code of the moduler tool but it should be to hard  
> to turn it into a plugin, create a lifecycle class and a  
> configuration file and off you go. Then its one big plugin and from  
> there you could the moduler tool and divide it into multipul plugins.
>
> But like you write the developers of the cayenne project are quit  
> busy with lots of things so it may be better to focus on those  
> things and move the addition of a plugin engine up to a later time.
> And as far as I know there wasn't made a decision about which  
> plugin engine to choice so that must be finished off before you can  
> add a plugin engine.
>
> Evert
>
> Mike Kienenberger wrote:
>> 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 <andrus@objectstyle.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;
>>> >    }
>>> >
>>>
>>>
>
>


Mime
View raw message