Hi Olivier,
I think you have a lot of question, and some questions are due
to the general project background and project purpose. But email, it’s
not best solution. This is why I ask to sync with Jim to help you in the
project context. Afterwards, we can communicate more easily.
>* Data description : if we embed data description into
core metamodel, that forces us to embed databinding into core metamodel.
>I think that the risk is clearly to resrict in the future other data
structure that the ones covered at the moment.
Yes, we deal with both. They are necessary to provide a data
presentation solution. The purpose of PMF is not only UI control (static)
modeling. It deals with data presentation. The concept of UI is widely
extended. It is composed of :
1. UI
Structure
2. UI
Dynamic
3. Page
flows
4. Presentation
patterns
The Data model is very simple and extensible. It is very similar
than Ecore metamodel. I don’t think we restrict other data structure. The
data model is defined for the data binding purpose.
There are already some description on our Wiki page for the
general purpose of PMF.
>* UI component modeling : do we need in core metamodel mouse and keyboard
support for instance. Even if a huge percentage of the UI support this devices,
it will probably not be the case in the future. We are a lot to believe that
tactile smartphones will be the next generation of devices, focus and mousemove
does not have the same impact on a zoomable UI than in windows or Internet
Explorer.
Providing mouse and keyboard or not is not important. The
important is the customization. We should enable the PMF final developer can do
it.
>I do not propose to drop the existing work, just to split up the current
monolithic metamodel (EMF makes it possible), in order to be able to switch from
one data management design to another if needed (please have a look at EMML
effort in mashup)
Every
suggestion to improve the model, and other proposition are well come. But suggestions
and propositions can be taken if the context is filled. PMF deals with a complex
contexts, I think we should keep a good approach: from simple to complex. Now,
we should focus one simple. And then we add step by step, to become complex and
covers everything.
>On the same line, the current UIObject could inherit
from a abstract one (in two different metamodels).
Please
keep in mind, the genericity in design is no limit. We should consider it when
it is necessary. Not for fine.
I think you should detail your purpose since I cannot see the necessity
by now.
Best regards
Yves YNAG
From:
pmf-dev-bounces@xxxxxxxxxxx [mailto:pmf-dev-bounces@xxxxxxxxxxx] On Behalf
Of Olivier Moïses
Sent: Sunday, December 13, 2009 9:46 AM
To: PMF Development team
Subject: Re: [pmf-dev] Discussion about the 'core' metamodel
Hi all,
Yves, I am happy that you open this discussion to everybody. It is time. Like
you, I believe that this topic is strategical.
I don't think we have a communication problem. Chatting with you is always a
pleasure.
Every open source projects support questions and answers about minor details or
strategical parts.
If my questions were not accurate enough, please accept my excuses, I will pay
more attention to be clearer in the future.
However, since the CVS history shows that you authored 100% of the core
metamodel, I guess that you are the best one to give detailed
informations/answers.
In order to get more than one line of answer for the questions, I wanted to
fill a bug, but I am afraid that it will not give opportunity to everyone to
participate.
There is only 4 committers in PMF, at the moment, and I think that this
questions should be asked to more than them.
As I explained in previous post, my first concern is about the coverage of the
core metamodel.We don't need to close doors.
Regarding the question you did not understand (and once again sorry for that),
I asked it one more time with other words.
Please, as the author of the PMF core metamodel, give us more than one line of
explanation.
You made a great first work.
Here is my question :
The current PMF core metamodel mixes different level of details.
* Data description : if we embed data description into core metamodel, that
forces us to embed databinding into core metamodel.
I think that the risk is clearly to resrict in the future other data structure
that the ones covered at the moment.
* UI component modeling : do we need in core metamodel mouse and keyboard
support for instance. Even if a huge percentage of the UI support this devices,
it will probably not be the case in the future. We are a lot to believe that
tactile smartphones will be the next generation of devices, focus and mousemove
does not have the same impact on a zoomable UI than in windows or Internet
Explorer.
I do not propose to drop the existing work, just to split up the current
monolithic metamodel (EMF makes it possible), in order to be able to switch from
one data management design to another if needed (please have a look at EMML
effort in mashup)
On the same line, the current UIObject could inherit from a abstract one (in
two different metamodels).
Thanks a lot,
Olivier
2009/12/13 yves (yingmin) yang <yves.yang@xxxxxxxxxxx>
Jim,
Please help me to give a general
presentation of PMF to Olivier. I believe it is best solution to get him in the
context of project quickly.
Thanks
yves
Yves,
PMF is an open source project. That means that every design decision could be
discussed.
Since if is in incubation phase and since there is no big documentation, I ask
you to pay attention to the asked questions and to answer bigger explainations.
If we want to start to create a good documentation we need a better
understanding of the concepts.
What we need now is to exchange and compare our own ideas in order to do the
better for this open source project.
What I understood about PMF, and please tell me if I am wrong, is not a rewrite
of HTML/_javascript_ in EMF.
I did not see your point about my last question and I need more explanations :
Why do we need to deals data in UI model ?
Data are not part of UI model, the binding between data and UI is depending on
data. The common point of you is to separate Data from UI. Could you please
explain me clearly wha
2009/12/12
yves (yingmin) yang <yves.yang@xxxxxxxxxxx>
>As I explained, my main concern is about
the relations between databinding model, datamodel and UI model. Do we need to
embbed the two/three concepts in the same metamodel/model ?
What’s the problem?
>Especially at this level of abstraction ?
>For instance JFace and EMF databinding
are non intrusive, they defines binding outside of the UI model.
It is not PMF’s responsibility to
take care of the specific databinding model. It is the role of integration. We
need to just model the databinding in PMF.
yves
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev
Internal Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09
06:09:00
_______________________________________________
pmf-dev mailing list
pmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pmf-dev
Internal
Virus Database is out of date.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.58/2306 - Release Date: 08/16/09
06:09:00