[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-mtj-dev] MTJ Model
|
Hi,
As regarding to the EMF model editing, there is a related
document, which is a bit outdated but still showing the
idea:
You can also edit directly the EMF ecore model by
downloading the EMF SDK into your Eclipse and then editing it with the EMF
editor.
As you
see, the datamodel (aka MTJ objects) is presented though the
EMF.
The
object model definition is visible there and with help with the EMF code
generation, you can create the data model java
classes directly.
Then
you can use the EMF persisting services or use the data integrity services
(aka enable to propagate the changes to
relevant listeners).
If you
do not like to use the EMF, then the work is to remove it and code
the similar object services again.
-Arto
Craig,
I think that you are right that there is
the persistence model, and then the java objects that we convert them into to
use within the code. However, this division is fuzzy in some places of
the code, and the java representation is not shared across some of our service
components. So, we represent the device during SDK definition using one
java object representation, and then retrieve it for compilation/library use
using a different object representation to match the IDE requirements.
One of the things that we did during
creation was to not provide utility access to the EMF calls to store and
retrieve data across different implementations within the same service.
This meant that we duplicated the java object model representations as
we wrote code, while never formalizing them as a model representation.
There was an initial decision to do it this way so that the user was
exposed to the model. I think, in retrospect, that this was wrong, and
introduced to much complexity to the platform extender. In writing the
generic SDK provider, I hid all of the EMF calls in the implementation, and
wrote it to serve as a reference that could be extended without needing to
understand the calls in the future. If we stay with the EMF model, we
need to work to bury the EMF calls in a similar manner, and use the java
object representation within the code. Over time, that would allow us to
change the persistence model if desired.
kevin
--
Kevin
Horowitz
khorowit@xxxxxxxxxx
Expeditor Tools Development
Workplace
Portal and Collaboration Software
IBM - Boca Raton,
+1-561-862-2113
From:
| <Arto.Laurila@xxxxxxxxx>
|
To:
| <dsdp-mtj-dev@xxxxxxxxxxx>
|
Date:
| 11/15/2007 02:12 AM
|
Subject:
| RE: [dsdp-mtj-dev] MTJ
Model |
Craig,
I would disagree that there are two
models, as the EMF based model
publishes the objects that the UI is using.
"EMF itself is not a object model, merely it's provides add-on
services to the object model".
If you go and take a look to the UML
model, it describes the MTJ
Object structure and then the EMF publishes it
into a Object model.
When taking any those objects in detail analysis, you
see that the
object is a typical java object, which has a EMF
wrapper.
When tinking that what the EMF provides, it is the persistence
and
integrity services. So, if you take the EMF out, you would have to
code those by your self.
There is a manually written API layer on
top of the Object model,
that is used to access the Objects.
So,
when analyzing the MTJ Object structure and API, the base model
can be
seen from the UML model and the API is visible through the
extension point
API.
-Arto
>-----Original Message-----
>From:
dsdp-mtj-dev-bounces@xxxxxxxxxxx
>[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Craig Setera
>Sent: 15 November, 2007
04:24
>To: Mobile Tools for The Java Platform mailing
list
>Subject: Re: [dsdp-mtj-dev] MTJ Model
>
>My two cents
on the whole issue of the underlying model...
>
>There are really
two models with some amount of overlap between them.
>There is
the object model (Java) and the data model (EMF based
>in this case).
My understanding of the current MTJ
>implementation is that the
>overlap between those two models is a very large percentage.
>Is this a
>true statement?
>
>Another alternative
is to use the data model for a more
>limited subset of
functionality, primarily focusing on an
>Java based object model with
the ability to use an EMF data
>model for persistence when the Java
object chooses. To make
>this more clear, doing things this way
makes the model a
>potential for storage rather than a requirement for
extension.
>
>In my mind, I'd like to see the MTJ extension point
>implementations defined purely by Java interfaces and PDE
>extension point definitions.
>It should not be a
requirement for an extension to implement
>or extend the model in order
to function in this environment.
>It should, however, be possible
for the extension
>implementation to take advantage of an EMF model for
>persistence if they choose to do so. This seems to me to be
>the best of both
worlds.
>
>Thanks,
>Craig
>
>Arto.Laurila@xxxxxxxxx
wrote:
>> Hi,
>>
>> The current MTJ services
are using an EMF based model, that is
>> initially created with any
EMF compatible tool.
>> The tools that Kevin is referring here and
what e.g. I have used is
>> the a bit older Rational Rose tool to
create the UML model.
>> I think that even some very old version of
Rose can be used
>with this.
>>
>> Thus the
same model can be done with other tools, like IBM Rational
>>
Architect or Modeler or what ever (or even directly with the EMF).
>>
>> When thinking the current MTJ architecture, there is
>certainly needed
>> to discuss that does team members have
experience on EMF or not.
>> In case of that would be replaced, it
pretty much means that
>the whole
>> MTJ internal
architecture have to be recoded also.
>>
>> As
comparing to other Eclipse based projects, some of those are not
>>
using EMF at all and they do model their data model e.g.
>with plain
java.
>> As it is e.g. with EclipseME (Craig, correct me if I'm
wrong).
>>
>> Why the EMF has been used here, well
that enables to have a Eclipse
>> compatible and working data layer,
where the initial design is done
>> with UML and the the MTJ related
EMF layer is generated from the UML
>> file. That saves a lot of
coding & testing time.
>>
>> In my part I have to
say that if the EMF layer is dropped, I
>may have
>> problems
to participate to create the same functionality again from
>> Nokia
point of view.
>>
>>
-Arto
>>
>_______________________________________________
>dsdp-mtj-dev
mailing list
>dsdp-mtj-dev@xxxxxxxxxxx
>https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
>
_______________________________________________
dsdp-mtj-dev
mailing list
dsdp-mtj-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev