Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [gef-dev] Graph Structure Proposal 
Hi,

I have checked now; the EMF generator does not seem to support generating only the implementations into a separate bundle... I could change it to generate _all_ code into a different bundle, but not just the implementation.

Cheers,
Zoltán
-- Zoltán Ujhelyi
https://www.inf.mit.bme.hu/en/members/ujhelyiz

Fault Tolerant Systems Research Group
Budapest University of Technology and Economics

On 2014.08.04., at 9:40, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:

> Hi all,
> 
> I have implemented the changes I had in mind with EMapPropertyHolder and MapPropertyHolder: https://github.com/nyssen/kgraph.git. In detail, 
> - I extended IPropertyHolder to provide a getSerializedProperties() method, which can replace the mechanism that was formerly provided by EMapPropertyHolder (makePersistent(), getPersistetProperties()). I added an implementation to MapPropertyHolder.
> - I removed EMapPropertyHolder and related constructs (PropertyMapping) and used IPropertyHolder within the Ecore Model directly (and used MapPropertyHolder within the generated implementation classes).
> 
> I also changed the data of KGraphElement from EObject to Object, so its not EMF-specific. 
> 
> What I would like to do in addition (but have not incorporated yet is):
> - If possible, split implementation and interfaces in two bundles (I have not figured out yet, if this is supported by EMF right out of the box).
> - Use GEF4 Geometry Point and Dimension instead of KPoint, etc. The Geometry classes support imprecise comparison and can directly be used within GEF4 (and converted into other representations), so I would prefer these to an additional representation (as GEF4 Geometry does not introduce any new dependencies, there is no drawback included). 
> I hope I can add this today.
> 
> I also still need to investigate whether it makes sense to "merge" the properties mechanism with the adapter mechanism. However, do not think that is an urgent matter. I could basically live with what came out of the refactoring now (Property and PropertyHolder), while I am still unaware about the need for the IProperty-interface in addition to the Property-class (What abstraction does it add? What use case is behind it?).
> 
> Cheers
> Alexander
> 
> 
> Am 03.08.2014 um 13:46 schrieb Alexander Nyßen <alexander.nyssen@xxxxxxxxx>:
> 
>> Hi Miro,
>> 
>> Am 03.08.2014 um 04:31 schrieb Miro Spönemann <msp@xxxxxxxxxxxxxxxxxxxxxx>:
>> 
>>> Hi,
>>> see below.
>>> 
>>> On 28.07.2014, at 19:21, Alexander Nyßen <alexander.nyssen@xxxxxxxxx> wrote:
>>>> 1) Shouldn't we now also split it into two bundles, i.e. have an org.eclipse.gef4.kgraph and org.eclipse.gef4.kgraph.impl?
>>> 
>>> If we have only one implementation, splitting the interfaces from the implementation is not necessary, as far as I understand.
>> 
>> Well, it would IMHO not make much sense to bundle the EMF-independent interfaces within a bundle that has EMF-dependencies.
>> 
>>> 
>>>> 2) Why do we haven a MapPropertyHolder as well as an EMapPropertyHolder and related EMapPropertyHolderImpl? Couldn't we simply remove the manually coded MapPropertyHolder and rename the EMapPropertyHolder to MapPropertyHolder, so that MapPropertyHolderImpl would be its proper replacement?
>>> 
>>> The EMapPropertyHolder is based on an EMap, while the MapPropertyHolder is based on a HashMap. The latter is useful for including the properties mechanism in other data structures without EMF.
>> 
>> Why not use the HashMap-based MapPropertyHolder in both situations? If the Graph-interfaces are intended to be EMF-unspecific, they should be based on HashMap rather than EMap anyway. And why not use the manually implemented MapPropertyHolder also within the EMF-based implementation? Having seems to be somehow strange to me. 
>> 
>>> 
>>>> Miro, Christoph-Daniel, what do you think about Zoltan's result? Would that generally serve to fulfill your requirements as well?
>>>> 
>>>> As announced, I have spent some time on extending the IAdaptable mechanism (we can now bind the adapters under roles; everything is now available within GEF4 Common) and will take another look at the properties mechanism now. Maybe there's a potential for some synergy. I will keep you updated.
>>> 
>>> After a quick look it seemed to me that Zoltan's result could work for us. So the biggest open question is how to handle the properties. We’ll await your proposal.
>> 
>> I will take a look into it next week.
>> 
>>> 
>>> Regards
>>>  Miro
>> 
>> Cheers
>> Alexander
>> 
>>> _______________________________________________
>>> gef-dev mailing list
>>> gef-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/gef-dev
>> 
>> --  
>> Dr. Alexander Nyßen
>> Dipl.-Inform.
>> Software-Engineer
>> 
>> Telefon: +49 (0) 231 / 98 60-210
>> Telefax: +49 (0) 231 / 98 60-211
>> Mobil: +49 (0) 151 /  17396743
>> 
>> http://www.itemis.de 
>> alexander.nyssen@xxxxxxxxx 
>> 
>> itemis AG
>> Am Brambusch 15-24
>> 44536 Lünen
>> 
>> Rechtlicher Hinweis:
>> 
>> Amtsgericht Dortmund, HRB 20621
>> 
>> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
>> 
>> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
>> 
>> _______________________________________________
>> gef-dev mailing list
>> gef-dev@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/gef-dev
> 
> --
> Dr. Alexander Nyßen
> Dipl.-Inform.
> Software-Engineer
> 
> Telefon: +49 (0) 231 / 98 60-210
> Telefax: +49 (0) 231 / 98 60-211
> Mobil: +49 (0) 151 /  17396743
> 
> http://www.itemis.de 
> alexander.nyssen@xxxxxxxxx 
> 
> itemis AG
> Am Brambusch 15-24
> 44536 Lünen
> 
> Rechtlicher Hinweis:
> 
> Amtsgericht Dortmund, HRB 20621
> 
> Vorstand: Jens Wagener (Vors.), Wolfgang Neuhaus, Dr. Georg Pietrek, Jens Trompeter, Sebastian Neus
> 
> Aufsichtsrat: Dr. Burkhard Igel (Vors.), Stephan Grollmann, Michael Neuhaus
> 
> 
> _______________________________________________
> gef-dev mailing list
> gef-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/gef-dev

Back to the top