[squeak-dev] Re: [Pharo-project] Sake Basic Documentation
Stéphane Ducasse
stephane.ducasse at inria.fr
Tue Nov 11 15:29:18 UTC 2008
>
I should really use Sake to understand it further.
Now what is clear to me is that I like the idea. We need something to
write build script.
Now for the classTasks, I'm a bit worried that we can do this kind of
actions
becuse it means that depending on the task used to create a given
distribution
we can have a side effect method removed, added, class added ....
> Class Tasks
> ===========
>
> In the following examples #Cup is used where the class Cup, is not
> guaranteed to exist.
>
> task dependsOn:{ (SakeTask class: #Cup) exists }
>
>
> "create a needed class"
> task dependsOn:{ (SakeTask class: Object) subclass: #Cup }
>
> "create a needed class"
> task dependsOn:{ (SakeTask class: Object)
> subclass: #Cup category:'Demo'}
>
> task dependsOn:{ (SakeTask class: #Cup)
> removeSelector: #tmp }
>
> task dependsOn:{ (SakeTask class: #Cup)
> removeSelectorsMatching: '*' }
> task dependsOn:{ (SakeTask class: #Cup)
> removeSelectorsMatching: '*' }
>
> task dependsOn:{ (SakeTask class: #Cup) ifExistsDo: [ :c | c rename:
> #Glass ] }
>
> MetaData
> ========
>
> Each Sake task contains a dictionary, SakeInfo that can be used simply
> to store any arbitrary metadata.
>
> task info someField: someValue.
>
> Sake-Packages uses metadata extensively, in this case the typical use
> pattern is begin with a subclass of SakeTask and to define the generic
> task on the class side and the metadata on the instance side.
>
> SakeTask subclass: MakeADrink.
>
> MakeADrink classSide >> #taskPourADrink: aDrink
>
> self define: [ :task |
> task perform: aDrink.
>
> task if: [ Bar containsBottle: task info name ].
>
> task action: [ Glass add: (task info name). ].
> ].
>
> Documentation Methods
> =====================
>
> Subclasses of SakeTask, utilise a specialised compiler, which allows
> raw
> text to be stored in instance side methods following six quotes.
> """"""
>
> aTaskClass at: selector category: cat putMethod: code doc: content
>
> aTaskClass docAt: selector.
>
> This is used by the Mantis package to pull raw data from mantis, so
> that
> subsequent tasks can process that data.
>
>
> SakeSignal and trace:
> =====================
>
> If a task needs to communicate with the outside context, it can
> sends a
> SakeSignal, a utility method is provided for this.
>
> task lookup: #aSelector.
>
> The outside context can return a value, by defining an exception
> handler
> for SakeSignal.
>
> The default implementation of #trace: is used in Sake-Tests for a task
> to signal to the outside testing context what it is doing. Tasks send
> #trace: and the SakeTaskTest runCaseWith: block, defines an exception
> handler to collect the signalled values so as to record the actions of
> the tasks. For the tests to pass all of the required actions must have
> been signalled.
>
>
> SakeStep and SakeStop
> =====================
>
> task step: 'Are you Sure'.
>
> Signals a notifier to request confirmation.
>
> task stop: 'It Broke'.
>
> Finishes processing.
>
> Task Extensions
> ===============
>
> In the same manner as magritte. A class side task definition may be
> extended by another package.
>
> #taskDoThis, may be extended by adding the extension method,
>
> #taskDoThisAndAlso: task.
> task addDependency: [ ... ].
> task addAction: [...].
>
> Answering Notifications
> =======================
>
> Tasks are wrapped in notification handlers, to use them:
>
> task answer: '*password*' with: 'secret'.
>
>
> ================================
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Sake.
>
> Below is a SakeTask as generated from the universes package
> definition.
> What follows is a "method", in the class PackagesSqueak310U.
>
> So here is a Sake Task Definition for Seaside.... (info is simply a
> dictionary for non-essential meta information)
>
> ----------
>
> PackagesSqueak310U -i- Seaside
>
> self name: 'Seaside'.
> info category: 'Web Development'.
> info description:
> 'A framework for building sophisticated web applications in Squeak.
> Develop for the web using reusable, embeddable components and unique
> call/return semantics for moving between pages.'.
> info maintainer: 'Lukas Renggli <renggli at gmail.com>'.
> info homepage: 'http://www.seaside.st/'.
> info squeakMapID: ''.
> info url: 'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'
> .
> info version: '2.8.522'.
> info provides: #().
>
> self dependsOn: #('KomHttpServer').
>
> self load: [
> Installer
> installUrl:'http://www.squeaksource.com/Seaside/Seaside2.8a1-lr.522.mcz'
> .
> ].
>
> self unloadDependsOn: { self taskUnloadDependants }.
> self unload: [
> Installer unload: 'Seaside'.
> ].
>
> -------------
>
> Notice that we have an unload block as well as a load block! This is a
> new and very experimental feature, we can now define unload scripts
> for
> each package, and Sake/Packages provides a way to capture and publish
> them for some or all image versions. Indeed this feature is barely
> tested, I mention it here simply to intoduce the concept.
>
> usage:
>
> PackagesSqueak310 new Seaside load. or, (PackagesSqueak310
> named:'Seaside') load.
> PackagesSqueak310 new Seaside unload. or, (PackagesSqueak310
> named:'Seaside') unload.
>
> Packages/Sake is also supported by Installer in a manner similar to
> universes support, e.g.
>
> Installer sake addPackage: 'PackagesA'; addPackage: 'PackageB';
> install.
>
> enjoy...
>
> best regards
>
> Keith
>
> p.s. to load
>
> Installer install: 'Packages'.
>
> ==========
>
> Addendum: Sake/Packages no longer uses blocks as standard, but the
> principle is the same.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
More information about the Squeak-dev
mailing list
|