+1 I'd say the main difference between a 'descriptor' and a 'part' is that the descriptor is *not* a UIElement, it is never meant to be rendered. The function of a 'descriptor' is to provide input for some function (i.e. 'createPart'(PartDescriptor desc)) that will modify the actual UI model. Just as a PerspectiveDescriptor is just a weak reference to a perspectiveFactory (which, on invocation constructs the presentation model).
Eric From: Hallvard Trætteberg <[email protected]> To: E4 Project developer mailing list <[email protected]> Date: 03/05/2010 06:01 PM Subject: Re: [e4-dev] e4 Model Questions and comments Sent by: [email protected] Boris Bokowski wrote: > It's understandable how we ended up in the current state, but I agree > with Tom's comments that we don't have the right shape for this yet. > PartDescriptor should not be derived from Part. It needs many of the > same attributes and references, but not all. I agree. That two classes need the same attributes/references is not a reason for introducing inheritance. If you want reuse, you could move the attributes into a "mixin", i.e. a common superclass that's not the primary superclass. In this case, it may work to switch the super/sub-relationship: let PartDescriptor inherit from Part. It all depends on the expectations of users of the class. Hallvard > > Any takers for changing the model to the better? > > Boris > > Inactive hide details for Paul Webster ---03/05/2010 08:08:19 AM---Hi > Tom, On Thu, Mar 4, 2010 at 5:23 PM, Tom Schindl <tom.schPaul Webster > ---03/05/2010 08:08:19 AM---Hi Tom, On Thu, Mar 4, 2010 at 5:23 PM, Tom > Schindl <[email protected]> wrote: > > > From: > Paul Webster <[email protected]> > > To: > E4 Project developer mailing list <[email protected]> > > Date: > 03/05/2010 08:08 AM > > Subject: > Re: [e4-dev] e4 Model Questions and comments > > Sent by: > [email protected] > > ------------------------------------------------------------------------ > > > > Hi Tom, > > On Thu, Mar 4, 2010 at 5:23 PM, Tom Schindl > <[email protected]> wrote: > > If I get this right the descriptor is something one uses to contribute a > > Part-Description to through ModelComponent and Part the thing that > > should end up as part of our UI-Workbench-Model. > > PartDescriptors serve one purpose -> they are templates for creating > Parts. PartDescriptor->Part is the equivalent of > ViewDescriptor->ViewPart in the 3.x world. PartDescriptors are stored > in a part of the model that's not rendered. They need to contain > everything necessary to generate the Part so it can be rendered (which > is pretty well every field). > > Right now we take the shortcut of simply cloning the PartDescriptor > (which is a Part) so that it can be rendered, but that's simply our > current implementation, not a requirement. > > > > > This (IMHO) incorrect extending of Part is also the problem we are > > seeing in ModelComponent which has the following attributes: > > > > PartDescriptorContainer { > > descriptor: List<PartDescriptor> > > } > > > > ModelComponent extends PartDescriptorContainer { > > children: List<UIElement> > > } > > > > So because PartDescriptor is a Part I can also contribute it through the > > children-Attribute though this probably not I wanted to do. > > Probably not, as it will be rendered :-) > > ModelComponent also serves a purpose. It's supposed to be a loadable > fragment of the model, that we can then apply to the real model (kind > of an extension point for models). > > Really what we are trying to do with ModelComponent is to add to the > model instance by merging model fragments into it. If there's already > a well known EMF way to do this, it would be good to know :-) I > recently ran into a problem where the model has commands defined, but > I can't use the model fragment to add a menu item because it cannot > resolve the reference to its command ... since that's in the already > loaded model instance. > > Later, > PW > > -- > Paul Webster > Hi floor. Make me a sammich! - GIR > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > > ------------------------------------------------------------------------ > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev _______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
