Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Rich Client Platform (RCP) » Sharing application context between views (and eventually plug-ins)
Sharing application context between views (and eventually plug-ins) [message #447979] Tue, 18 April 2006 16:02 Go to next message
Mark Levison is currently offline Mark LevisonFriend
Messages: 12
Registered: July 2009
Junior Member
In the past I’ve 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. I’m now struggling as to how I
achieve the same thing as we build an eclipse RCP application.

The approaches I’ve 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 (I’m
not sure who) and call setApplicationContext(). Of all the solutions I’ve
found so far this seems like the only workable one yet it’s 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 viewPart’s and pass in the context?

A confused former .NET developer
Mark Levison
Re: Sharing application context between views (and eventually plug-ins) [message #447982 is a reply to message #447979] Tue, 18 April 2006 16:31 Go to previous message
Paul Webster is currently offline Paul WebsterFriend
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


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


Current Time: Sat Dec 14 20:52:46 GMT 2024

Powered by FUDForum. Page generated in 0.03535 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top