[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [e4-dev] Working with modeled UI and HEAD
|
On Wed, Dec 1, 2010 at 8:38 AM, Tom Schindl
<tom.schindl@xxxxxxxxxxxxxxx> wrote:
Now if you put a commands dependency on bindings and a contexts
dependency on commands. The ModelAssembler guarantees that (see
ModelAssembler#topoSort):
This will get you part of the way there, but really this is using a "mostly parallel" structure to try and order the system. It's based on the assumption that your classpath dependencies will lead to the correct model. In the case where you have a plugin that defines the 20 things, and then separate implementation plugins, since inter-service dependencies are managed through the one plugin your order will once again be non-deterministic.
This also doesn't solve the many-times stated problem in RCP land of being able to control the order of things in eclipse because we hide implemented the order in a hidden algorithm.
Beside that if you use a ModelProcess you can rearrange the addons
whenever you want - as the current fragment system doesn't allow you to
contribute to any Application-Element you have to write a ModelProcessor.
This depends on the last guy in being able to re-arrange a set of add-ons so that they're correct, which is another algorithm needed to be written in someplace else (and in a plugin that's gauranteed to be run last).
I'm not 100% sold on my current method, but these will be problems with the assumption that each plugin can contribute it's information in the correct order.
PW
--
Paul Webster
Hi floor. Make me a sammich! - GIR
