Skip to main content

[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


Back to the top