Re: [e4-dev] Working with modeled UI and HEAD

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

I think we'd better discuss this on IRC but final statement on it but
I'd really like to make sure we are all talking about the same thing.

Problem to solve:
-----------------
Our Workbench Model has to have 2 addons when the workbench is
initialized so that the Addons are processed and start working.

<Application>
  <addon contributionURI="platform:/plugin/p1/CommandServiceAddon" />
  <addon contributionURI="platform:/plugin/p1/CommandProcessingAddon" />

  <!-- Future -->
  <addon contributionURI="platform:/plugin/p2/BindingServiceAddon" />
  <addon contributionURI="platform:/plugin/p2/BindingProcessingAddon" />
</Applicatio>

Current state:
--------------
We require users to add 2 addon-elements in their Application.e4xmi and
they have to be there in the exact order. If they don't things won't
work at all

Proposal:
---------
Contribute ModelProcessors who add the 2 Addon-Elements => because this
is pure Java you can ensure quite simply that CommandServiceAddon is
before BindingServiceAddon.

I'm not talking about the generic case here our very specific one with
the addons you mentioned in your first mail and here it is really simple
to ensure this ordering, not?

Tom

Am 01.12.10 15:02, schrieb Paul Webster:
> On Wed, Dec 1, 2010 at 8:38 AM, Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
> <mailto: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
> 
> 
> 
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev


-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                                        geschaeftsfuehrer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5/1    A-6020 innsbruck      phone    ++43 512 935834