[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [e4-dev] More Model Question and Proposals
|
And because I've forgot about one more thing.
I think the current URI-Attributes might lead to confusion. If you look
at InputPart it has:
* uri (from MContribution#uri)
* iconUri (from MUILabel#iconUri)
* inputUri (from MInput#inputUri)
My suggestion yesterday on IRC was to rename MContribution#uri to
MContribution#contributionUri which is (as others noted) an over
definition if you look at MContribution itself but make them much more
explicit if you look at Part, InputPart, ... .
I guess the only place where people might notice this over definition is
when they get an MContribution injected.
Tom
Am 10.03.10 22:57, schrieb Tom Schindl:
> Hi,
>
> While working on my Model Editor I'm going through the model and there
> are question poping up. I'll try to summerize the current question and
> doubts I have:
>
> * Model-Contributions:
> ----------------------
> Currently I found two problems where the current model is probably
> having problems with because it expects the EMF-Object-Instance
> available at design time.
>
> The 2 areas are:
> * Contributed Handlers who want to use commands
> * Contributed Perspectives you want to use existing PartStacks, Parts,
> ...
>
> but probably there are more. I guess we need to find a common way to
> deal with this.
>
> * WindowTrim as a PSCElement:
> -----------------------------
> WindowTrim is an PSCElement so that it can get part of the
> Window#children-List but this also makes it useable at places the model
> should protect it's usage. I think Window should have an
> windowTrims-Attribute to store the trim instead of holding them inside
> the children-List.
>
> Another probably interesting question is whether one could have multiple
> WindowTrim(s) with the same SideValue else one could store them in 4
> trim-Attributes (left,right,top,bottom) but this is less important than
> getting the trim out of the children-List.
>
> * BindingContainer:
> -------------------
> I think the nameing things like HandlerContainer/Handler is better than
> the BindingContainer/KeyBinding and suggest to do a minor renaming to
> KeyBindingContainer.
>
> * KeySequence:
> --------------
> Why is KeySequence an EClass on itsown when only KeyBinding uses it as
> its superclass. Is there a reason for this, do we expect other Types to
> inherit from there, else we should probably merge the attribute from
> there into KeyBinding and remove the KeySequence-Type.
>
> Tom
>
--
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