RE: [gmf-dev] GMF runtime complexity makes it hard for clients to benefi

[Mindaugas Idzelis <idzelis@xxxxxxxxxx>]

I also had to go through a long ramp-up
period to understand all of GMF. The best way to learn, IMHO is through
trial and error, persistence, and heavy use of the debugger :-) Of course,
that's the way I've learned most of swt, gef, platform, jdt, etc.  I
don't think this ramp-up period is unique to GMF, but to all large software
bases.

One thing that I think will be extremely
valuable is to have some kind of "activation explaination" built
into the Service infrastructure. It would be great if there were debug
switches available that for a given service will trace every provider that
is consulted and why or not it was chosen. There are many layers that services
use... execution strategies, enablement, policies, and it is pretty daunting
at first to debug. Luckily, I've figured out strategic places to put breakpoints
;-) Nevertheless, some debug support for Service activation would go a
long way in understanding the various types of extensibility. 


Thanks,

Mindaugas Idzelis
IBM Rational Middleware

Steven Shaw <steveshaw@xxxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

11/08/2005 09:56 AM

Please respond to
"GMF Project developer discussions."

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	RE: [gmf-dev] GMF runtime complexity makes it hard for clients        to        benefit from its power

Note:  In case people weren't aware,
there are a number of tutorials currently available in the SDK and a "How-to"
document that are fairly comprehensive.  
 
See org.eclipse.gmf.runtime.doc.isv / html
/ howto
           
                     
                     
             / tutorials
 
Regards,
 
Steve.
 
Tuesday, November 08, 2005 9:45 AM
To: "GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc: 
From: Doug Schaefer <DSchaefer@xxxxxxx>
Subject: RE: [gmf-dev] GMF runtime complexity makes it hard for clients
to   benefit from its power

Thanks Steve, I think a document
would be immensely helpful for people trying to get their feet wet. The
barrier to entry is pretty high and I keep bouncing off. J.
 
Cheers,
Doug

---

From: gmf-dev-bounces@xxxxxxxxxxx
[mailto:gmf-dev-bounces@xxxxxxxxxxx] On Behalf Of Steven Shaw
Sent: Tuesday, November 08, 2005 9:13 AM
To: GMF Project developer discussions.
Cc: GMF Project developer discussions.; gmf-dev-bounces@xxxxxxxxxxx
Subject: Re: [gmf-dev] GMF runtime complexity makes it hard for clients
to benefit from its power
 

Hello Henrik, 

Thanks for your feedback.  The complexity certainly can be overwhelming
due to the power of the infrastructure for extensibility and as a platform
across domains.  There is a programmers guide for the diagram plugins
under construction that hasn't been published yet in the SDK.  This
would include some basic interaction diagrams describing how the creation
process invokes the different services (View, EditPart, EditPolicy etc.).
 This should be available in M4.

There is also some planned investigation on simplifying the service schema
to avoid some of the complex XML tags that are needed to define providers.
 These are currently necessary to avoid loading a plugin simply to
determine enablement or provides criteria for a provider.  With the
introduction of the OSGI bundles some of this complexity could be potentially
eliminated allowing the logic to be centralized in the java source.  (This
needs to be investigated further...)

Re: log --> There is advanced tracing option available that can be activated
that should let you see trace data logged by services.  In the Debug
dialog, if you navigate to the "Tracing" tab and turn on "Enable
tracing for the selected plug-ins".

Regards, 

Steve. 
________________________________________
Steven R. Shaw
Rational Modeling Platform Diagram Layer Lead
Rational Software | IBM Software Group
770 Palladium Drive, Kanata, ON, Canada, K2V 1C8
tel: 613.591.7979
steveshaw@xxxxxxxxxx

Henrik Rentz-Reichert <hrr@xxxxxxxxx>
Sent by: gmf-dev-bounces@xxxxxxxxxxx

11/08/2005 04:46 AM

Please respond to
"GMF Project developer discussions."

To	"GMF Project developer discussions." <gmf-dev@xxxxxxxxxxx>
cc
Subject	[gmf-dev] GMF runtime complexity makes it hard for clients to benefit from its power

 

Hi all,

currently I'm implementing a simple example using the GMF runtime.

I tried to follow the lines of the logic example (which is fairly complex
though). Obviously the framework is extremely powerful. But its complexity
also puts a high burden on its clients. My experience up to now is that
it is very difficult to trace problems back to their origin. This is partly
due to the complex interactions of the framework with the providers defined
by the client. Especially registering the clients via extension points
is very error prone and problems are hard to detect.

Some examples:

• it took me quite a long time to realize that the DiagramKind of the Wizard page has to be in sync with the corresponding entry in the ViewProvider
• I missed to derive an EditHelper from MSLEditHelper which led to an exception in a context that was extremely hard to analyze
• in general declarations in the plugin.xml interact via services and service providers with user written code. There are many places where strings here and there have to coincide literally which can lead to subtle errors which are typically very hard to detect for a GMF runtime novice

Now
my questions:

• Is there a document (sequence diagrams would be great) that illustrates the interaction of framework instances with user defined code?
• Is a log file written with registry information of the GMF runtime services? Or alternatively: can I get information of this kind using certain tracing switches? This kind of information could be extremely helpful

Kind regards,

Henrik

-- 
..................................................
  
Dr. Henrik Rentz-Reichert  mailto://hrr@xxxxxxxxx

Hafnerstr. 1               fon +49-7533-9342-43
D-78476 Allensbach         fax      
       -44
_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev_______________________________________________
gmf-dev mailing list
gmf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/gmf-dev