Services for 3.9
Romain Robbes
romain.robbes at lu.unisi.ch
Tue Aug 23 22:05:22 UTC 2005
On Aug 23, 2005, at 11:32 PM, Daniel Vainsencher wrote:
> I think we should put a Services framework in 3.9 as quickly as
> possible, this is really important for improving the tools, and
> would make simpler many packaging problems. Are there candidates
> other than Robbes Romain's? have people reviewed them? is there a
> list of known issues?
>
Well I don't think there is any other framework available ...
>
> From a quick look at this one (Services-Base), I have the following
> comments/questions:
> 1. It has a CLI thing that seems like it should be split off
> (should be optional, while services should become common
> infrastructure we can assume is there). BTW, the CLI looks pretty
> neat (assuming keymapper is installed), but I dont understand what
> the nextKeyStrokes: stuff does.
>
the next iteration (coming in the next few days) has this out, and
something I find neater is on a "developer" services package
(along with refactorings, etc ...).
> 2. There's a couple of classes for subsets of the loaded code:
> SubSystemNaviggation, and PartialClass. Probably useful for
> specific services, not for the framework itself, so might be left
> out (or not)
>
This goes in the developer package as well, hence is now out of the
base.
> 3. There's a Requestor hierarchy. Having read most of the code and
> some of the comments, I haven't really understood their role in
> this. Are these queries specific to code? or is this something
> general to parametrize over how to handle requests that are usually
> sent to the user? if so, what is its relation to those used in
> various of the automatic installation tricks used for various
> packages? is there parallel functionality in ToolBuilder?
>
requestors are acting as a third-party between the model and the
services.
a service asks the requestor for some information it needs, and the
requestor asks the model itselfs.
This allows to have a BrowserRequestor, specialized to deal with
browsers, and then an OBRequestor inheriting from
it with only a few key overrides needed (such as getting the class
name, the selector name, etc).
Cheers,
Romain
>
> Daniel Vainsencher
>
>
More information about the Squeak-dev
mailing list
|