Home » Modeling » EMF » item provider adapter 'getText' redefinitions
| item provider adapter 'getText' redefinitions [message #417358] |
Thu, 06 March 2008 13:02  |
 Victor Sanchez
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Hello, Ed!
Don't know if you recall an EMF news post thread in which we discussed
about the possibility of factoring out the 'getString' method call result
(I'm talking about item provider adapters here). I have given it more
thought, and although I'm fine with things as they currently are, there is
a simple solution to my previous (and presumably still latent) problem,
which consists of simply factoring out the string that becomes the
parameter for 'getString', not the result of the call to 'getString' itself.
If such actual parameter value would end up becoming a 'static final
String' defined somewhere in the java class, then it would get updated
appropriately if by any chance somebody would be forced to change the name
of the EClass it adapts. Otherwise, such literal string gets buried
and frozen inside a non-regenerable (marked with the 'generated NOT' tag)
'getText' method, with the wrong, obsolete value.
With this literal String factored out in a 'static final String' defined
outside the method, the 'getString' method would still be invoked the same
as before, so localization would be preserved.
As an example, consider the following simplified code belonging to a
'getText' method which, for some reason, has been marked with the
'generated NOT' tag:
return getString("_UI_<EClass_name>_type");
would be replaced by something like this:
return getString(<EClass_name>_key);
Which would require the '<EClass_name>_key' identifier to be also defined:
static final String = "_UI_<EClass_name>_type";
This would only address the unsynchronization problems arisen when renaming
item provider adapter files. The solution of deleting and regenerating
them afresh would not work in that case, except where no customizations
were present, which is unlikely if, for starters, we are assuming the
'getText' method to have already been customized.
I suppose that if such a 'refactoring' is interesting, then other strings
referenced in the 'plugin.properties' would have to be considered as
well, which could be cumbersome. That said, I can perfectly live with
things as they are now. :) I just wanted to let you give a thought on this
little idea.
Cheers!!!
Victor Sánchez
|
|
|
| Re: item provider adapter 'getText' redefinitions [message #417369 is a reply to message #417358] |
Thu, 06 March 2008 16:47  |
Ed Merks
Messages: 33137
Registered: July 2009 |
Senior Member |
|
|
Victor,
Comments below.
Victor Sanchez wrote:
> Hello, Ed!
>
Hey, it's the EMF newsgroup, not Ed's newsgroup!
> Don't know if you recall an EMF news post thread in which we discussed
> about the possibility of factoring out the 'getString' method call result
> (I'm talking about item provider adapters here). I have given it more
> thought, and although I'm fine with things as they currently are, there is
> a simple solution to my previous (and presumably still latent) problem,
> which consists of simply factoring out the string that becomes the
> parameter for 'getString', not the result of the call to 'getString' itself.
>
> If such actual parameter value would end up becoming a 'static final
> String' defined somewhere in the java class, then it would get updated
> appropriately if by any chance somebody would be forced to change the name
> of the EClass it adapts. Otherwise, such literal string gets buried
> and frozen inside a non-regenerable (marked with the 'generated NOT' tag)
> 'getText' method, with the wrong, obsolete value.
>
> With this literal String factored out in a 'static final String' defined
> outside the method, the 'getString' method would still be invoked the same
> as before, so localization would be preserved.
>
> As an example, consider the following simplified code belonging to a
> 'getText' method which, for some reason, has been marked with the
> 'generated NOT' tag:
>
> return getString("_UI_<EClass_name>_type");
>
> would be replaced by something like this:
>
> return getString(<EClass_name>_key);
>
> Which would require the '<EClass_name>_key' identifier to be also defined:
>
> static final String = "_UI_<EClass_name>_type";
>
> This would only address the unsynchronization problems arisen when renaming
> item provider adapter files. The solution of deleting and regenerating
> them afresh would not work in that case, except where no customizations
> were present, which is unlikely if, for starters, we are assuming the
> 'getText' method to have already been customized.
>
> I suppose that if such a 'refactoring' is interesting, then other strings
> referenced in the 'plugin.properties' would have to be considered as
> well, which could be cumbersome. That said, I can perfectly live with
> things as they are now. :) I just wanted to let you give a thought on this
> little idea.
>
I'm not sure this would simplify things so much, but I can see how it
would help with refactoring. A good model-based refactoring system
could look at patterns within strings... The old/existing strings in
the properties file wouldn't be renamed, so refactoring would need to
consider that as well. I'd rather pursue this kind of thing when folks
start to work on refactoring support. I'm hoping there will be a Google
SOC project related to refactoring...
> Cheers!!!
>
> Victor Sánchez
>
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
| Re: item provider adapter 'getText' redefinitions [message #417370 is a reply to message #417369] |
Thu, 06 March 2008 17:11 |
Victor Sanchez
Messages: 28
Registered: July 2009 |
Junior Member |
|
|
Ed, replies inline below:
> Hey, it's the EMF newsgroup, not Ed's newsgroup!
Hehe! Yeah, I was aware of that, but this message was specifically
directed at you as a remainder of a previous conversation. I'm sorry about
that. Of course I didn't mean to be rude to the community, and in fact,
I'd have been (and would be) delightful to hear from anybody else than
you, of course, about this subject.
> I'm not sure this would simplify things so much, but I can see how it
> would help with refactoring. A good model-based refactoring system
> could look at patterns within strings... The old/existing strings in
> the properties file wouldn't be renamed, so refactoring would need to
> consider that as well. I'd rather pursue this kind of thing when folks
> start to work on refactoring support. I'm hoping there will be a Google
> SOC project related to refactoring...
Sounds interesting. Thanks for the information, Ed!
Best regards:
Victor Sanchez
|
|
|
Goto Forum:
Current Time: Fri Apr 19 15:18:25 GMT 2024
Powered by FUDForum. Page generated in 0.02957 seconds |
] 
Search
Help
Register
Login
Home
