Thank you Philipp for your agreement that we should go for
Pragmas/method annotations/method properties.

You have now started the discussion how the contract for menus should
look like. I think as well that we should do this now.


--Hannes

On 4/28/10, Philipp Tessenow <phite at nada1.de> wrote:
> Am 28.04.2010 12:26, schrieb Hannes Hirzel:
>> Thank you Andreas for the writeup you put at
>>
>> 'Annotations for Service Discovery'
>> http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-discovery/
>> [...]
>>
>> --Hannes
> +1
>
> Thank you all (on- and off-list) for the pragma discussion. Now I see
> that pragmas can be looked at from different angles. I believe what we
> want for menus is a pragma which is like a declarative contract (see
> Tobias' post).
>
> What about organizing official system extension points via services?
> A (DockingBar-)MenuBuilder is a service, a PreferenceManager is a
> service, ..and so on.
>
> Given I have build an applications that wants to use a menu service it
> could implement something along this:
>
> toggleColor
> 	"Toggles the background color of my singleton instance."
> 	<action>
> 	<actionScope: #UI>
> 	<actionCategory: #extra subCategory: #colors>
> 	<actionOccurence: #persistent>
> 	<actionName: 'Toggle Color'>
> 	<actionIcon: #toggleColorIcon>
>
> 	(Instance color = Color blue)
> 		ifTrue: [ Instance color: Color red ]
> 		ifFalse: [ Instance color: Color blue ].
>
> Please read the method like this:
>  This message wants to contribute an action which should be accessible
> through the UI - therefore we have the annotation <action> (which is
> kind of a general tag) and <actionScope: #UI> which says we want this
> action be present in the UI.
> (The other annotations are optional in this case!)
>
> Pleasee note that the message basically implements its own business
> stuff, but annotates some ui-things as a different plane.
>
> The DockingBar, for example, is a way to represent UI-actions which
> applications offer the user.
> So a service, namely the docking bar, looks through all
> service-annotations with scope: #UI. ("Ah, I (the docking bar) may offer
> a menu for this message of this class").
> As it is specified that this is a persistent activity (meaning: this
> UIAction doesn't change too often) through <serviceOccurence:
> #persistent> the docking bar decides to build a menu for this action.
> (The world menu may decide different as it is better in displaying
> #changing actions.)
>
> What do you think about this approach?
>
> - philipp
>
>