Eclipse Community Forums: Rich Client Platform (RCP) » Sharing application context between views (and eventually plug-ins)

Home » Eclipse Projects » Rich Client Platform (RCP) » Sharing application context between views (and eventually plug-ins)

Show: Today's Messages :: Show Polls :: Message Navigator

Sharing application context between views (and eventually plug-ins) [message #447979]

Tue, 18 April 2006 16:02

Mark Levison

Messages: 12
Registered: July 2009

Junior Member

In the past Ive developed .NET we had an application context: a class
that supported opening a model, events related to that model and was the
container for a few other key classes. We passed this application context
to the views that needed that needed it through their constructors. One of
the key values we achieved was to limit access to the contents of
application context to the few classes that really needed it thus we
avoided turning it into a god class. Im now struggling as to how I
achieve the same thing as we build an eclipse RCP application.

The approaches Ive conceived of so far:
1) Make application context a singleton. This is obviously a very bad
since any class could get direct access to it. It will quickly become a
god class.
2) Hang the instance of the application context off the Plugin class for
the core application. Similar to 1.
3) Hang the instance of the application context off the Activator (as per
Paul Webster: http://www.eclipsezone.com/eclipse/forums/m92011547.html)
Same problem as 1 & 2.
4) Create a special ViewPart subclass with a public
setApplicationContext() and protected getApplicationContext(). Once the
application context is created I go and find the relevant viewParts (Im
not sure who) and call setApplicationContext(). Of all the solutions Ive
found so far this seems like the only workable one yet its prone to all
sorts of ridiculous problems. How do I enumerate the list of all views? If
I do it manually no one will remember to call the setter when a new one is
added etc.

There has to be a better solution. Is there anyway to have our own
constructors for viewParts and pass in the context?

A confused former .NET developer
Mark Levison

Report message to a moderator

Re: Sharing application context between views (and eventually plug-ins) [message #447982 is a reply to message #447979]

Tue, 18 April 2006 16:31

Paul Webster

Messages: 6859
Registered: July 2009
Location: Ottawa

Senior Member

Hi.

<philosophy>I wouldn't worry about it so much. Within your plugin, your
"application context" will be as much or as little of a god class as you
give it functionality to be. Outside of it's own functionality, you are
writing your plugin so don't ask for the application context if you
don't need it. Outside of your plugin you can place access restrictions
so that other plugins can't see the class.</philosophy>

The short answer is that your views will only ever have the no-argument
constructor.

But there are ways to specify a String property to your view creation
extension, that will end up in your view part in the call to
setInitializationData(*). Check out IExecutableExtension for a
description of how it is used.

example: Your view is instantiated. Your view get's its
setInitializationData(*) method called (you must extend it). The String
is the name of your application context factory class.

Your view now goes to the factory to request an application context.

The setInitializationData(*) is the step needed to defer any
"view-needed" constructor data. You can never actually get at the
constructor, because you'll be no where near the view when it's actually
constructed due to the support for lazy plugin activation and deferred
view activation.

Later,
PW

Paul Webster
http://wiki.eclipse.org/Platform_Command_Framework
http://wiki.eclipse.org/Command_Core_Expressions
http://wiki.eclipse.org/Menu_Contributions

Report message to a moderator

Previous Topic:	RCP standard preferences
Next Topic:	"Help content" error

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Wed Dec 04 03:22:11 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter