Re: [e4-dev] Unique Id generation Proposal

[Lars Vogel <lars.vogel@xxxxxxxxxxxxxx>]

Thanks for this detailed discussion about how the modeled UI is
constructed and re-created. I'll try to extract the information of
this discussion and add it to my e4 tutorial.

Cheers, Lars

2010/3/12 Sven Efftinge <sven.efftinge@xxxxxxxxx>:
> Thanks Boris and Remy,
> now I see :-).
> I think then we can't get rid of the UUIDs in the final XMI, but it should
> be possible
> to generate it based on some other more readable description. We might be
> able to
> contribute something like that in the future.
> Cheers,
> Sven
>
>
> On Mar 12, 2010, at 3:00 PM, Boris Bokowski wrote:
>
> Remy, Sven,
>
> It's important to understand why we started putting IDs everywhere.
>
> Obviously, one reason is so that other can contribute model pieces relative
> to existing well-known elements in the model. For this, you'd like to have
> "well-known" human-readable IDs, and I think we do allow it. (Tangent: we've
> talked about using tags of which you can have more than one, instead of IDs,
> for the underlying matching problem to make things more flexible.)
>
> The second reason is that we have a merge problem, similar to merges in
> version control systems, or multi-user apps like Wave. Here is why:
> 1. The application defines in its application.e4xmi file a base model (for
> example, main menu, perhaps UI elements like views that are always there,
> etc). This file changes over time as new versions of the application are
> being developed and released.
> 2. Other plug-ins add to that model through our model extension point.
> Plug-ins can be installed and uninstalled. This means that we have a model
> that results from combining the base model with these contributions. Of
> course, this means that there is an additional source of change to the
> model, but it is pretty clear how these contributions get merged into the
> model.
> 3. Now it gets interesting: While the application is running, the model
> objects are being changed. For example, views that were there when the
> application first started got closed, or menus/toolbars were customized, new
> views were opened, etc. These changes need to be persisted across sessions,
> and ideally even across updating plug-ins or the base application.
>
> The hard problem is how you deal with 3. Obviously, if you just persist the
> resulting model at the end of each session, it will be very difficult to
> react to changes in 1 and 2. Therefore, our approach (as implemented by
> Remy) is as follows: On first startup, populate the model as described under
> 1 and 2. Changes during the session will be recorded as deltas, and we
> persist these deltas instead of the whole model when we shut down. Then, for
> subsequent startups, populate the model as described under 1 and 2 and then
> apply any persisted deltas from 3. If there are deltas that don't make any
> sense then skip them.
>
> To make this work, you need to be able to relate the deltas to their
> corresponding objects in the model. Note that they can be relative to *any*
> model object, not just "well-known" ones. This is where we need the IDs
> because relative references (especially those using list positions) are too
> fragile.
>
> Does this make sense?
>
> Boris
>
> Remy Suen wrote on 03/12/2010 07:59:29 AM:
>> <sven.efftinge@xxxxxxxxx> wrote:
>> > But is it really necessary to allow contributions to every node?
>> > Wouldn't it
>> > be ok if one could only add
>> > children or refer to nodes which have a name/id?
>>
>> Well, the model is completely "public" unlike how things are in 3.x,
>> so even if you don't contribute something through a model snippet,
>> you can still programmatically add a random part to some other
>> person's stack (for instance).
>>
>> These changes to the workbench "state" are performed every day by
>> Eclipse users when they go 'Window > Customize Perspective...' or
>> when they drag one view to another stack or drag one view to the
>> "side" to spawn a new stack.
>>
>> Perhaps I'm misunderstanding something here?
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
>



-- 
Lars
http://www.vogella.de - Tutorials about Java, Eclipse and Web programming
http://www.twitter.com/vogella - Lars on Twitter