Dear all,
I have the same issues as Camille regarding loading time and
adding required resource. I suspect, resources are loaded multiple
times, otherwise it would not take that long.
Compared to the neon version I like that error-prone IDs have now
be replaced by "real" model references. But I still have quite a
large list of shortcomings:
* Validation: the validation of an element-type file almost
always reports no errors, even if there are for instance undefined
references, duplicate IDs, etc.
* Better editors:
- References can be selected via a pull down menu. This doesn't
scale. There is no filter to search for a given element (you can
type blindly but you have to write the whole prefix, starting with
Metamodel or Specialization Type ...). Thus, it would be good to
see a filter line which allows to prefix with "*" and type the
name of the element-type to find.
- No completion/browsing/validation, e.g.if we enter an advice
class name or a stereotype name in a
matcher-condition/application-advice. It's simply a string and up
to the user to enter/check.
- As we don't see the full path of an element-type reference, we
cannot distinguish between two elements having the same name. This
is a minor issue, as you can avoid having identical names in most
cases, but I once made the mistake to use the same name for the
(non-child) DI element and the associated semantic element type.
* Redundancy:
- Icon paths within element type definitions are taken into
account for the new-child menu, but they have do be redone in the
Palette definition (and at other places)
- Duplication of matcher conditions and apply-stereotype advice.
While I understand that these are two different things, you'll
need both with identical data in most cases. A pragmatical
solution would be have a boolean flag in the stereotype-matcher
condition (defaulting to true) indicating "apply-during-create"
- Old problem of having separate element-type-DI definitions for
child-node and top-node. It would be great, if it is possible to
distinguish them only if needed, i.e. if they should actually be
presented differently. Well, this is rather an inheritance from GMF
instead of an issue in the architecture framework
* Runtime robustness:
A single bad element-type definition can break all diagrams and
produce a runtime NPE. It's hard to find which element type
definition caused the problem
* Generation from profile definition
An initial set of element types definitions can be generated from
a profile. While this is very useful, a re-generation e.g. after a
profile evolution would overwrite existing advice configurations.
I.e. it would be grate to have an incremental generator that
preserves these definitions.
Best regards
Ansgar
On 12/10/2017 13:43, TESSIER Patrick
wrote:
Hi all committers and
advanced users of papyrus,
For the oxygen version,
the architecture framework has been developed and used.
I would like to know
your feedbacks about this framework, to include , if
needed, improvements in the road map of photon.
You can write that it is
nice, why, we appreciate this kind of remarks.
You can also write
remarks about:
-
Needs
improvements about developer points of view:
o
Configuration
about .architecture
o
How
to define something that you have difficulties to do.
o
Maybe
problems of performance that you have detected.
-
Needs
improvements about user points of view:
o
Menus
o
Some
behaviors that you have not understand…
Responses need to be
clearly and precise in order to be managed.
Patrick Tessier
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
