You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Eshan Sudharaka <es...@gmail.com> on 2011/06/26 08:05:07 UTC

Gsoc Project Update

Hi Ksenia ,
       As you mentioned I went through the code where i deletes cyenne.xml
in UpgradeHandler_V6 class. And then in a case of we are having
xyzDomainMap.xml  (with out cayenne.xml) we can not open i with my external
editor (cayenne modeler) by default. Because we can filter files according
to extension or from a specific name. (can not go for pattern matching and
filer  xyzDomainMap.xml using the keyword  DomainMap). So we have to open
the DomainMap xml file by  Open With > Cayenne Modeler Plugin (when we
double click on DomainMap file is opens with default xml editor ) . I am
still figuring out  a way of solving this.

         I have attached a patch  by adding java class generation support
for my plugin in jira issue page.
https://issues.apache.org/jira/browse/CAY-1554

-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Ksenia Khailenko <xe...@tut.by>.
Hi

The current plugin could be committed after some cleanup and making
PluginActionManager to extend from DefaultActionManager(instead of
implementing ActionManager). the last require some changes in
DefaultActionManager(got rid of static final variables).

Eshan, as for the cleanup - remove all the meaningless comments, useless
imports, etc. Add the javadocs for the important methods(Ideally, we need
javadocs for all our code).

2011/7/17 Andrus Adamchik <an...@objectstyle.org>

> Hi Eshan,
>
> Thanks for your work on the plugin. Ksenia showed me the latest version of
> the plugin on her machine (we happen to work for the same company with her).
> Very nice progress.
>
> A question to both Ksenia and Eshan - is there anything committable at this
> point? I haven't seen any of that going to SVN yet. Would be nice if we
> start committing this code.
>
> Cheers,
> Andrus
>
>
> On Jul 15, 2011, at 10:54 PM, Eshan Sudharaka wrote:
> > Thanks for thevaluable ideas which leads me to do my job properly and I
> got
> > a e-mail from Google Open Source Programs Team and according to it I have
> > passed from the midterm evaluation. And Special thank should goes to
> Ksenia.
> > Looking forward to work with the team for next updates.
> >
> > On Mon, Jul 11, 2011 at 11:54 AM, Andrus Adamchik <
> andrus@objectstyle.org>wrote:
> >
> >> I have no problem if we change DefaultActionManager etc. on the Cayenne
> end
> >> to be easily extendable class. CayenneModeler configuration of internal
> >> classes has lots of shortcuts, as it never assumed other apps using or
> >> extending this code. Now it is time to evolve it.
> >>
> >> Andrus
> >>
> >> On Jul 10, 2011, at 1:12 PM, Ksenia Khailenko wrote:
> >>
> >>> Andrus, look at this one, please. We have the DefaultActionManager with
> >>> final property which we want to override. It is possible to create an
> >>> another implementation of ActionManager, but in fact in this case, we
> >>> duplicate a lot of code...
> >>>
> >>> 2011/7/2 Eshan Sudharaka <es...@gmail.com>
> >>>
> >>>> Yes. It is possible. I have attached patch files with this. For this
> >> patch
> >>>> I had to add default constructors to following  classes.
> >>>>
> >>>> CayenneController.java
> >>>> CayenneModelerController.java
> >>>>
> >>>> trunk.patch includes this modification (Actualy no need to apply
> >>>> trunk.patch just add default constructors to those clases)
> >>>>
> >>>> Second patch includes the modifications included in this thread.
> >>>>
> >>>>
> >>>> On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <
> >> xenia_khailenka@tut.by>wrote:
> >>>>
> >>>>> May be it would be better not to extend from DefaultActionManager,
> but
> >>>>> implement it's interface? Is it possible?
> >>>>>
> >>>>> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
> >>>>>
> >>>>>> Thanks. I got it. I have another problem in implementing plugin
> >> actions
> >>>>>> classes. We can register external Actions to actionMap in
> >>>>>> DefaultActionManager class. So I registered PlugingProject class and
> >> add
> >>>>>> that class in to file menu of CayenneModelerFrame and run my plugin.
> >>>>> Then
> >>>>>> it
> >>>>>> seems project close action is menu item is disabled .I think I need
> >> add
> >>>>>> PluginProjectAction class   following in DefaultActionManager class.
> >>>>>>
> >>>>>> static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
> >>>>>>         RevertAction.class.getName(),
> >>>>>>         ProjectAction.class.getName(),
> >>>>>>         ValidateAction.class.getName(),
> >>>>>>         SaveAsAction.class.getName(),
> >>>>>>         FindAction.class.getName());
> >>>>>>
> >>>>>> Here I should add my PluginProjectAction class. I have extended
> >>>>>> PluginActionManager from DefaultActionManager class. Since this is a
> >>>>> static
> >>>>>> this list is not inherited to child class and also we can not add
> any
> >>>>> thing
> >>>>>> since it is final. How to overcome this issue ? We can do this by
> >>>>> modifying
> >>>>>> parent class ( DefaultActionManager class ) and I am not sure
> whether
> >> it
> >>>>> is
> >>>>>> a good approach or not. Now I am working on this.
> >>>>>>
> >>>>>> Thanks.
> >>>>>>
> >>>>>> On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
> >>>>> xenia_khailenka@tut.by
> >>>>>>> wrote:
> >>>>>>
> >>>>>>>>>>>>
> >>>>>>> 1:07
> >>>>>>> Eshan Sudharaka
> >>>>>>> Hi , what is the reason to do setEnable(false )  for some items in
> >>>>> file
> >>>>>>> menu
> >>>>>>> in cayenne modeler in your plugin ?
> >>>>>>> I dint get the point
> >>>>>>>>>>>>>>
> >>>>>>> Eshan means this one:
> >>>>>>>
> >>>>>>> if (NewProjectAction.getActionName().equals(name)
> >>>>>>> +                        ||
> >>>>>> OpenProjectAction.getActionName().equals(name)
> >>>>>>> +                        ||
> >> ProjectAction.getActionName().equals(name)
> >>>>>>> +                        || "Recent Projects".equals(name)) {
> >>>>>>> +                    item.setEnabled(false);
> >>>>>>> +                }
> >>>>>>> All these actions perform manipulations with some another projects,
> >>>>> but
> >>>>>> we
> >>>>>>> are dealing with the selected project from Eclipse, so, it was
> >>>>> considered
> >>>>>>> then that the switching between projects is undesirable when
> working
> >>>>> with
> >>>>>>> plugin - it may happen that we don't have the correspondent project
> >> in
> >>>>>>> Eclipse, and on change will try to update it...
> >>>>>>>
> >>>>>>> But I think we can enable the "NewProjectAction" for example, to
> >>>>> create
> >>>>>> the
> >>>>>>> cayenne project by the plugin....or we can just leave these buttons
> >>>>> for
> >>>>>> now
> >>>>>>>
> >>>>>>> 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
> >>>>>>>
> >>>>>>>> Sounds good.
> >>>>>>>>
> >>>>>>>> We might still want to change the naming convention for
> consistency
> >>>>>> down
> >>>>>>>> the road, but good to hear there's no urgency.
> >>>>>>>>
> >>>>>>>> Andrus
> >>>>>>>>
> >>>>>>>> On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
> >>>>>>>>
> >>>>>>>>> Hi ,
> >>>>>>>>> I am sorry. I found a way to check the content of the XML files
> >>>>>>>> (currently
> >>>>>>>>> root element) and if it is cayenne project file then load cayenne
> >>>>>> icon
> >>>>>>> in
> >>>>>>>>> eclipse. So no need of changing file naming conventions.
> >>>>>>>>>
> >>>>>>>>> On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
> >>>>>>> andrus@objectstyle.org
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> >>>>>>>>>>
> >>>>>>>>>>> However... nothing prevents us from changing the naming
> >>>>> convention
> >>>>>>>> again.
> >>>>>>>>>> After all 3.1 is not final yet (not even Beta). We might as well
> >>>>>> adopt
> >>>>>>>>>> another "double extension":
> >>>>>>>>>>>
> >>>>>>>>>>> Main project file: xyz.cayenne.xml
> >>>>>>>>>>> DataMap file: xyz.map.xml
> >>>>>>>>>>>
> >>>>>>>>>>> This will ensure both types of files follow a similar
> >>>>> convention,
> >>>>>> and
> >>>>>>>>>> make them Eclipse-friendly.
> >>>>>>>>>>
> >>>>>>>>>> Also the beauty of Cayenne 3.1 is that the name of the project
> >>>>> file
> >>>>>> is
> >>>>>>>>>> specified explicitly when the runtime is started, so the file
> can
> >>>>>>> really
> >>>>>>>> be
> >>>>>>>>>> called anything (doesn't even have to have .xml extension). So
> >>>>> the
> >>>>>>> focus
> >>>>>>>> of
> >>>>>>>>>> this discussion is the tools (CayenneModeler, Eclipse, etc..),
> >>>>> not
> >>>>>> the
> >>>>>>>>>> runtime.
> >>>>>>>>>>
> >>>>>>>>>> Andrus
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> *~Thanks & Regards~*
> >>>>>>>>> ***
> >>>>>>>>> *
> >>>>>>>>> P.A.Eshan Sudharaka
> >>>>>>>>> Dept of Computer Science and Engineering
> >>>>>>>>> University of Moratuwa
> >>>>>>>>> Sri Lanka
> >>>>>>>>> http://esudharaka.blogspot.com/
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Regards, Ksenia Khailenko
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> *~Thanks & Regards~*
> >>>>>> ***
> >>>>>> *
> >>>>>> P.A.Eshan Sudharaka
> >>>>>> Dept of Computer Science and Engineering
> >>>>>> University of Moratuwa
> >>>>>> Sri Lanka
> >>>>>> http://esudharaka.blogspot.com/
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Regards, Ksenia Khailenko
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> *~Thanks & Regards~*
> >>>> ***
> >>>> *
> >>>> P.A.Eshan Sudharaka
> >>>> Dept of Computer Science and Engineering
> >>>> University of Moratuwa
> >>>> Sri Lanka
> >>>> http://esudharaka.blogspot.com/
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Regards, Ksenia Khailenko
> >>
> >>
> >
> >
> > --
> > *~Thanks & Regards~*
> > ***
> > *
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
> > http://esudharaka.blogspot.com/
>
>


-- 
Regards, Ksenia Khailenko

Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Eshan,

Thanks for your work on the plugin. Ksenia showed me the latest version of the plugin on her machine (we happen to work for the same company with her). Very nice progress.

A question to both Ksenia and Eshan - is there anything committable at this point? I haven't seen any of that going to SVN yet. Would be nice if we start committing this code.

Cheers,
Andrus


On Jul 15, 2011, at 10:54 PM, Eshan Sudharaka wrote:
> Thanks for thevaluable ideas which leads me to do my job properly and I got
> a e-mail from Google Open Source Programs Team and according to it I have
> passed from the midterm evaluation. And Special thank should goes to Ksenia.
> Looking forward to work with the team for next updates.
> 
> On Mon, Jul 11, 2011 at 11:54 AM, Andrus Adamchik <an...@objectstyle.org>wrote:
> 
>> I have no problem if we change DefaultActionManager etc. on the Cayenne end
>> to be easily extendable class. CayenneModeler configuration of internal
>> classes has lots of shortcuts, as it never assumed other apps using or
>> extending this code. Now it is time to evolve it.
>> 
>> Andrus
>> 
>> On Jul 10, 2011, at 1:12 PM, Ksenia Khailenko wrote:
>> 
>>> Andrus, look at this one, please. We have the DefaultActionManager with
>>> final property which we want to override. It is possible to create an
>>> another implementation of ActionManager, but in fact in this case, we
>>> duplicate a lot of code...
>>> 
>>> 2011/7/2 Eshan Sudharaka <es...@gmail.com>
>>> 
>>>> Yes. It is possible. I have attached patch files with this. For this
>> patch
>>>> I had to add default constructors to following  classes.
>>>> 
>>>> CayenneController.java
>>>> CayenneModelerController.java
>>>> 
>>>> trunk.patch includes this modification (Actualy no need to apply
>>>> trunk.patch just add default constructors to those clases)
>>>> 
>>>> Second patch includes the modifications included in this thread.
>>>> 
>>>> 
>>>> On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <
>> xenia_khailenka@tut.by>wrote:
>>>> 
>>>>> May be it would be better not to extend from DefaultActionManager, but
>>>>> implement it's interface? Is it possible?
>>>>> 
>>>>> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
>>>>> 
>>>>>> Thanks. I got it. I have another problem in implementing plugin
>> actions
>>>>>> classes. We can register external Actions to actionMap in
>>>>>> DefaultActionManager class. So I registered PlugingProject class and
>> add
>>>>>> that class in to file menu of CayenneModelerFrame and run my plugin.
>>>>> Then
>>>>>> it
>>>>>> seems project close action is menu item is disabled .I think I need
>> add
>>>>>> PluginProjectAction class   following in DefaultActionManager class.
>>>>>> 
>>>>>> static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
>>>>>>         RevertAction.class.getName(),
>>>>>>         ProjectAction.class.getName(),
>>>>>>         ValidateAction.class.getName(),
>>>>>>         SaveAsAction.class.getName(),
>>>>>>         FindAction.class.getName());
>>>>>> 
>>>>>> Here I should add my PluginProjectAction class. I have extended
>>>>>> PluginActionManager from DefaultActionManager class. Since this is a
>>>>> static
>>>>>> this list is not inherited to child class and also we can not add any
>>>>> thing
>>>>>> since it is final. How to overcome this issue ? We can do this by
>>>>> modifying
>>>>>> parent class ( DefaultActionManager class ) and I am not sure whether
>> it
>>>>> is
>>>>>> a good approach or not. Now I am working on this.
>>>>>> 
>>>>>> Thanks.
>>>>>> 
>>>>>> On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
>>>>> xenia_khailenka@tut.by
>>>>>>> wrote:
>>>>>> 
>>>>>>>>>>>> 
>>>>>>> 1:07
>>>>>>> Eshan Sudharaka
>>>>>>> Hi , what is the reason to do setEnable(false )  for some items in
>>>>> file
>>>>>>> menu
>>>>>>> in cayenne modeler in your plugin ?
>>>>>>> I dint get the point
>>>>>>>>>>>>>> 
>>>>>>> Eshan means this one:
>>>>>>> 
>>>>>>> if (NewProjectAction.getActionName().equals(name)
>>>>>>> +                        ||
>>>>>> OpenProjectAction.getActionName().equals(name)
>>>>>>> +                        ||
>> ProjectAction.getActionName().equals(name)
>>>>>>> +                        || "Recent Projects".equals(name)) {
>>>>>>> +                    item.setEnabled(false);
>>>>>>> +                }
>>>>>>> All these actions perform manipulations with some another projects,
>>>>> but
>>>>>> we
>>>>>>> are dealing with the selected project from Eclipse, so, it was
>>>>> considered
>>>>>>> then that the switching between projects is undesirable when working
>>>>> with
>>>>>>> plugin - it may happen that we don't have the correspondent project
>> in
>>>>>>> Eclipse, and on change will try to update it...
>>>>>>> 
>>>>>>> But I think we can enable the "NewProjectAction" for example, to
>>>>> create
>>>>>> the
>>>>>>> cayenne project by the plugin....or we can just leave these buttons
>>>>> for
>>>>>> now
>>>>>>> 
>>>>>>> 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
>>>>>>> 
>>>>>>>> Sounds good.
>>>>>>>> 
>>>>>>>> We might still want to change the naming convention for consistency
>>>>>> down
>>>>>>>> the road, but good to hear there's no urgency.
>>>>>>>> 
>>>>>>>> Andrus
>>>>>>>> 
>>>>>>>> On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
>>>>>>>> 
>>>>>>>>> Hi ,
>>>>>>>>> I am sorry. I found a way to check the content of the XML files
>>>>>>>> (currently
>>>>>>>>> root element) and if it is cayenne project file then load cayenne
>>>>>> icon
>>>>>>> in
>>>>>>>>> eclipse. So no need of changing file naming conventions.
>>>>>>>>> 
>>>>>>>>> On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
>>>>>>> andrus@objectstyle.org
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
>>>>>>>>>> 
>>>>>>>>>>> However... nothing prevents us from changing the naming
>>>>> convention
>>>>>>>> again.
>>>>>>>>>> After all 3.1 is not final yet (not even Beta). We might as well
>>>>>> adopt
>>>>>>>>>> another "double extension":
>>>>>>>>>>> 
>>>>>>>>>>> Main project file: xyz.cayenne.xml
>>>>>>>>>>> DataMap file: xyz.map.xml
>>>>>>>>>>> 
>>>>>>>>>>> This will ensure both types of files follow a similar
>>>>> convention,
>>>>>> and
>>>>>>>>>> make them Eclipse-friendly.
>>>>>>>>>> 
>>>>>>>>>> Also the beauty of Cayenne 3.1 is that the name of the project
>>>>> file
>>>>>> is
>>>>>>>>>> specified explicitly when the runtime is started, so the file can
>>>>>>> really
>>>>>>>> be
>>>>>>>>>> called anything (doesn't even have to have .xml extension). So
>>>>> the
>>>>>>> focus
>>>>>>>> of
>>>>>>>>>> this discussion is the tools (CayenneModeler, Eclipse, etc..),
>>>>> not
>>>>>> the
>>>>>>>>>> runtime.
>>>>>>>>>> 
>>>>>>>>>> Andrus
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> *~Thanks & Regards~*
>>>>>>>>> ***
>>>>>>>>> *
>>>>>>>>> P.A.Eshan Sudharaka
>>>>>>>>> Dept of Computer Science and Engineering
>>>>>>>>> University of Moratuwa
>>>>>>>>> Sri Lanka
>>>>>>>>> http://esudharaka.blogspot.com/
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Regards, Ksenia Khailenko
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> *~Thanks & Regards~*
>>>>>> ***
>>>>>> *
>>>>>> P.A.Eshan Sudharaka
>>>>>> Dept of Computer Science and Engineering
>>>>>> University of Moratuwa
>>>>>> Sri Lanka
>>>>>> http://esudharaka.blogspot.com/
>>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Regards, Ksenia Khailenko
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> *~Thanks & Regards~*
>>>> ***
>>>> *
>>>> P.A.Eshan Sudharaka
>>>> Dept of Computer Science and Engineering
>>>> University of Moratuwa
>>>> Sri Lanka
>>>> http://esudharaka.blogspot.com/
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Regards, Ksenia Khailenko
>> 
>> 
> 
> 
> -- 
> *~Thanks & Regards~*
> ***
> *
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/


Re: Gsoc Project Update

Posted by Eshan Sudharaka <es...@gmail.com>.
Thanks for thevaluable ideas which leads me to do my job properly and I got
a e-mail from Google Open Source Programs Team and according to it I have
passed from the midterm evaluation. And Special thank should goes to Ksenia.
Looking forward to work with the team for next updates.

On Mon, Jul 11, 2011 at 11:54 AM, Andrus Adamchik <an...@objectstyle.org>wrote:

> I have no problem if we change DefaultActionManager etc. on the Cayenne end
> to be easily extendable class. CayenneModeler configuration of internal
> classes has lots of shortcuts, as it never assumed other apps using or
> extending this code. Now it is time to evolve it.
>
> Andrus
>
> On Jul 10, 2011, at 1:12 PM, Ksenia Khailenko wrote:
>
> > Andrus, look at this one, please. We have the DefaultActionManager with
> > final property which we want to override. It is possible to create an
> > another implementation of ActionManager, but in fact in this case, we
> > duplicate a lot of code...
> >
> > 2011/7/2 Eshan Sudharaka <es...@gmail.com>
> >
> >> Yes. It is possible. I have attached patch files with this. For this
> patch
> >> I had to add default constructors to following  classes.
> >>
> >> CayenneController.java
> >> CayenneModelerController.java
> >>
> >> trunk.patch includes this modification (Actualy no need to apply
> >> trunk.patch just add default constructors to those clases)
> >>
> >> Second patch includes the modifications included in this thread.
> >>
> >>
> >> On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <
> xenia_khailenka@tut.by>wrote:
> >>
> >>> May be it would be better not to extend from DefaultActionManager, but
> >>> implement it's interface? Is it possible?
> >>>
> >>> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
> >>>
> >>>> Thanks. I got it. I have another problem in implementing plugin
> actions
> >>>> classes. We can register external Actions to actionMap in
> >>>> DefaultActionManager class. So I registered PlugingProject class and
> add
> >>>> that class in to file menu of CayenneModelerFrame and run my plugin.
> >>> Then
> >>>> it
> >>>> seems project close action is menu item is disabled .I think I need
> add
> >>>> PluginProjectAction class   following in DefaultActionManager class.
> >>>>
> >>>> static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
> >>>>           RevertAction.class.getName(),
> >>>>           ProjectAction.class.getName(),
> >>>>           ValidateAction.class.getName(),
> >>>>           SaveAsAction.class.getName(),
> >>>>           FindAction.class.getName());
> >>>>
> >>>> Here I should add my PluginProjectAction class. I have extended
> >>>> PluginActionManager from DefaultActionManager class. Since this is a
> >>> static
> >>>> this list is not inherited to child class and also we can not add any
> >>> thing
> >>>> since it is final. How to overcome this issue ? We can do this by
> >>> modifying
> >>>> parent class ( DefaultActionManager class ) and I am not sure whether
> it
> >>> is
> >>>> a good approach or not. Now I am working on this.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
> >>> xenia_khailenka@tut.by
> >>>>> wrote:
> >>>>
> >>>>>>>>>>
> >>>>> 1:07
> >>>>> Eshan Sudharaka
> >>>>> Hi , what is the reason to do setEnable(false )  for some items in
> >>> file
> >>>>> menu
> >>>>> in cayenne modeler in your plugin ?
> >>>>> I dint get the point
> >>>>>>>>>>>>
> >>>>> Eshan means this one:
> >>>>>
> >>>>> if (NewProjectAction.getActionName().equals(name)
> >>>>> +                        ||
> >>>> OpenProjectAction.getActionName().equals(name)
> >>>>> +                        ||
> ProjectAction.getActionName().equals(name)
> >>>>> +                        || "Recent Projects".equals(name)) {
> >>>>> +                    item.setEnabled(false);
> >>>>> +                }
> >>>>> All these actions perform manipulations with some another projects,
> >>> but
> >>>> we
> >>>>> are dealing with the selected project from Eclipse, so, it was
> >>> considered
> >>>>> then that the switching between projects is undesirable when working
> >>> with
> >>>>> plugin - it may happen that we don't have the correspondent project
> in
> >>>>> Eclipse, and on change will try to update it...
> >>>>>
> >>>>> But I think we can enable the "NewProjectAction" for example, to
> >>> create
> >>>> the
> >>>>> cayenne project by the plugin....or we can just leave these buttons
> >>> for
> >>>> now
> >>>>>
> >>>>> 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
> >>>>>
> >>>>>> Sounds good.
> >>>>>>
> >>>>>> We might still want to change the naming convention for consistency
> >>>> down
> >>>>>> the road, but good to hear there's no urgency.
> >>>>>>
> >>>>>> Andrus
> >>>>>>
> >>>>>> On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
> >>>>>>
> >>>>>>> Hi ,
> >>>>>>> I am sorry. I found a way to check the content of the XML files
> >>>>>> (currently
> >>>>>>> root element) and if it is cayenne project file then load cayenne
> >>>> icon
> >>>>> in
> >>>>>>> eclipse. So no need of changing file naming conventions.
> >>>>>>>
> >>>>>>> On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
> >>>>> andrus@objectstyle.org
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> >>>>>>>>
> >>>>>>>>> However... nothing prevents us from changing the naming
> >>> convention
> >>>>>> again.
> >>>>>>>> After all 3.1 is not final yet (not even Beta). We might as well
> >>>> adopt
> >>>>>>>> another "double extension":
> >>>>>>>>>
> >>>>>>>>> Main project file: xyz.cayenne.xml
> >>>>>>>>> DataMap file: xyz.map.xml
> >>>>>>>>>
> >>>>>>>>> This will ensure both types of files follow a similar
> >>> convention,
> >>>> and
> >>>>>>>> make them Eclipse-friendly.
> >>>>>>>>
> >>>>>>>> Also the beauty of Cayenne 3.1 is that the name of the project
> >>> file
> >>>> is
> >>>>>>>> specified explicitly when the runtime is started, so the file can
> >>>>> really
> >>>>>> be
> >>>>>>>> called anything (doesn't even have to have .xml extension). So
> >>> the
> >>>>> focus
> >>>>>> of
> >>>>>>>> this discussion is the tools (CayenneModeler, Eclipse, etc..),
> >>> not
> >>>> the
> >>>>>>>> runtime.
> >>>>>>>>
> >>>>>>>> Andrus
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> *~Thanks & Regards~*
> >>>>>>> ***
> >>>>>>> *
> >>>>>>> P.A.Eshan Sudharaka
> >>>>>>> Dept of Computer Science and Engineering
> >>>>>>> University of Moratuwa
> >>>>>>> Sri Lanka
> >>>>>>> http://esudharaka.blogspot.com/
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Regards, Ksenia Khailenko
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> *~Thanks & Regards~*
> >>>> ***
> >>>> *
> >>>> P.A.Eshan Sudharaka
> >>>> Dept of Computer Science and Engineering
> >>>> University of Moratuwa
> >>>> Sri Lanka
> >>>> http://esudharaka.blogspot.com/
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards, Ksenia Khailenko
> >>>
> >>
> >>
> >>
> >> --
> >> *~Thanks & Regards~*
> >> ***
> >> *
> >> P.A.Eshan Sudharaka
> >> Dept of Computer Science and Engineering
> >> University of Moratuwa
> >> Sri Lanka
> >> http://esudharaka.blogspot.com/
> >>
> >>
> >
> >
> > --
> > Regards, Ksenia Khailenko
>
>


-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
I have no problem if we change DefaultActionManager etc. on the Cayenne end to be easily extendable class. CayenneModeler configuration of internal classes has lots of shortcuts, as it never assumed other apps using or extending this code. Now it is time to evolve it.

Andrus

On Jul 10, 2011, at 1:12 PM, Ksenia Khailenko wrote:

> Andrus, look at this one, please. We have the DefaultActionManager with
> final property which we want to override. It is possible to create an
> another implementation of ActionManager, but in fact in this case, we
> duplicate a lot of code...
> 
> 2011/7/2 Eshan Sudharaka <es...@gmail.com>
> 
>> Yes. It is possible. I have attached patch files with this. For this patch
>> I had to add default constructors to following  classes.
>> 
>> CayenneController.java
>> CayenneModelerController.java
>> 
>> trunk.patch includes this modification (Actualy no need to apply
>> trunk.patch just add default constructors to those clases)
>> 
>> Second patch includes the modifications included in this thread.
>> 
>> 
>> On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <xe...@tut.by>wrote:
>> 
>>> May be it would be better not to extend from DefaultActionManager, but
>>> implement it's interface? Is it possible?
>>> 
>>> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
>>> 
>>>> Thanks. I got it. I have another problem in implementing plugin actions
>>>> classes. We can register external Actions to actionMap in
>>>> DefaultActionManager class. So I registered PlugingProject class and add
>>>> that class in to file menu of CayenneModelerFrame and run my plugin.
>>> Then
>>>> it
>>>> seems project close action is menu item is disabled .I think I need add
>>>> PluginProjectAction class   following in DefaultActionManager class.
>>>> 
>>>> static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
>>>>           RevertAction.class.getName(),
>>>>           ProjectAction.class.getName(),
>>>>           ValidateAction.class.getName(),
>>>>           SaveAsAction.class.getName(),
>>>>           FindAction.class.getName());
>>>> 
>>>> Here I should add my PluginProjectAction class. I have extended
>>>> PluginActionManager from DefaultActionManager class. Since this is a
>>> static
>>>> this list is not inherited to child class and also we can not add any
>>> thing
>>>> since it is final. How to overcome this issue ? We can do this by
>>> modifying
>>>> parent class ( DefaultActionManager class ) and I am not sure whether it
>>> is
>>>> a good approach or not. Now I am working on this.
>>>> 
>>>> Thanks.
>>>> 
>>>> On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
>>> xenia_khailenka@tut.by
>>>>> wrote:
>>>> 
>>>>>>>>>> 
>>>>> 1:07
>>>>> Eshan Sudharaka
>>>>> Hi , what is the reason to do setEnable(false )  for some items in
>>> file
>>>>> menu
>>>>> in cayenne modeler in your plugin ?
>>>>> I dint get the point
>>>>>>>>>>>> 
>>>>> Eshan means this one:
>>>>> 
>>>>> if (NewProjectAction.getActionName().equals(name)
>>>>> +                        ||
>>>> OpenProjectAction.getActionName().equals(name)
>>>>> +                        || ProjectAction.getActionName().equals(name)
>>>>> +                        || "Recent Projects".equals(name)) {
>>>>> +                    item.setEnabled(false);
>>>>> +                }
>>>>> All these actions perform manipulations with some another projects,
>>> but
>>>> we
>>>>> are dealing with the selected project from Eclipse, so, it was
>>> considered
>>>>> then that the switching between projects is undesirable when working
>>> with
>>>>> plugin - it may happen that we don't have the correspondent project in
>>>>> Eclipse, and on change will try to update it...
>>>>> 
>>>>> But I think we can enable the "NewProjectAction" for example, to
>>> create
>>>> the
>>>>> cayenne project by the plugin....or we can just leave these buttons
>>> for
>>>> now
>>>>> 
>>>>> 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
>>>>> 
>>>>>> Sounds good.
>>>>>> 
>>>>>> We might still want to change the naming convention for consistency
>>>> down
>>>>>> the road, but good to hear there's no urgency.
>>>>>> 
>>>>>> Andrus
>>>>>> 
>>>>>> On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
>>>>>> 
>>>>>>> Hi ,
>>>>>>> I am sorry. I found a way to check the content of the XML files
>>>>>> (currently
>>>>>>> root element) and if it is cayenne project file then load cayenne
>>>> icon
>>>>> in
>>>>>>> eclipse. So no need of changing file naming conventions.
>>>>>>> 
>>>>>>> On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
>>>>> andrus@objectstyle.org
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
>>>>>>>> 
>>>>>>>>> However... nothing prevents us from changing the naming
>>> convention
>>>>>> again.
>>>>>>>> After all 3.1 is not final yet (not even Beta). We might as well
>>>> adopt
>>>>>>>> another "double extension":
>>>>>>>>> 
>>>>>>>>> Main project file: xyz.cayenne.xml
>>>>>>>>> DataMap file: xyz.map.xml
>>>>>>>>> 
>>>>>>>>> This will ensure both types of files follow a similar
>>> convention,
>>>> and
>>>>>>>> make them Eclipse-friendly.
>>>>>>>> 
>>>>>>>> Also the beauty of Cayenne 3.1 is that the name of the project
>>> file
>>>> is
>>>>>>>> specified explicitly when the runtime is started, so the file can
>>>>> really
>>>>>> be
>>>>>>>> called anything (doesn't even have to have .xml extension). So
>>> the
>>>>> focus
>>>>>> of
>>>>>>>> this discussion is the tools (CayenneModeler, Eclipse, etc..),
>>> not
>>>> the
>>>>>>>> runtime.
>>>>>>>> 
>>>>>>>> Andrus
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> *~Thanks & Regards~*
>>>>>>> ***
>>>>>>> *
>>>>>>> P.A.Eshan Sudharaka
>>>>>>> Dept of Computer Science and Engineering
>>>>>>> University of Moratuwa
>>>>>>> Sri Lanka
>>>>>>> http://esudharaka.blogspot.com/
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Regards, Ksenia Khailenko
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> *~Thanks & Regards~*
>>>> ***
>>>> *
>>>> P.A.Eshan Sudharaka
>>>> Dept of Computer Science and Engineering
>>>> University of Moratuwa
>>>> Sri Lanka
>>>> http://esudharaka.blogspot.com/
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Regards, Ksenia Khailenko
>>> 
>> 
>> 
>> 
>> --
>> *~Thanks & Regards~*
>> ***
>> *
>> P.A.Eshan Sudharaka
>> Dept of Computer Science and Engineering
>> University of Moratuwa
>> Sri Lanka
>> http://esudharaka.blogspot.com/
>> 
>> 
> 
> 
> -- 
> Regards, Ksenia Khailenko


Re: Gsoc Project Update

Posted by Ksenia Khailenko <xe...@tut.by>.
Andrus, look at this one, please. We have the DefaultActionManager with
final property which we want to override. It is possible to create an
another implementation of ActionManager, but in fact in this case, we
duplicate a lot of code...

2011/7/2 Eshan Sudharaka <es...@gmail.com>

> Yes. It is possible. I have attached patch files with this. For this patch
> I had to add default constructors to following  classes.
>
> CayenneController.java
> CayenneModelerController.java
>
> trunk.patch includes this modification (Actualy no need to apply
> trunk.patch just add default constructors to those clases)
>
> Second patch includes the modifications included in this thread.
>
>
> On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <xe...@tut.by>wrote:
>
>> May be it would be better not to extend from DefaultActionManager, but
>> implement it's interface? Is it possible?
>>
>> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
>>
>> > Thanks. I got it. I have another problem in implementing plugin actions
>> > classes. We can register external Actions to actionMap in
>> > DefaultActionManager class. So I registered PlugingProject class and add
>> > that class in to file menu of CayenneModelerFrame and run my plugin.
>> Then
>> > it
>> > seems project close action is menu item is disabled .I think I need add
>> > PluginProjectAction class   following in DefaultActionManager class.
>> >
>> >  static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
>> >            RevertAction.class.getName(),
>> >            ProjectAction.class.getName(),
>> >            ValidateAction.class.getName(),
>> >            SaveAsAction.class.getName(),
>> >            FindAction.class.getName());
>> >
>> > Here I should add my PluginProjectAction class. I have extended
>> > PluginActionManager from DefaultActionManager class. Since this is a
>> static
>> > this list is not inherited to child class and also we can not add any
>> thing
>> > since it is final. How to overcome this issue ? We can do this by
>> modifying
>> > parent class ( DefaultActionManager class ) and I am not sure whether it
>> is
>> > a good approach or not. Now I am working on this.
>> >
>> > Thanks.
>> >
>> > On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
>> xenia_khailenka@tut.by
>> > >wrote:
>> >
>> > > >>>>>
>> > > 1:07
>> > > Eshan Sudharaka
>> > > Hi , what is the reason to do setEnable(false )  for some items in
>> file
>> > > menu
>> > > in cayenne modeler in your plugin ?
>> > > I dint get the point
>> > > >>>>>>>
>> > > Eshan means this one:
>> > >
>> > > if (NewProjectAction.getActionName().equals(name)
>> > > +                        ||
>> > OpenProjectAction.getActionName().equals(name)
>> > > +                        || ProjectAction.getActionName().equals(name)
>> > > +                        || "Recent Projects".equals(name)) {
>> > > +                    item.setEnabled(false);
>> > > +                }
>> > > All these actions perform manipulations with some another projects,
>> but
>> > we
>> > > are dealing with the selected project from Eclipse, so, it was
>> considered
>> > > then that the switching between projects is undesirable when working
>> with
>> > > plugin - it may happen that we don't have the correspondent project in
>> > > Eclipse, and on change will try to update it...
>> > >
>> > > But I think we can enable the "NewProjectAction" for example, to
>> create
>> > the
>> > > cayenne project by the plugin....or we can just leave these buttons
>> for
>> > now
>> > >
>> > > 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
>> > >
>> > > > Sounds good.
>> > > >
>> > > > We might still want to change the naming convention for consistency
>> > down
>> > > > the road, but good to hear there's no urgency.
>> > > >
>> > > > Andrus
>> > > >
>> > > > On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
>> > > >
>> > > > > Hi ,
>> > > > >  I am sorry. I found a way to check the content of the XML files
>> > > > (currently
>> > > > > root element) and if it is cayenne project file then load cayenne
>> > icon
>> > > in
>> > > > > eclipse. So no need of changing file naming conventions.
>> > > > >
>> > > > > On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
>> > > andrus@objectstyle.org
>> > > > >wrote:
>> > > > >
>> > > > >>
>> > > > >> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
>> > > > >>
>> > > > >>> However... nothing prevents us from changing the naming
>> convention
>> > > > again.
>> > > > >> After all 3.1 is not final yet (not even Beta). We might as well
>> > adopt
>> > > > >> another "double extension":
>> > > > >>>
>> > > > >>> Main project file: xyz.cayenne.xml
>> > > > >>> DataMap file: xyz.map.xml
>> > > > >>>
>> > > > >>> This will ensure both types of files follow a similar
>> convention,
>> > and
>> > > > >> make them Eclipse-friendly.
>> > > > >>
>> > > > >> Also the beauty of Cayenne 3.1 is that the name of the project
>> file
>> > is
>> > > > >> specified explicitly when the runtime is started, so the file can
>> > > really
>> > > > be
>> > > > >> called anything (doesn't even have to have .xml extension). So
>> the
>> > > focus
>> > > > of
>> > > > >> this discussion is the tools (CayenneModeler, Eclipse, etc..),
>> not
>> > the
>> > > > >> runtime.
>> > > > >>
>> > > > >> Andrus
>> > > > >>
>> > > > >>
>> > > > >
>> > > > >
>> > > > > --
>> > > > > *~Thanks & Regards~*
>> > > > > ***
>> > > > > *
>> > > > > P.A.Eshan Sudharaka
>> > > > > Dept of Computer Science and Engineering
>> > > > > University of Moratuwa
>> > > > > Sri Lanka
>> > > > > http://esudharaka.blogspot.com/
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Regards, Ksenia Khailenko
>> > >
>> >
>> >
>> >
>> > --
>> > *~Thanks & Regards~*
>> > ***
>> > *
>> > P.A.Eshan Sudharaka
>> > Dept of Computer Science and Engineering
>> > University of Moratuwa
>> > Sri Lanka
>> > http://esudharaka.blogspot.com/
>> >
>>
>>
>>
>> --
>> Regards, Ksenia Khailenko
>>
>
>
>
> --
> *~Thanks & Regards~*
> ***
> *
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/
>
>


-- 
Regards, Ksenia Khailenko

Re: Gsoc Project Update

Posted by Eshan Sudharaka <es...@gmail.com>.
Yes. It is possible. I have attached patch files with this. For this patch I
had to add default constructors to following  classes.

CayenneController.java
CayenneModelerController.java

trunk.patch includes this modification (Actualy no need to apply trunk.patch
just add default constructors to those clases)

Second patch includes the modifications included in this thread.

On Fri, Jul 1, 2011 at 8:59 PM, Ksenia Khailenko <xe...@tut.by>wrote:

> May be it would be better not to extend from DefaultActionManager, but
> implement it's interface? Is it possible?
>
> 2011/7/1 Eshan Sudharaka <es...@gmail.com>
>
> > Thanks. I got it. I have another problem in implementing plugin actions
> > classes. We can register external Actions to actionMap in
> > DefaultActionManager class. So I registered PlugingProject class and add
> > that class in to file menu of CayenneModelerFrame and run my plugin. Then
> > it
> > seems project close action is menu item is disabled .I think I need add
> > PluginProjectAction class   following in DefaultActionManager class.
> >
> >  static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
> >            RevertAction.class.getName(),
> >            ProjectAction.class.getName(),
> >            ValidateAction.class.getName(),
> >            SaveAsAction.class.getName(),
> >            FindAction.class.getName());
> >
> > Here I should add my PluginProjectAction class. I have extended
> > PluginActionManager from DefaultActionManager class. Since this is a
> static
> > this list is not inherited to child class and also we can not add any
> thing
> > since it is final. How to overcome this issue ? We can do this by
> modifying
> > parent class ( DefaultActionManager class ) and I am not sure whether it
> is
> > a good approach or not. Now I am working on this.
> >
> > Thanks.
> >
> > On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <
> xenia_khailenka@tut.by
> > >wrote:
> >
> > > >>>>>
> > > 1:07
> > > Eshan Sudharaka
> > > Hi , what is the reason to do setEnable(false )  for some items in file
> > > menu
> > > in cayenne modeler in your plugin ?
> > > I dint get the point
> > > >>>>>>>
> > > Eshan means this one:
> > >
> > > if (NewProjectAction.getActionName().equals(name)
> > > +                        ||
> > OpenProjectAction.getActionName().equals(name)
> > > +                        || ProjectAction.getActionName().equals(name)
> > > +                        || "Recent Projects".equals(name)) {
> > > +                    item.setEnabled(false);
> > > +                }
> > > All these actions perform manipulations with some another projects, but
> > we
> > > are dealing with the selected project from Eclipse, so, it was
> considered
> > > then that the switching between projects is undesirable when working
> with
> > > plugin - it may happen that we don't have the correspondent project in
> > > Eclipse, and on change will try to update it...
> > >
> > > But I think we can enable the "NewProjectAction" for example, to create
> > the
> > > cayenne project by the plugin....or we can just leave these buttons for
> > now
> > >
> > > 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
> > >
> > > > Sounds good.
> > > >
> > > > We might still want to change the naming convention for consistency
> > down
> > > > the road, but good to hear there's no urgency.
> > > >
> > > > Andrus
> > > >
> > > > On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
> > > >
> > > > > Hi ,
> > > > >  I am sorry. I found a way to check the content of the XML files
> > > > (currently
> > > > > root element) and if it is cayenne project file then load cayenne
> > icon
> > > in
> > > > > eclipse. So no need of changing file naming conventions.
> > > > >
> > > > > On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
> > > andrus@objectstyle.org
> > > > >wrote:
> > > > >
> > > > >>
> > > > >> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> > > > >>
> > > > >>> However... nothing prevents us from changing the naming
> convention
> > > > again.
> > > > >> After all 3.1 is not final yet (not even Beta). We might as well
> > adopt
> > > > >> another "double extension":
> > > > >>>
> > > > >>> Main project file: xyz.cayenne.xml
> > > > >>> DataMap file: xyz.map.xml
> > > > >>>
> > > > >>> This will ensure both types of files follow a similar convention,
> > and
> > > > >> make them Eclipse-friendly.
> > > > >>
> > > > >> Also the beauty of Cayenne 3.1 is that the name of the project
> file
> > is
> > > > >> specified explicitly when the runtime is started, so the file can
> > > really
> > > > be
> > > > >> called anything (doesn't even have to have .xml extension). So the
> > > focus
> > > > of
> > > > >> this discussion is the tools (CayenneModeler, Eclipse, etc..), not
> > the
> > > > >> runtime.
> > > > >>
> > > > >> Andrus
> > > > >>
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > *~Thanks & Regards~*
> > > > > ***
> > > > > *
> > > > > P.A.Eshan Sudharaka
> > > > > Dept of Computer Science and Engineering
> > > > > University of Moratuwa
> > > > > Sri Lanka
> > > > > http://esudharaka.blogspot.com/
> > > >
> > > >
> > >
> > >
> > > --
> > > Regards, Ksenia Khailenko
> > >
> >
> >
> >
> > --
> > *~Thanks & Regards~*
> > ***
> > *
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
> > http://esudharaka.blogspot.com/
> >
>
>
>
> --
> Regards, Ksenia Khailenko
>



-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Ksenia Khailenko <xe...@tut.by>.
May be it would be better not to extend from DefaultActionManager, but
implement it's interface? Is it possible?

2011/7/1 Eshan Sudharaka <es...@gmail.com>

> Thanks. I got it. I have another problem in implementing plugin actions
> classes. We can register external Actions to actionMap in
> DefaultActionManager class. So I registered PlugingProject class and add
> that class in to file menu of CayenneModelerFrame and run my plugin. Then
> it
> seems project close action is menu item is disabled .I think I need add
> PluginProjectAction class   following in DefaultActionManager class.
>
>  static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
>            RevertAction.class.getName(),
>            ProjectAction.class.getName(),
>            ValidateAction.class.getName(),
>            SaveAsAction.class.getName(),
>            FindAction.class.getName());
>
> Here I should add my PluginProjectAction class. I have extended
> PluginActionManager from DefaultActionManager class. Since this is a static
> this list is not inherited to child class and also we can not add any thing
> since it is final. How to overcome this issue ? We can do this by modifying
> parent class ( DefaultActionManager class ) and I am not sure whether it is
> a good approach or not. Now I am working on this.
>
> Thanks.
>
> On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <xenia_khailenka@tut.by
> >wrote:
>
> > >>>>>
> > 1:07
> > Eshan Sudharaka
> > Hi , what is the reason to do setEnable(false )  for some items in file
> > menu
> > in cayenne modeler in your plugin ?
> > I dint get the point
> > >>>>>>>
> > Eshan means this one:
> >
> > if (NewProjectAction.getActionName().equals(name)
> > +                        ||
> OpenProjectAction.getActionName().equals(name)
> > +                        || ProjectAction.getActionName().equals(name)
> > +                        || "Recent Projects".equals(name)) {
> > +                    item.setEnabled(false);
> > +                }
> > All these actions perform manipulations with some another projects, but
> we
> > are dealing with the selected project from Eclipse, so, it was considered
> > then that the switching between projects is undesirable when working with
> > plugin - it may happen that we don't have the correspondent project in
> > Eclipse, and on change will try to update it...
> >
> > But I think we can enable the "NewProjectAction" for example, to create
> the
> > cayenne project by the plugin....or we can just leave these buttons for
> now
> >
> > 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
> >
> > > Sounds good.
> > >
> > > We might still want to change the naming convention for consistency
> down
> > > the road, but good to hear there's no urgency.
> > >
> > > Andrus
> > >
> > > On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
> > >
> > > > Hi ,
> > > >  I am sorry. I found a way to check the content of the XML files
> > > (currently
> > > > root element) and if it is cayenne project file then load cayenne
> icon
> > in
> > > > eclipse. So no need of changing file naming conventions.
> > > >
> > > > On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
> > andrus@objectstyle.org
> > > >wrote:
> > > >
> > > >>
> > > >> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> > > >>
> > > >>> However... nothing prevents us from changing the naming convention
> > > again.
> > > >> After all 3.1 is not final yet (not even Beta). We might as well
> adopt
> > > >> another "double extension":
> > > >>>
> > > >>> Main project file: xyz.cayenne.xml
> > > >>> DataMap file: xyz.map.xml
> > > >>>
> > > >>> This will ensure both types of files follow a similar convention,
> and
> > > >> make them Eclipse-friendly.
> > > >>
> > > >> Also the beauty of Cayenne 3.1 is that the name of the project file
> is
> > > >> specified explicitly when the runtime is started, so the file can
> > really
> > > be
> > > >> called anything (doesn't even have to have .xml extension). So the
> > focus
> > > of
> > > >> this discussion is the tools (CayenneModeler, Eclipse, etc..), not
> the
> > > >> runtime.
> > > >>
> > > >> Andrus
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > *~Thanks & Regards~*
> > > > ***
> > > > *
> > > > P.A.Eshan Sudharaka
> > > > Dept of Computer Science and Engineering
> > > > University of Moratuwa
> > > > Sri Lanka
> > > > http://esudharaka.blogspot.com/
> > >
> > >
> >
> >
> > --
> > Regards, Ksenia Khailenko
> >
>
>
>
> --
> *~Thanks & Regards~*
> ***
> *
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/
>



-- 
Regards, Ksenia Khailenko

Re: Gsoc Project Update

Posted by Eshan Sudharaka <es...@gmail.com>.
Thanks. I got it. I have another problem in implementing plugin actions
classes. We can register external Actions to actionMap in
DefaultActionManager class. So I registered PlugingProject class and add
that class in to file menu of CayenneModelerFrame and run my plugin. Then it
seems project close action is menu item is disabled .I think I need add
PluginProjectAction class   following in DefaultActionManager class.

  static final Collection<String> PROJECT_ACTIONS = Arrays.asList(
            RevertAction.class.getName(),
            ProjectAction.class.getName(),
            ValidateAction.class.getName(),
            SaveAsAction.class.getName(),
            FindAction.class.getName());

Here I should add my PluginProjectAction class. I have extended
PluginActionManager from DefaultActionManager class. Since this is a static
this list is not inherited to child class and also we can not add any thing
since it is final. How to overcome this issue ? We can do this by modifying
parent class ( DefaultActionManager class ) and I am not sure whether it is
a good approach or not. Now I am working on this.

Thanks.

On Thu, Jun 30, 2011 at 7:04 PM, Ksenia Khailenko <xe...@tut.by>wrote:

> >>>>>
> 1:07
> Eshan Sudharaka
> Hi , what is the reason to do setEnable(false )  for some items in file
> menu
> in cayenne modeler in your plugin ?
> I dint get the point
> >>>>>>>
> Eshan means this one:
>
> if (NewProjectAction.getActionName().equals(name)
> +                        || OpenProjectAction.getActionName().equals(name)
> +                        || ProjectAction.getActionName().equals(name)
> +                        || "Recent Projects".equals(name)) {
> +                    item.setEnabled(false);
> +                }
> All these actions perform manipulations with some another projects, but we
> are dealing with the selected project from Eclipse, so, it was considered
> then that the switching between projects is undesirable when working with
> plugin - it may happen that we don't have the correspondent project in
> Eclipse, and on change will try to update it...
>
> But I think we can enable the "NewProjectAction" for example, to create the
> cayenne project by the plugin....or we can just leave these buttons for now
>
> 2011/6/28 Andrus Adamchik <an...@objectstyle.org>
>
> > Sounds good.
> >
> > We might still want to change the naming convention for consistency down
> > the road, but good to hear there's no urgency.
> >
> > Andrus
> >
> > On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
> >
> > > Hi ,
> > >  I am sorry. I found a way to check the content of the XML files
> > (currently
> > > root element) and if it is cayenne project file then load cayenne icon
> in
> > > eclipse. So no need of changing file naming conventions.
> > >
> > > On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <
> andrus@objectstyle.org
> > >wrote:
> > >
> > >>
> > >> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> > >>
> > >>> However... nothing prevents us from changing the naming convention
> > again.
> > >> After all 3.1 is not final yet (not even Beta). We might as well adopt
> > >> another "double extension":
> > >>>
> > >>> Main project file: xyz.cayenne.xml
> > >>> DataMap file: xyz.map.xml
> > >>>
> > >>> This will ensure both types of files follow a similar convention, and
> > >> make them Eclipse-friendly.
> > >>
> > >> Also the beauty of Cayenne 3.1 is that the name of the project file is
> > >> specified explicitly when the runtime is started, so the file can
> really
> > be
> > >> called anything (doesn't even have to have .xml extension). So the
> focus
> > of
> > >> this discussion is the tools (CayenneModeler, Eclipse, etc..), not the
> > >> runtime.
> > >>
> > >> Andrus
> > >>
> > >>
> > >
> > >
> > > --
> > > *~Thanks & Regards~*
> > > ***
> > > *
> > > P.A.Eshan Sudharaka
> > > Dept of Computer Science and Engineering
> > > University of Moratuwa
> > > Sri Lanka
> > > http://esudharaka.blogspot.com/
> >
> >
>
>
> --
> Regards, Ksenia Khailenko
>



-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Ksenia Khailenko <xe...@tut.by>.
>>>>>
1:07
Eshan Sudharaka
Hi , what is the reason to do setEnable(false )  for some items in file menu
in cayenne modeler in your plugin ?
I dint get the point
>>>>>>>
Eshan means this one:

if (NewProjectAction.getActionName().equals(name)
+                        || OpenProjectAction.getActionName().equals(name)
+                        || ProjectAction.getActionName().equals(name)
+                        || "Recent Projects".equals(name)) {
+                    item.setEnabled(false);
+                }
All these actions perform manipulations with some another projects, but we
are dealing with the selected project from Eclipse, so, it was considered
then that the switching between projects is undesirable when working with
plugin - it may happen that we don't have the correspondent project in
Eclipse, and on change will try to update it...

But I think we can enable the "NewProjectAction" for example, to create the
cayenne project by the plugin....or we can just leave these buttons for now

2011/6/28 Andrus Adamchik <an...@objectstyle.org>

> Sounds good.
>
> We might still want to change the naming convention for consistency down
> the road, but good to hear there's no urgency.
>
> Andrus
>
> On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:
>
> > Hi ,
> >  I am sorry. I found a way to check the content of the XML files
> (currently
> > root element) and if it is cayenne project file then load cayenne icon in
> > eclipse. So no need of changing file naming conventions.
> >
> > On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <andrus@objectstyle.org
> >wrote:
> >
> >>
> >> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
> >>
> >>> However... nothing prevents us from changing the naming convention
> again.
> >> After all 3.1 is not final yet (not even Beta). We might as well adopt
> >> another "double extension":
> >>>
> >>> Main project file: xyz.cayenne.xml
> >>> DataMap file: xyz.map.xml
> >>>
> >>> This will ensure both types of files follow a similar convention, and
> >> make them Eclipse-friendly.
> >>
> >> Also the beauty of Cayenne 3.1 is that the name of the project file is
> >> specified explicitly when the runtime is started, so the file can really
> be
> >> called anything (doesn't even have to have .xml extension). So the focus
> of
> >> this discussion is the tools (CayenneModeler, Eclipse, etc..), not the
> >> runtime.
> >>
> >> Andrus
> >>
> >>
> >
> >
> > --
> > *~Thanks & Regards~*
> > ***
> > *
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
> > http://esudharaka.blogspot.com/
>
>


-- 
Regards, Ksenia Khailenko

Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
Sounds good. 

We might still want to change the naming convention for consistency down the road, but good to hear there's no urgency.

Andrus

On Jun 28, 2011, at 2:16 PM, Eshan Sudharaka wrote:

> Hi ,
>  I am sorry. I found a way to check the content of the XML files (currently
> root element) and if it is cayenne project file then load cayenne icon in
> eclipse. So no need of changing file naming conventions.
> 
> On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <an...@objectstyle.org>wrote:
> 
>> 
>> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
>> 
>>> However... nothing prevents us from changing the naming convention again.
>> After all 3.1 is not final yet (not even Beta). We might as well adopt
>> another "double extension":
>>> 
>>> Main project file: xyz.cayenne.xml
>>> DataMap file: xyz.map.xml
>>> 
>>> This will ensure both types of files follow a similar convention, and
>> make them Eclipse-friendly.
>> 
>> Also the beauty of Cayenne 3.1 is that the name of the project file is
>> specified explicitly when the runtime is started, so the file can really be
>> called anything (doesn't even have to have .xml extension). So the focus of
>> this discussion is the tools (CayenneModeler, Eclipse, etc..), not the
>> runtime.
>> 
>> Andrus
>> 
>> 
> 
> 
> -- 
> *~Thanks & Regards~*
> ***
> *
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/


Re: Gsoc Project Update

Posted by Eshan Sudharaka <es...@gmail.com>.
Hi ,
  I am sorry. I found a way to check the content of the XML files (currently
root element) and if it is cayenne project file then load cayenne icon in
eclipse. So no need of changing file naming conventions.

On Sun, Jun 26, 2011 at 8:34 PM, Andrus Adamchik <an...@objectstyle.org>wrote:

>
> On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:
>
> > However... nothing prevents us from changing the naming convention again.
> After all 3.1 is not final yet (not even Beta). We might as well adopt
> another "double extension":
> >
> > Main project file: xyz.cayenne.xml
> > DataMap file: xyz.map.xml
> >
> > This will ensure both types of files follow a similar convention, and
> make them Eclipse-friendly.
>
> Also the beauty of Cayenne 3.1 is that the name of the project file is
> specified explicitly when the runtime is started, so the file can really be
> called anything (doesn't even have to have .xml extension). So the focus of
> this discussion is the tools (CayenneModeler, Eclipse, etc..), not the
> runtime.
>
> Andrus
>
>


-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
On Jun 26, 2011, at 5:45 PM, Andrus Adamchik wrote:

> However... nothing prevents us from changing the naming convention again. After all 3.1 is not final yet (not even Beta). We might as well adopt another "double extension":
> 
> Main project file: xyz.cayenne.xml 
> DataMap file: xyz.map.xml
> 
> This will ensure both types of files follow a similar convention, and make them Eclipse-friendly. 

Also the beauty of Cayenne 3.1 is that the name of the project file is specified explicitly when the runtime is started, so the file can really be called anything (doesn't even have to have .xml extension). So the focus of this discussion is the tools (CayenneModeler, Eclipse, etc..), not the runtime.

Andrus


Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
A bit disappointing that Eclipse can't match on a simple filename pattern. We stopped using cayenne.xml in 3.1 as it wasn't flexible enough - it didn't allow multiple projects to exist under the same base url. So yeah for now it seems like we can't create an automated file association.

However... nothing prevents us from changing the naming convention again. After all 3.1 is not final yet (not even Beta). We might as well adopt another "double extension":

Main project file: xyz.cayenne.xml 
DataMap file: xyz.map.xml

This will ensure both types of files follow a similar convention, and make them Eclipse-friendly. 

Andrus


On Jun 26, 2011, at 11:14 AM, Eshan Sudharaka wrote:
> Sorry. I have made a mistake about naming conversion. But still there can be
> various names for Main project file which starts from cayenne. So  it is
> hard to figure out which files should be open with Cayenne modeler.
> According to this<http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_ui_editors.html>we
> can filter files from extension attribute and file name attribute. So
> I
> it seems difficult to set cayenne modeler as the default editor for cayenne
> main project xml file. ( eg : If we have a file name cayenne.xml we can
> configure that name in eclipse plugin so that when double click on that file
> it  opens with the external editor instead open with eclipse xml editor.
> Also we can load icon for that xml file as well ) .
> 
> Once we have not such a specific name we have to open it by File > Open With
> and select our editor.
> 
> 
> On Sun, Jun 26, 2011 at 12:47 PM, Andrus Adamchik <an...@objectstyle.org>wrote:
> 
>> Not sure I am answering the question being asked, but in 3.1, the file
>> naming convention is the following:
>> 
>> Main project file: cayenne-*.xml
>> DataMap file: *.map.xml
>> 
>> Which is pretty deterministic, even if a bit unusual.
>> 
>> Andrus
>> 
>> 
>> On Jun 26, 2011, at 9:05 AM, Eshan Sudharaka wrote:
>>> Hi Ksenia ,
>>>       As you mentioned I went through the code where i deletes
>> cyenne.xml  in UpgradeHandler_V6 class. And then in a case of we are having
>> xyzDomainMap.xml  (with out cayenne.xml) we can not open i with my external
>> editor (cayenne modeler) by default. Because we can filter files according
>> to extension or from a specific name. (can not go for pattern matching and
>> filer  xyzDomainMap.xml using the keyword  DomainMap). So we have to open
>> the DomainMap xml file by  Open With > Cayenne Modeler Plugin (when we
>> double click on DomainMap file is opens with default xml editor ) . I am
>> still figuring out  a way of solving this.
>>> 
>>>         I have attached a patch  by adding java class generation support
>> for my plugin in jira issue page.
>> https://issues.apache.org/jira/browse/CAY-1554
>>> 
>>> --
>>> ~Thanks & Regards~
>>> 
>>> P.A.Eshan Sudharaka
>>> Dept of Computer Science and Engineering
>>> University of Moratuwa
>>> Sri Lanka
>>> http://esudharaka.blogspot.com/
>>> 
>>> <plugin-gsoc.patch>
>> 
>> 
> 
> 
> -- 
> *~Thanks & Regards~*
> ***
> *
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/


Re: Gsoc Project Update

Posted by Eshan Sudharaka <es...@gmail.com>.
Sorry. I have made a mistake about naming conversion. But still there can be
various names for Main project file which starts from cayenne. So  it is
hard to figure out which files should be open with Cayenne modeler.
According to this<http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fextension-points%2Forg_eclipse_ui_editors.html>we
can filter files from extension attribute and file name attribute. So
I
it seems difficult to set cayenne modeler as the default editor for cayenne
main project xml file. ( eg : If we have a file name cayenne.xml we can
configure that name in eclipse plugin so that when double click on that file
it  opens with the external editor instead open with eclipse xml editor.
Also we can load icon for that xml file as well ) .

Once we have not such a specific name we have to open it by File > Open With
and select our editor.


On Sun, Jun 26, 2011 at 12:47 PM, Andrus Adamchik <an...@objectstyle.org>wrote:

> Not sure I am answering the question being asked, but in 3.1, the file
> naming convention is the following:
>
> Main project file: cayenne-*.xml
> DataMap file: *.map.xml
>
> Which is pretty deterministic, even if a bit unusual.
>
> Andrus
>
>
> On Jun 26, 2011, at 9:05 AM, Eshan Sudharaka wrote:
> > Hi Ksenia ,
> >        As you mentioned I went through the code where i deletes
> cyenne.xml  in UpgradeHandler_V6 class. And then in a case of we are having
> xyzDomainMap.xml  (with out cayenne.xml) we can not open i with my external
> editor (cayenne modeler) by default. Because we can filter files according
> to extension or from a specific name. (can not go for pattern matching and
> filer  xyzDomainMap.xml using the keyword  DomainMap). So we have to open
> the DomainMap xml file by  Open With > Cayenne Modeler Plugin (when we
> double click on DomainMap file is opens with default xml editor ) . I am
> still figuring out  a way of solving this.
> >
> >          I have attached a patch  by adding java class generation support
> for my plugin in jira issue page.
> https://issues.apache.org/jira/browse/CAY-1554
> >
> > --
> > ~Thanks & Regards~
> >
> > P.A.Eshan Sudharaka
> > Dept of Computer Science and Engineering
> > University of Moratuwa
> > Sri Lanka
> > http://esudharaka.blogspot.com/
> >
> > <plugin-gsoc.patch>
>
>


-- 
*~Thanks & Regards~*
***
*
P.A.Eshan Sudharaka
Dept of Computer Science and Engineering
University of Moratuwa
Sri Lanka
http://esudharaka.blogspot.com/

Re: Gsoc Project Update

Posted by Andrus Adamchik <an...@objectstyle.org>.
Not sure I am answering the question being asked, but in 3.1, the file naming convention is the following:

Main project file: cayenne-*.xml
DataMap file: *.map.xml

Which is pretty deterministic, even if a bit unusual.

Andrus


On Jun 26, 2011, at 9:05 AM, Eshan Sudharaka wrote:
> Hi Ksenia , 
>        As you mentioned I went through the code where i deletes cyenne.xml  in UpgradeHandler_V6 class. And then in a case of we are having xyzDomainMap.xml  (with out cayenne.xml) we can not open i with my external editor (cayenne modeler) by default. Because we can filter files according to extension or from a specific name. (can not go for pattern matching and filer  xyzDomainMap.xml using the keyword  DomainMap). So we have to open the DomainMap xml file by  Open With > Cayenne Modeler Plugin (when we double click on DomainMap file is opens with default xml editor ) . I am still figuring out  a way of solving this. 
> 
>          I have attached a patch  by adding java class generation support for my plugin in jira issue page.  https://issues.apache.org/jira/browse/CAY-1554 
>  
> -- 
> ~Thanks & Regards~
> 
> P.A.Eshan Sudharaka
> Dept of Computer Science and Engineering 
> University of Moratuwa
> Sri Lanka
> http://esudharaka.blogspot.com/
> 
> <plugin-gsoc.patch>