|
| Re: Fragments of Fragments [message #1432209 is a reply to message #1431960] |
Fri, 26 September 2014 20:09   |
 Thomas Schindl
Messages: 6651
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 #1434677 is a reply to message #1432884] |
Tue, 30 September 2014 12:38 |
Bruce Skingle
Messages: 5
Registered: July 2009 |
Junior Member |
|
|
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?
|
|
|
| Re: Fragments of Fragments [message #1434699 is a reply to message #1434677] |
Tue, 30 September 2014 13:03 |
Thomas Schindl
Messages: 6651
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
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.07885 seconds
] 
Search
Help
Register
Login
Home
