Loading Seaside into Pharo 1.2 core

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Loading Seaside into Pharo 1.2 core

Michael Roberts-2
Hi, i want to load Seaside into Pharo 1.2 core.  I have followed
various threads talking about doing this with metacello, but beyond
the simple tutorial i have worked through I am lost. I don't want to
have to specify each package by hand.

I can do this...

Gofer new
        squeaksource: 'MetacelloRepository';
        package: 'ConfigurationOfSeaside30';
        load.
       
(ConfigurationOfSeaside30 project version: '3.0.3')
        load: { 'Grease Core'. 'Grease Core Tests'. 'Swazoo2'}
       
I can do this...

(ConfigurationOfSeaside30 project version: '3.0.3')
        load: { 'Javascript-Core'}

but how do I load all the stuff declared as #common, or some of the
other parts, in the spec? I don't want to do this in a Pharo image.

If I do something like load: { #common }  or load: { #pharo } then
this was clearly a stupid request and I get 100s of errors pop up from
some decompiler issue and my image dies.  If someone can help or just
point me at the part of the docs I should be reading that would be
great.

thanks,
Mike

Reply | Threaded
Open this post in threaded view
|

Re: Loading Seaside into Pharo 1.2 core

Dale Henrichs
Hello Mike,

I am presently working on Seaside 3.0.4 which will correctly load into
Pharo1.2, but you should be aware that there a number of test failures
will remain and that (speaking unofficialy), Seaside3.0 isn't yet
supported on Pharo1.2...

To answer your general question you don't have to specify individual
packages by hand. The following load expression will load the 'default'
group for a project:

   (ConfigurationOfSeaside30 project version: '3.0.3') load.

By _default_ the 'default' group is the all of the packages and project
references defined in a configuration. A developer may explicitly define
the packages/project refs that are included in the 'default' group. A
developer may also define groups that are specific to the project. A
common group name is 'Core'. The 'Core' group typically defines the
basic unit that the developers expect you to load.

To find out which groups are defined in a project, you can execute the
following expression:

   (ConfigurationOfSeaside30 project version: '3.0.3') groups
      collect: [:each | each name ]

You can name a group in a load expression along with package names. Here
are the list of groups for Seaside 3.0:

   - 'Base'
   - 'Base Tests'
   - 'Development'
   - 'Development Tests'
   - 'Core'
   - 'Tests'
   - 'OneClick'

You will note that there aren't a lot of options for partitioning a
Seaside3.0 load:

   - 'Base' is the absolute minimum set of packages that should be
     loaded to get expected Seaside3.0 functionality
   - 'Development' adds in the Seaside30 development tools. It should be
     noted that it is recommended that the Seaside30 development tools
     be loaded in a production image, because the tools are considered
     essential
   - 'Core' includes "optional" packages like javascript support,
     adaptors, etc.
   - 'OneClick' is the subset of 'Core' that is shipped in the one-click
     image

It is recommended that you load the 'Core' group, if you want to exclude
the tests and load the 'default' group (i.e., everything) if you want to
include the tests.

Here's the list of packages in the 'Core' group:

   - 'Comet-Core' 'Seaside-Examples' 'Scriptaculous-Core'
     'Seaside-Tools-Core' 'Seaside-Tools-OmniBrowser' 'Seaside-HTML5'
     'Seaside-Environment' 'Seaside-Core' 'Seaside-Adaptors-Swazoo'
     'Seaside-Widgets' 'Seaside-Flow' 'Seaside-InternetExplorer'
     'Javascript-Core' 'JQuery-UI' 'Seaside-Adaptors-Comanche'
     'Seaside-Development' 'Seaside-Component' 'Seaside-Canvas'
     'RSS-Examples' 'RSS-Core' 'Scriptaculous-Components' 'JQuery-Core'
     'Seaside-FileSystem' 'Seaside-Session' 'Seaside-Email'
     'Seaside-Tools-Web' 'Comet-Examples' 'Seaside-RenderLoop'
     'Seaside-Welcome' 'Prototype-Core' 'Seaside-Swazoo' 'Seaside-Slime'

You must choose at least one adaptor (from the 'Core; group), so in
theory the absolute minimum loadable unit for Seaside30 would be:

   (ConfigurationOfSeaside30 project version: '3.0.3')
     load: #('Base' 'Seaside-Adaptors-Comanche').

Note that there are no pre-defined components registered in this case,
so even if you manually start WAKom:

   WAKom startOn: 8080

the only page you can hit is the files page:

   http://localhost:8080/files

You could load the example packages:

  (ConfigurationOfSeaside30 project version: '3.0.3')
     load: #('Seaside-Examples').

to have a few more pages to hit:

   http://localhost:8080/examples/examplebrowser

but without the familiar development tools you might not have an
enjoyable experience. You can add in the development tools with the
following expression:

  (ConfigurationOfSeaside30 project version: '3.0.3')
     load: #('Development').

Only then will you see the familiar Dispatcher page when you hit:

   http://localhost:8080/

At this point in time, the only things that you won't have loaded
(because of package dependencies) are:

   - Comet
   - Swazoo
   - RSS support
   - javascript support
   - HTML5 support
   - EMail
   - Welcome page

To add the remaining pieces you'd now have to list the individual
packages ...

Does this help?

Dale


On 02/14/2011 12:42 PM, Michael Roberts wrote:

> Hi, i want to load Seaside into Pharo 1.2 core.  I have followed
> various threads talking about doing this with metacello, but beyond
> the simple tutorial i have worked through I am lost. I don't want to
> have to specify each package by hand.
>
> I can do this...
>
> Gofer new
> squeaksource: 'MetacelloRepository';
> package: 'ConfigurationOfSeaside30';
> load.
>
> (ConfigurationOfSeaside30 project version: '3.0.3')
> load: { 'Grease Core'. 'Grease Core Tests'. 'Swazoo2'}
>
> I can do this...
>
> (ConfigurationOfSeaside30 project version: '3.0.3')
> load: { 'Javascript-Core'}
>
> but how do I load all the stuff declared as #common, or some of the
> other parts, in the spec? I don't want to do this in a Pharo image.
>
> If I do something like load: { #common }  or load: { #pharo } then
> this was clearly a stupid request and I get 100s of errors pop up from
> some decompiler issue and my image dies.  If someone can help or just
> point me at the part of the docs I should be reading that would be
> great.
>
> thanks,
> Mike
>