Services

​Hi everyone,

for a Project of mine I am currently looking into a way to define object-specific context menus which work across different tools.
Thus, I looked into the Services implementation and played around with it. It still seems mostly functional as I was able to re-implement
the button bar of my class browser with Services.

As I also would like to have configurable keyboard shortcuts I think about reviving Services and introducing them to the standard tools.
However, before diving in I wanted to ask you whether you still consider Services as the desired way of doing this.
Especially as they are not really used in the image so far and would require some clean up and fixing.

The major technical hurdles I discovered so far are the number of involved classes to write and the static nature of some of the attributes
of Services (e.g. the text of a menu item is currently static). Also, I personally find them conceptually confusing as they require the definition
of actions (e.g. the browse implementor action of the browser) outside of the tool they will be available in (BrowserProvider vs. Browser).
The class the actions are defined in is however tightly coupled to the actual tool and the actions are thus barely reusable. The only thing that
changes is that the composition of menus could now be done in the Services Browser.

Bests
Patrick

Hi Patrick

Services are surely an issue and thank you for bringing this topic up
again. I think it would be good to do some research in the mailing
list archives and summarize the conclusions reached so far. If I
remember well it was discussed during the development of Squeak 4.4.

What did you see as the benefit of implementing the button bar of the
class browser with services?

The screen shot shows implementors of

    fileReaderServicesForFile: fullName suffix: suffix

Seems to be well implemented [1]


Are you as well referring to AppRegistry [2] and subclasses?

A use case for services is discussed here [3]

What did you find out about the status of the keyboard shortcuts
(screen shot), browser opened by

    PreferenceBrowser openForServices


It would be interesting to have a look at the services framework from
the point of view of Data Context Interaction (DCI) [4]


Regards

-Hannes


[1] SimpleServiceEntry subclass: #FileModifyingSimpleServiceEntry
        category: 'System-FileRegistry'

I represent a service

provider : the service provider
label : to be display in a menu
selector : to do the service
useLineAfter
stateSelector : a secondary selector (to be able to query state of the
provider for example)
description : a description for balloon for example
argumentGetter : a selector to get additional arguments with (if
selector requres them)
buttonLabel : a short label




[2] AppRegistry is a simple little class, not much more than a wrapper
around a collection. It's intended to help break dependencies between
packages. For example, if you'd like to be able to send e-mail, you
could use the bare-bones MailComposition class, or you could use the
full-blown Celeste e-mail client. Instead of choosing one or the
other, you can call "MailSender default" (where MailSender is a
subclass of AppRegistry), and thus avoid creating a hard-coded
dependency on either of the two mail senders.

This will only really be useful, of course, for applications that have
a very simple, general, well-defined interface. Most of the time,
you're probably better off just marking your package as being
dependent on a specific other package, and avoiding the hassle of this
whole AppRegistry thing. But for simple things like e-mail senders or
web browsers, it might be useful.


[3] Where can I find a use case or concrete example of setting up a service?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108255.html

[4] http://wiki.squeak.org/squeak/6048    Data-Context-Interaction
"improve the readability of object-oriented code by giving system
behavior first-class status;"

On 3/15/17, Rein, Patrick <[hidden email]> wrote:

Hi Hannes,

thanks for also looking into this.

> What did you see as the benefit of implementing the button bar of the
> class browser with services?

So far I have not seen any benefit, except of being able to specify the order of buttons
in the button bar as well as the items in the context menus in the ServicesBrowser.
Ultimately, I would hope that the services would become more reusable so that every tool
displaying a list of methods could select from the method services to provide e.g. senders
and implementor.

My current goal is to also make keyboard shortcuts assignable. So far, I did not make it there yet. :)

> The screen shot shows implementors of
>
>   fileReaderServicesForFile: fullName suffix: suffix
>
> Seems to be well implemented [1]

As far as I can see it, the file reader services are different from the menu item services.
The fact that the file reader services do not inherit from any of the core Services classes (Provider and Requestor)
makes me believe that. I might be mistaken though, as I do not fully comprehend it yet. Unfortunately, they share
very similar names and the infrastructure also seems to work in a similar way.

I am also not sure whether it would make sense to unify these to mechanisms. I have to investigate that further.

> Are you as well referring to AppRegistry [2] and subclasses?

For the time being no.

> It would be interesting to have a look at the services framework from
the point of view of Data Context Interaction (DCI) [4]

Yes, it looks like this is actually a good example for DCI. Especially when menu actions become more complex
and require several objects. Probably a DCI implementation is not necessary but it might be a good model
to explain services (and extend it).

Bests
Patrick

________________________________________
From: Squeak-dev <[hidden email]> on behalf of H. Hirzel <[hidden email]>
Sent: Thursday, March 16, 2017 22:44
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] Services

Hi Patrick

Services are surely an issue and thank you for bringing this topic up
again. I think it would be good to do some research in the mailing
list archives and summarize the conclusions reached so far. If I
remember well it was discussed during the development of Squeak 4.4.

What did you see as the benefit of implementing the button bar of the
class browser with services?

The screen shot shows implementors of

    fileReaderServicesForFile: fullName suffix: suffix

Seems to be well implemented [1]


Are you as well referring to AppRegistry [2] and subclasses?

A use case for services is discussed here [3]

What did you find out about the status of the keyboard shortcuts
(screen shot), browser opened by

    PreferenceBrowser openForServices


It would be interesting to have a look at the services framework from
the point of view of Data Context Interaction (DCI) [4]


Regards

-Hannes


[1] SimpleServiceEntry subclass: #FileModifyingSimpleServiceEntry
        category: 'System-FileRegistry'

I represent a service

provider : the service provider
label : to be display in a menu
selector : to do the service
useLineAfter
stateSelector : a secondary selector (to be able to query state of the
provider for example)
description : a description for balloon for example
argumentGetter : a selector to get additional arguments with (if
selector requres them)
buttonLabel : a short label




[2] AppRegistry is a simple little class, not much more than a wrapper
around a collection. It's intended to help break dependencies between
packages. For example, if you'd like to be able to send e-mail, you
could use the bare-bones MailComposition class, or you could use the
full-blown Celeste e-mail client. Instead of choosing one or the
other, you can call "MailSender default" (where MailSender is a
subclass of AppRegistry), and thus avoid creating a hard-coded
dependency on either of the two mail senders.

This will only really be useful, of course, for applications that have
a very simple, general, well-defined interface. Most of the time,
you're probably better off just marking your package as being
dependent on a specific other package, and avoiding the hassle of this
whole AppRegistry thing. But for simple things like e-mail senders or
web browsers, it might be useful.


[3] Where can I find a use case or concrete example of setting up a service?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108255.html

[4] http://wiki.squeak.org/squeak/6048    Data-Context-Interaction
"improve the readability of object-oriented code by giving system
behavior first-class status;"

On 3/15/17, Rein, Patrick <[hidden email]> wrote:

And I forgot the attachment showing how the configuration of the button bar looks like.
________________________________________
From: Squeak-dev <[hidden email]> on behalf of Rein, Patrick
Sent: Thursday, March 23, 2017 16:40
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] Services

Hi Hannes,

thanks for also looking into this.

> What did you see as the benefit of implementing the button bar of the
> class browser with services?

So far I have not seen any benefit, except of being able to specify the order of buttons
in the button bar as well as the items in the context menus in the ServicesBrowser.
Ultimately, I would hope that the services would become more reusable so that every tool
displaying a list of methods could select from the method services to provide e.g. senders
and implementor.

My current goal is to also make keyboard shortcuts assignable. So far, I did not make it there yet. :)

> The screen shot shows implementors of
>
>   fileReaderServicesForFile: fullName suffix: suffix
>
> Seems to be well implemented [1]

As far as I can see it, the file reader services are different from the menu item services.
The fact that the file reader services do not inherit from any of the core Services classes (Provider and Requestor)
makes me believe that. I might be mistaken though, as I do not fully comprehend it yet. Unfortunately, they share
very similar names and the infrastructure also seems to work in a similar way.

I am also not sure whether it would make sense to unify these to mechanisms. I have to investigate that further.

> Are you as well referring to AppRegistry [2] and subclasses?

For the time being no.

> It would be interesting to have a look at the services framework from
the point of view of Data Context Interaction (DCI) [4]

Yes, it looks like this is actually a good example for DCI. Especially when menu actions become more complex
and require several objects. Probably a DCI implementation is not necessary but it might be a good model
to explain services (and extend it).

Bests
Patrick

________________________________________
From: Squeak-dev <[hidden email]> on behalf of H. Hirzel <[hidden email]>
Sent: Thursday, March 16, 2017 22:44
To: The general-purpose Squeak developers list
Subject: Re: [squeak-dev] Services

Hi Patrick

Services are surely an issue and thank you for bringing this topic up
again. I think it would be good to do some research in the mailing
list archives and summarize the conclusions reached so far. If I
remember well it was discussed during the development of Squeak 4.4.

What did you see as the benefit of implementing the button bar of the
class browser with services?

The screen shot shows implementors of

    fileReaderServicesForFile: fullName suffix: suffix

Seems to be well implemented [1]


Are you as well referring to AppRegistry [2] and subclasses?

A use case for services is discussed here [3]

What did you find out about the status of the keyboard shortcuts
(screen shot), browser opened by

    PreferenceBrowser openForServices


It would be interesting to have a look at the services framework from
the point of view of Data Context Interaction (DCI) [4]


Regards

-Hannes


[1] SimpleServiceEntry subclass: #FileModifyingSimpleServiceEntry
        category: 'System-FileRegistry'

I represent a service

provider : the service provider
label : to be display in a menu
selector : to do the service
useLineAfter
stateSelector : a secondary selector (to be able to query state of the
provider for example)
description : a description for balloon for example
argumentGetter : a selector to get additional arguments with (if
selector requres them)
buttonLabel : a short label




[2] AppRegistry is a simple little class, not much more than a wrapper
around a collection. It's intended to help break dependencies between
packages. For example, if you'd like to be able to send e-mail, you
could use the bare-bones MailComposition class, or you could use the
full-blown Celeste e-mail client. Instead of choosing one or the
other, you can call "MailSender default" (where MailSender is a
subclass of AppRegistry), and thus avoid creating a hard-coded
dependency on either of the two mail senders.

This will only really be useful, of course, for applications that have
a very simple, general, well-defined interface. Most of the time,
you're probably better off just marking your package as being
dependent on a specific other package, and avoiding the hassle of this
whole AppRegistry thing. But for simple things like e-mail senders or
web browsers, it might be useful.


[3] Where can I find a use case or concrete example of setting up a service?
http://lists.squeakfoundation.org/pipermail/squeak-dev/2006-September/108255.html

[4] http://wiki.squeak.org/squeak/6048    Data-Context-Interaction
"improve the readability of object-oriented code by giving system
behavior first-class status;"

On 3/15/17, Rein, Patrick <[hidden email]> wrote: