| object mapping during evaluation [message #483771] |
Wed, 02 September 2009 17:14  |
Eclipse User |
|
|
|
Hi all,
Thanks everybody for all the previous answers, they have been extremely
useful.
The problem I have now is really tricky and I do not know how to solve it.
The deal is this:
1) I have an Ecore object that is not exactly the one I have to perform
the evaluation on. (e.g. some attributes are string instead of dates and
so on, or I have a list of class instances with an attribute a, and it has
to be accessed by OCL as a list of only the "a"). This is clearly a
mapping to be done.
2) Is there a way to hijack the way the OCL parser/evaluator accesses the
properties/types in order to translate these things on the fly?
Any idea is really appreciated...
Elio
ps. I have to deal with legacy code and I do not have full control over
it, I know this whole problem should never arise in a clean design... :(
|
|
|
| Re: object mapping during evaluation [message #483799 is a reply to message #483771] |
Thu, 03 September 2009 01:51  |
| Eclipse User |
|
|
|
Hi Elio
I think you want to step back a bit from your problem and think about
it; what you're asking doesn't make sense.
OCL works to the Ecore meta-model. If the Ecore meta-model is wrong OCL
will behave consistently with that meta-model.
So you probably have two different Ecore meta-models; what you actually
have and what you want. This is a model transformation. Shoe horning it
into OCL is a very difficult way of solving it. Any of the M2M tools
should be able to do it for you. Since the maping is so small you might
consider AM3 which I think, (I've never used it), is specifically
intended for mappings.
You might hand code the transformation as a Java tree iteration.
You might perform the transformation during Ecore loading via custom
StringToDate EDataType reading methods for the true Ecore model.
You might define the true Ecore as an elaboration of the actual Ecore
with the true e.g. Date properities marked as derived requiring you to
provide the conversion routines.
Regards
Ed Willink
Elio Damaggio wrote:
> Hi all,
>
> Thanks everybody for all the previous answers, they have been extremely
> useful.
> The problem I have now is really tricky and I do not know how to solve it.
>
> The deal is this:
> 1) I have an Ecore object that is not exactly the one I have to perform
> the evaluation on. (e.g. some attributes are string instead of dates and
> so on, or I have a list of class instances with an attribute a, and it
> has to be accessed by OCL as a list of only the "a"). This is clearly a
> mapping to be done.
> 2) Is there a way to hijack the way the OCL parser/evaluator accesses
> the properties/types in order to translate these things on the fly?
>
> Any idea is really appreciated...
>
> Elio
>
> ps. I have to deal with legacy code and I do not have full control over
> it, I know this whole problem should never arise in a clean design... :(
>
|
|
|
Powered by
FUDForum. Page generated in 0.03301 seconds
Home