View source for Talk:Papyrus/Oxygen Work Description/NewFeature/PapyrusAFViewpointSwitch

Hi,

Some points

# Extension Points
The unapply method is missing from the interface
This interface should probably also provide a mechanism for viewpoint version management:
Ex : A ModelKind is removed from v1 to v2

# Figure 11: a Refactor menu is already present in Papyrus
It would be for the best to either reuse it or use another name

# Figure 5: Is this the target meta-model? (I don't see much difference with the current one)
=> It may be interesting to have a way to share common css for an Architecture domain.

Benoit,

=ModelRules=
*ModelRules define constraints for the DiagramKind creation
** It should be able to use element type here

=Table (Vincent Lorenzo)=
*PapyrusTableKind and PapyrusSyncTableKind must be merged!
**In the first case, we use the configuration file (referenced as a string?!)
**In the second case, we use the implementationID (the type of the table)

I propose to merge these 2 concepts which are useless for the viewpoint. The table configuration must be referenced by its '''type''' or must reference the configuration file itself. 
*Choosing the type of the table will allow to be easily compliant with a potential next version of the table.
**Please, in this case replace the name implementationID by type to be compliant wiith diagram and table!
*Choosing the file itself could broke the model if the required model is not available!


FYI, viewpoints allows to configure the palette of the diagrams. In the table we don't have palette, but we have menus looking like new child menu. We need to be able to configure them. Currently, this configuration is done by java code provided by classes referenced by ID in the table configuration file. 

FYI, viewpoints allow to create and configure new diagrams. With the current table implementation, we are not able to provide new table kind using viewpoint, because the configuration of the table is not done by viewpoint but by a specific table configuration file. Viewpoint provides only useful creation menu for table, with creation restriction according to the selection.

=Root and owner (Vincent Lorenzo)=
*It is possible to find better name for root and owner? It is never clear for me! One is used to know where we are able to display a given editor and the second one is used as creation context for the new elements. Right ? So why not call them '''displayContext''' and '''creationContext''' or '''displayRoot''' and '''semanticRoot''' or ...?

*If I understand good the role of the owner is to be able to display a table or a diagram somewhere in the model. Maybe, it could be interesting to have a list for the field owner, in order to be able to display the same table/diagram, in several location in the model.