[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[gef-dev] Re: Making GEF's EDiagram extensible
|
Hi Pratik
[Picking up the newsgroup thread.]
If you are not planning to do anything much with EDiagram, I am
happy to pick it up, since I need the extensibility for my
Eclipse/GMT/UMLX sub-project.
How would you like to arrange things?
What is your attitude to using Java generics?
How much refactoring can you tolerate?
So far I appear to be able to work without changes beyond ediagram, so
suggestions for generalising the underlying parts of GEF should be
very limited...
... except where Multi-tab editing is concerned. This needs ScrollingGraphViewer
to impose much less implementation.
Regards
Ed Willink
Pratik Shah wrote:
> "Ed Willink" <ed@xxxxxxxxxxxxx> wrote in message
> news:d5o5jf$j6u$1@xxxxxxxxxxxxxxxx...
>
>>I'm extending EDiagram to support editing of a graphical transformations
>>between MOF-like UML diagrams. I've found that EDiagram gives me a great
>>starting point, but that ultimately its structure leaves a bit to be
>>desired; instanceof ReferenceView tests are rather widespread.
>>
>>I have therefore been refactoring to localise the Ecore/MOF/UML business
>>policies, and after a side track trying to extend Request and
>
> CreationFactory
>
>>seem to have a more promising approach based on a new family of IRegime
>
> derived
>
>>singletons that provide the business policy and are referenced as required
>>by the EditPolicy, EditPart and CreationFactory. Additional business
>
> artefacts
>
>>may be defined by an extension point.
>>
>>This functionality could provide a neutral business independent EDiagram
>>on which the Ecore editor and my transformation editor could be layered.
>>
>>What are the plans for EDiagram?
>>
>>Is it to fade away awaiting a take-over by GMF?
>
>
> Good question. Taking over by GMF (and porting to their standards/API)
> would be the ideal scenario. We certainly hope it won't fade away. While
> we continue to make minor changes to that example, we do not have the
> resources required to continue work on that project. For now, it's gonna
> have to wait. Contributions from the community are always welcome too.
>
>
>>Would you like my refactoring to contribute to EDiagram's future?
>>(I'm successfully using Java generics to eliminate large numbers
>>of casts at matching depths in parallel inheritance trees.)
>>
>>Regards
>>
>>Ed Willink
>
>
>