Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse 4 » Fragments of Fragments(Is it possible to extend a fragment rather than Application.e4xmi?)
Fragments of Fragments [message #1431960] Fri, 26 September 2014 11:53 Go to next message
Bruce Skingle is currently offline Bruce SkingleFriend
Messages: 5
Registered: July 2009
Junior Member
It seems to be the case that a Fragment.e4xmi can only extend the base Application.e4xmi and not another fragment. Is this correct and if so, is this a deliberate design decision?

Why do I think this?

I have an RCP application containing a bundle with an Application.e4xmi and 2 bundles each with a Fragment.e4xmi, the third bundle contains a Fragment containing a Part, the fragment feature name is "children" if I set the fragment Element ID to an ID defined in the Application model it appears, if I change this to an ID contained in the other Fragment it does not.

Why am I trying to do this?

I have a normal and a developer version of the product, the developer version includes the second fragment as an additional feature. I want the two editions to have different branding (icons, splash screen etc).

The app contains just a top level window and branding.
The first fragment contains the main app, including a perspective and several part stacks.
The second fragment extends the first fragment with the developer tools, it wants to add a view Part to one of the Part Stacks defined by the main app in the first fragment.

I could just copy the Application.e4xmi into both main apps and maintain it twice but this is obviously nasty.

Re: Fragments of Fragments [message #1432209 is a reply to message #1431960] Fri, 26 September 2014 20:09 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6580
Registered: July 2009
Senior Member
On 26.09.14 16:15, Bruce Skingle wrote:
> It seems to be the case that a Fragment.e4xmi can only extend the base
> Application.e4xmi and not another fragment. Is this correct and if so,
> is this a deliberate design decision?

This is *not* correct

>
> Why do I think this?
>
> I have an RCP application containing a bundle with an Application.e4xmi
> and 2 bundles each with a Fragment.e4xmi, the third bundle contains a
> Fragment containing a Part, the fragment feature name is "children" if I
> set the fragment Element ID to an ID defined in the Application model it
> appears, if I change this to an ID contained in the other Fragment it
> does not.

Order is important make sure that your 2nd bundle depends on the first
and that you run with a 4.4.1 target platform.

>
> Why am I trying to do this?
>
> I have a normal and a developer version of the product, the developer
> version includes the second fragment as an additional feature. I want
> the two editions to have different branding (icons, splash screen etc).
>
> The app contains just a top level window and branding.
> The first fragment contains the main app, including a perspective and
> several part stacks.
> The second fragment extends the first fragment with the developer tools,
> it wants to add a view Part to one of the Part Stacks defined by the
> main app in the first fragment.
>
> I could just copy the Application.e4xmi into both main apps and maintain
> it twice but this is obviously nasty.
>
>
Re: Fragments of Fragments [message #1432504 is a reply to message #1432209] Sat, 27 September 2014 07:43 Go to previous messageGo to next message
Bruce Skingle is currently offline Bruce SkingleFriend
Messages: 5
Registered: July 2009
Junior Member
I was unaware that 4.4.1 had been released, it's working now.

Thanks Tom.
Re: Fragments of Fragments [message #1432542 is a reply to message #1432504] Sat, 27 September 2014 09:11 Go to previous messageGo to next message
Bruce Skingle is currently offline Bruce SkingleFriend
Messages: 5
Registered: July 2009
Junior Member
I spoke too soon. It sort of works but I think I may be seeing a regression of https://bugs.eclipse.org/bugs/show_bug.cgi?id=389663

Is this something you know about Tom?

I have some persisted state in a view part, the state is written out to workspace.xmi but when the app restarts the state has vanished.

If I comment out the fragment in plugin.xml before the restart (which I assume prevents the re-merge of the fragment.e4xmi) then the persisted state is there as expected.

I have no idea if its the same bug but it looks like the behaviour described in that bug.
Re: Fragments of Fragments [message #1432884 is a reply to message #1432542] Sat, 27 September 2014 22:23 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6580
Registered: July 2009
Senior Member
Yeah remerging will always kill the state :-( but you should have new
options in the extension point to tell the guy to merge it only at the
first startup.

Tom

On 27.09.14 11:11, Bruce Skingle wrote:
> I spoke too soon. It sort of works but I think I may be seeing a
> regression of https://bugs.eclipse.org/bugs/show_bug.cgi?id=389663
>
> Is this something you know about Tom?
>
> I have some persisted state in a view part, the state is written out to
> workspace.xmi but when the app restarts the state has vanished.
>
> If I comment out the fragment in plugin.xml before the restart (which I
> assume prevents the re-merge of the fragment.e4xmi) then the persisted
> state is there as expected.
>
> I have no idea if its the same bug but it looks like the behaviour
> described in that bug.
Re: Fragments of Fragments [message #1434677 is a reply to message #1432884] Tue, 30 September 2014 12:38 Go to previous messageGo to next message
Bruce Skingle is currently offline Bruce SkingleFriend
Messages: 5
Registered: July 2009
Junior Member
Quote:
Yeah remerging will always kill the state Sad but you should have new
options in the extension point to tell the guy to merge it only at the
first startup.


So I added apply="initial" to my plugin.xml like this and it seems to work, is that what you meant?

<?xml version="1.0" encoding="UTF-8"?>
<plugin>
   <extension
         id="org.immutify.pan.fragment"
         point="org.eclipse.e4.workbench.model">
      <fragment
            apply="initial"
            uri="fragment.e4xmi">
      </fragment>
   </extension>
</plugin>


I'm still uncomfortable with the way this works, consider the following use case:

1. User downloads application v1, does lots of customisation, resizes columns, moves view parts within perspectives etc.

2. Developer adds a new feature including adding a new view part.

I think one of two things happens now, either:

A) A remerge doesn't happen because I have this option and there is no "clearPersistedState" parameter and the user never sees the new functionality

B) A remerge does happen (although it's unclear to me how I will make that happen for my product), the user gets the new view, but the whole UI has been "reset to factory defaults".

I plan to make frequent releases of my product and I think users will get fed up pretty quickly if everything gets reset often.

It seems to me that the persisted model needs to store the changes made by the user rather than the current merged composite. At the moment if a user closes a part it's just absent from the model, if there was a delta then you would have a record that the view had been closed, or the column had been resized etc.

Judging from things I've read it once did something like this and has been changed, am I right? How do we envision adding new capabilities to a product where the user has moved elements around?
Re: Fragments of Fragments [message #1434699 is a reply to message #1434677] Tue, 30 September 2014 13:03 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6580
Registered: July 2009
Senior Member
On 30.09.14 05:38, Bruce Skingle wrote:
> Quote:
>> Yeah remerging will always kill the state :( but you should have new
>> options in the extension point to tell the guy to merge it only at the
>> first startup.
>
>
> So I added apply="initial" to my plugin.xml like this and it seems to
> work, is that what you meant?
>
> <?xml version="1.0" encoding="UTF-8"?>
> <plugin>
> <extension
> id="org.immutify.pan.fragment"
> point="org.eclipse.e4.workbench.model">
> <fragment
> apply="initial"
> uri="fragment.e4xmi">
> </fragment>
> </extension>
> </plugin>
>
> I'm still uncomfortable with the way this works, consider the following
> use case:
>
> 1. User downloads application v1, does lots of customisation, resizes
> columns, moves view parts within perspectives etc.
>
> 2. Developer adds a new feature including adding a new view part.
>
> I think one of two things happens now, either:
>
> A) A remerge doesn't happen because I have this option and there is no
> "clearPersistedState" parameter and the user never sees the new
> functionality
>
> B) A remerge does happen (although it's unclear to me how I will make
> that happen for my product), the user gets the new view, but the whole
> UI has been "reset to factory defaults".
>
> I plan to make frequent releases of my product and I think users will
> get fed up pretty quickly if everything gets reset often.
>
> It seems to me that the persisted model needs to store the changes made
> by the user rather than the current merged composite. At the moment if a
> user closes a part it's just absent from the model, if there was a delta
> then you would have a record that the view had been closed, or the
> column had been resized etc.
>
> Judging from things I've read it once did something like this and has
> been changed, am I right? How do we envision adding new capabilities to
> a product where the user has moved elements around?

You are right the first e4 version used exactly this type of merging but
it didn't perform well and we could get all edge cases right :-(

Generally speaking the model loading is a service and you can replace it
with your own one if not satisfied with the default.

Another possibility would be that you use processors instead of
fragments because the you are under full control of the model creation
process.

As of now we don't have a general solution to the feature you want to
see, the only viable thing today is that you implement your custom
solution which means before you clear the persited state you extract the
informations you want to preserve.

How to restart with a clearing of persisted state is described at
http://tomsondev.bestsolution.at/2014/06/17/restarting-an-e4-application-with-the-intial-workbench-e4xmi/

Tom
Re: Fragments of Fragments [message #1434710 is a reply to message #1434699] Tue, 30 September 2014 13:21 Go to previous messageGo to next message
Bruce Skingle is currently offline Bruce SkingleFriend
Messages: 5
Registered: July 2009
Junior Member
It seems to me that we need a general solution to this problem because I think I am describing a mainstream part of the development lifecycle of any app which might use E4 as a platform, including the Eclipse IDE.

I'll try to give some thought to the problem, I can see how having to process a lot of deltas every start could become a performance problem. My workaround for this was to persist the "user preferences" separately and apply them after the model loads which is sort of what you suggested, but without having to understand all the E4 model code.

Is there an example (of a replacement model service) I can look at or do I just need to delve into the main code base?
Re: Fragments of Fragments [message #1434718 is a reply to message #1434710] Tue, 30 September 2014 13:34 Go to previous message
Thomas Schindl is currently offline Thomas SchindlFriend
Messages: 6580
Registered: July 2009
Senior Member
There is no sample but you simply add a <property> to your
..product-extension point where the key is "modelResourceHandler" and the
value "bundle-resource://...." which points to a class of type
IModelResourceHandler.

Tom

On 30.09.14 06:21, Bruce Skingle wrote:
> It seems to me that we need a general solution to this problem because I
> think I am describing a mainstream part of the development lifecycle of
> any app which might use E4 as a platform, including the Eclipse IDE.
>
> I'll try to give some thought to the problem, I can see how having to
> process a lot of deltas every start could become a performance problem.
> My workaround for this was to persist the "user preferences" separately
> and apply them after the model loads which is sort of what you
> suggested, but without having to understand all the E4 model code.
>
> Is there an example (of a replacement model service) I can look at or do
> I just need to delve into the main code base?
Previous Topic:PartDescriptor in Fragment
Next Topic:Mocking Eclipse Product
Goto Forum:
  


Current Time: Wed Jan 27 15:09:49 GMT 2021

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

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

Back to the top