ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for a bit of review

This version of Seaside30 covers the latest mcz files (as of 6/21/2010
14:32), has been ported to GLASS 1.0-beta.8, includes the dependency of
  Seaside-Development on Seaside-Environment (so that
WAWalkbackErrorHandler gets installed as #exceptionHandler), includes
the Base group definition and includes the Seaside-Welcome page.

I would like to release 3.0.0-alpha5.15 for the GLASS users relatively
soon, but I thought I'd get some feedback on what's included before
releasing it...

I'd like to get a bit of feedback on:
   - the definition of the 'Base' group
   - whether a 'Development' group should/could be defined
   - whether other groupings might be needed
   - on the inclusion of Seaside-Welcome.

Looking at a load of the 'Base' group these are the packages that are
loaded:

linear load :
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                load : ConfigurationOfGrease
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                linear load : 1.0-alpha9.3 [ConfigurationOfGrease]
                        load : Grease-Core-pmm.42
                        load : Grease-Pharo-Core-pmm.23
                load : Seaside-Core-pmm.648
                load : Seaside-Pharo-Core-pmm.9
                load : Seaside-Component-lr.82
                load : Seaside-Canvas-pmm.95
                load : Seaside-Session-jf.132
                load : Seaside-RenderLoop-lr.72
                load : Seaside-Tools-Core-lr.17
                load : Seaside-Widgets-obi.18
                load : Seaside-Environment-lr.69
                load : Seaside-Pharo-Canvas-lr.3
                load : Seaside-Pharo-Environment-lr.6

this matches the list that Julian (or was it me?) proposed, so I think
we are in good shape:)

I have not added a 'Development' group, because I'm not sure what would
need to be included beyond Seaside-Development (and it's dependents). If
there another couple of packages that you would consider development
packages (like including Slime?) then a 'Development' group would be
called for.

As for other groups I can imagine a 'Flow' group would be useful if a
package beyond Seaside-Flow (and it's dependents) would be required...

Finally, when you load the Seaside-Welcome page using this expression:

   (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
     load: #('Base' 'Seaside-Adaptors-Comanche' 'Seaside-Welcome' ).

quite a bit gets loaded, because of the inclusion of the Task example
(WAFlowConvenienceFunctionalTest in Seaside-Tests-Flow)... here's the
list of mcz files:

linear load :
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                load : ConfigurationOfKomHttpServer
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                load : ConfigurationOfGrease
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                load : ConfigurationOfGrease
        linear load : 3.0.0-alpha5.15 [ConfigurationOfSeaside30]
                linear load : 1.0-alpha9.3 [ConfigurationOfGrease]
                        load : Grease-Core-pmm.42
                        load : Grease-Pharo-Core-pmm.23
                linear load : 1.0-alpha9.3 [ConfigurationOfGrease]
                        load : Grease-Tests-Core-DaleHenrichs.58
                        load : Grease-Tests-Pharo-Core-jok.7
                load : Seaside-Core-pmm.648
                load : Seaside-Pharo-Core-pmm.9
                load : Seaside-Component-lr.82
                load : Seaside-Canvas-pmm.95
                load : Javascript-Core-DaleHenrichs.87
                load : Javascript-Pharo-Core-DaleHenrichs.9
                load : JQuery-Core-lr.106
                load : JQuery-UI-obi.58
                load : Seaside-Session-jf.132
                load : Seaside-RenderLoop-lr.72
                load : Seaside-Tools-Core-lr.17
                load : Seaside-Flow-lr.21
                load : Seaside-Examples-jok.18
                load : Seaside-Widgets-obi.18
                load : Seaside-Tools-Web-obi.89
                load : Seaside-Environment-lr.69
                load : Seaside-Development-jf.134
                load : Seaside-Tests-Core-pmm.195
                load : Seaside-Tests-Pharo-Core-pmm.12
                load : Seaside-Tests-Component-lr.29
                load : Seaside-Tests-Canvas-pmm.49
                load : Seaside-Tests-Functional-obi.121
                load : Seaside-Tests-Flow-YM.27
                load : Seaside-Welcome-obi.12
                load : Seaside-Tests-Session-pmm.39
                load : Seaside-Tests-RenderLoop-lr.11
                load : Seaside-Tests-Environment-lr.23
                linear load : 1.0.2 [ConfigurationOfKomHttpServer]
                        load : DynamicBindings-lr.13
                        load : KomServices-lr.20
                        load : KomHttpServer-pmm.53
                load : Seaside-Pharo-Canvas-lr.3
                load : Seaside-Pharo-Environment-lr.6
                load : Seaside-Tests-Pharo-Functional-lr.12
                load : Seaside-Pharo-Tools-Web-lr.21
                load : Seaside-Pharo-Continuation-lr.5
                load : Seaside-Tests-Pharo-Continuation-lr.7
                load : Seaside-Pharo-Flow-lr.5
                load : Seaside-Pharo-Development-lr.42
                load : Seaside-Adaptors-Comanche-pmm.59

Let me know if you'd like to see changes ... I can always release
another version if you want to add groups or make other tweaks...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Wed, Jun 23, 2010 at 1:02 PM, Dale Henrichs <[hidden email]> wrote:
> I would like to release 3.0.0-alpha5.15 for the GLASS users relatively soon,
> but I thought I'd get some feedback on what's included before releasing
> it...

If you hold off briefly I'll get the bloody RC release done and you
can call the version that. :) Naughty me, I've already changed the
version in the code so it will be a bit confusing to have releases
described as alpha describing themselves as RC's (that was bad
planning on my part given the delay in releasing it).

Looks about right, though I wonder why Pharo-Canvas isn't loaded after
Canvas (I guess because nothing else actually depends on Canvas?).

> I have not added a 'Development' group, because I'm not sure what would need
> to be included beyond Seaside-Development (and it's dependents). If there
> another couple of packages that you would consider development packages
> (like including Slime?) then a 'Development' group would be called for.

I think Slime (at least on platforms where it works) is a good
candidate for inclusion. Maybe worth having "Development" there then
on all platforms, even if on some it only currently includes
Seaside-Development?

> As for other groups I can imagine a 'Flow' group would be useful if a
> package beyond Seaside-Flow (and it's dependents) would be required...

Would Flow not be just conditionally loaded in Base depending on the platform?

> Finally, when you load the Seaside-Welcome page using this expression:
>
>  (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
>    load: #('Base' 'Seaside-Adaptors-Comanche' 'Seaside-Welcome' ).
>
> quite a bit gets loaded, because of the inclusion of the Task example
> (WAFlowConvenienceFunctionalTest in Seaside-Tests-Flow)... here's the list
> of mcz files:

Welcome depends on Environment so I expect a lot to get loaded but the
fact that it pulls in a bunch of unit test packages, Development
tools, and possibly Flow is a bit unfortunate. Still, we kind of do
want to demonstrate Flow... suggestions? (btw, I have uncommitted
changes to the Welcome package - I'll try to get those pushed in now).
...
>                load : Seaside-Environment-lr.69
...
>                load : Seaside-Welcome-obi.12
...
Why do all those Pharo packages get loaded at the end? My expectation
is that Pharo-Environment is loaded right after Environment, for
example. This could be important for initialization. I thought
Metacello's requires/includes distinction handled that?

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Wed, Jun 23, 2010 at 5:39 PM, Julian Fitzell <[hidden email]> wrote:
Another comment... is Widgets needed in there by something? I'd kind
of prefer people depend on that if they use it instead of pulling it
in for everyone (those components are badly aging and not really
*core* functionality but samples of usage).

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2010/6/24 Julian Fitzell <[hidden email]>:
Aye, I'd switch Widgets with Flow (if available).

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian,

Widgets is included because it is listed as an Environment dependency in the GRPackage definition, so I don't know whether there is an actual dependency or an artificial one...

Dale
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Julian Fitzell [[hidden email]]
Sent: Wednesday, June 23, 2010 5:42 PM
To: Seaside - developer list
Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for   a bit of review

On Wed, Jun 23, 2010 at 5:39 PM, Julian Fitzell <[hidden email]> wrote:
Another comment... is Widgets needed in there by something? I'd kind
of prefer people depend on that if they use it instead of pulling it
in for everyone (those components are badly aging and not really
*core* functionality but samples of usage).

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian,

That's why I've got the #development blessing for Metacello ... it makes it real easy to flip the switch for production as the last step is to change only the blessing and commit:)

The #includes: directive in Metacello does not tightly bind the included packages together, since Metacello has to allow for dependencies that may _need_ to come between the two packages. I can look another look at the algorithm that calculates load order and see if I can tighten up the coupling ... with that said, I have yet to run into initialization issues so it may not actually make a difference. As I think about this, I don't think that there can be a problem here ... Unless I'm mistaken (with SqueakSource down, I can't look at my most recent ConfigurationOfSeaside30) the packages that come between the #included packages are neutral packages ... #includes: tries to ensure that all packages that depend upon Seaside-Environment get loaded after Seaside-Pharo-Environment ... it does not ensure that Seaside-Pharo-Environment is loaded immediately after Seaside-Environment ... I'll take a closer look to make sure that constraint is not violated.

I'll add the 'Development' group tomorrow with Slime and Seaside-Development...

I'm not sure I understand you comment on Flow being dependent upon the platform (unless you are implying that you want Flow to be part of the 'Base' group except on platforms that don't support Flow).

You are already loading Seaside-Examples for Welcome, it may make sense to create a Seaside-Flow-Examples (ignoring package naming problems) that contained a couple examples of Flow...then it wouldn't be necessary to include the Flow-test (and all of it's dependents) s just to get a Task example.

Dale
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Julian Fitzell [[hidden email]]
Sent: Wednesday, June 23, 2010 5:39 PM
To: Seaside - developer list
Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for   a bit of review

On Wed, Jun 23, 2010 at 1:02 PM, Dale Henrichs <[hidden email]> wrote:
> I would like to release 3.0.0-alpha5.15 for the GLASS users relatively soon,
> but I thought I'd get some feedback on what's included before releasing
> it...

If you hold off briefly I'll get the bloody RC release done and you
can call the version that. :) Naughty me, I've already changed the
version in the code so it will be a bit confusing to have releases
described as alpha describing themselves as RC's (that was bad
planning on my part given the delay in releasing it).

Looks about right, though I wonder why Pharo-Canvas isn't loaded after
Canvas (I guess because nothing else actually depends on Canvas?).

> I have not added a 'Development' group, because I'm not sure what would need
> to be included beyond Seaside-Development (and it's dependents). If there
> another couple of packages that you would consider development packages
> (like including Slime?) then a 'Development' group would be called for.

I think Slime (at least on platforms where it works) is a good
candidate for inclusion. Maybe worth having "Development" there then
on all platforms, even if on some it only currently includes
Seaside-Development?

> As for other groups I can imagine a 'Flow' group would be useful if a
> package beyond Seaside-Flow (and it's dependents) would be required...

Would Flow not be just conditionally loaded in Base depending on the platform?

> Finally, when you load the Seaside-Welcome page using this expression:
>
>  (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
>    load: #('Base' 'Seaside-Adaptors-Comanche' 'Seaside-Welcome' ).
>
> quite a bit gets loaded, because of the inclusion of the Task example
> (WAFlowConvenienceFunctionalTest in Seaside-Tests-Flow)... here's the list
> of mcz files:

Welcome depends on Environment so I expect a lot to get loaded but the
fact that it pulls in a bunch of unit test packages, Development
tools, and possibly Flow is a bit unfortunate. Still, we kind of do
want to demonstrate Flow... suggestions? (btw, I have uncommitted
changes to the Welcome package - I'll try to get those pushed in now).
...
>                load : Seaside-Environment-lr.69
...
>                load : Seaside-Welcome-obi.12
...
Why do all those Pharo packages get loaded at the end? My expectation
is that Pharo-Environment is loaded right after Environment, for
example. This could be important for initialization. I thought
Metacello's requires/includes distinction handled that?

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Philippe,

 I assume that you mean that you think Widgets should be removed from Base and Flow included  in the Base?

I'll do that tomorrow as well...

Dale
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Philippe Marschall [[hidden email]]
Sent: Wednesday, June 23, 2010 10:00 PM
To: Seaside - developer list
Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for   a bit of review

2010/6/24 Julian Fitzell <[hidden email]>:
Aye, I'd switch Widgets with Flow (if available).

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian,

It looks like I _am_ missing an #includes: statement for Seaside-Canvas and Seaside-Pharo-Canvas, so that will probably make the load order look better...I'll double check the other specifications and see if I'm missing any other #includes:...

Dale
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Dale Henrichs [[hidden email]]
Sent: Thursday, June 24, 2010 2:06 AM
To: Seaside - developer list
Subject: RE: [Seaside-dev] ConfigurationOfSeaside30 3.0.0-alpha5.15 ready       for     a bit of review

Julian,

That's why I've got the #development blessing for Metacello ... it makes it real easy to flip the switch for production as the last step is to change only the blessing and commit:)

The #includes: directive in Metacello does not tightly bind the included packages together, since Metacello has to allow for dependencies that may _need_ to come between the two packages. I can look another look at the algorithm that calculates load order and see if I can tighten up the coupling ... with that said, I have yet to run into initialization issues so it may not actually make a difference. As I think about this, I don't think that there can be a problem here ... Unless I'm mistaken (with SqueakSource down, I can't look at my most recent ConfigurationOfSeaside30) the packages that come between the #included packages are neutral packages ... #includes: tries to ensure that all packages that depend upon Seaside-Environment get loaded after Seaside-Pharo-Environment ... it does not ensure that Seaside-Pharo-Environment is loaded immediately after Seaside-Environment ... I'll take a closer look to make sure that constraint is not violated.

I'll add the 'Development' group tomorrow with Slime and Seaside-Development...

I'm not sure I understand you comment on Flow being dependent upon the platform (unless you are implying that you want Flow to be part of the 'Base' group except on platforms that don't support Flow).

You are already loading Seaside-Examples for Welcome, it may make sense to create a Seaside-Flow-Examples (ignoring package naming problems) that contained a couple examples of Flow...then it wouldn't be necessary to include the Flow-test (and all of it's dependents) s just to get a Task example.

Dale
________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Julian Fitzell [[hidden email]]
Sent: Wednesday, June 23, 2010 5:39 PM
To: Seaside - developer list
Subject: Re: [Seaside-dev] ConfigurationOfSeaside30 3.0.0-alpha5.15 ready for   a bit of review

On Wed, Jun 23, 2010 at 1:02 PM, Dale Henrichs <[hidden email]> wrote:
> I would like to release 3.0.0-alpha5.15 for the GLASS users relatively soon,
> but I thought I'd get some feedback on what's included before releasing
> it...

If you hold off briefly I'll get the bloody RC release done and you
can call the version that. :) Naughty me, I've already changed the
version in the code so it will be a bit confusing to have releases
described as alpha describing themselves as RC's (that was bad
planning on my part given the delay in releasing it).

Looks about right, though I wonder why Pharo-Canvas isn't loaded after
Canvas (I guess because nothing else actually depends on Canvas?).

> I have not added a 'Development' group, because I'm not sure what would need
> to be included beyond Seaside-Development (and it's dependents). If there
> another couple of packages that you would consider development packages
> (like including Slime?) then a 'Development' group would be called for.

I think Slime (at least on platforms where it works) is a good
candidate for inclusion. Maybe worth having "Development" there then
on all platforms, even if on some it only currently includes
Seaside-Development?

> As for other groups I can imagine a 'Flow' group would be useful if a
> package beyond Seaside-Flow (and it's dependents) would be required...

Would Flow not be just conditionally loaded in Base depending on the platform?

> Finally, when you load the Seaside-Welcome page using this expression:
>
>  (ConfigurationOfSeaside30 project version: '3.0.0-alpha5.15')
>    load: #('Base' 'Seaside-Adaptors-Comanche' 'Seaside-Welcome' ).
>
> quite a bit gets loaded, because of the inclusion of the Task example
> (WAFlowConvenienceFunctionalTest in Seaside-Tests-Flow)... here's the list
> of mcz files:

Welcome depends on Environment so I expect a lot to get loaded but the
fact that it pulls in a bunch of unit test packages, Development
tools, and possibly Flow is a bit unfortunate. Still, we kind of do
want to demonstrate Flow... suggestions? (btw, I have uncommitted
changes to the Welcome package - I'll try to get those pushed in now).
...
>                load : Seaside-Environment-lr.69
...
>                load : Seaside-Welcome-obi.12
...
Why do all those Pharo packages get loaded at the end? My expectation
is that Pharo-Environment is loaded right after Environment, for
example. This could be important for initialization. I thought
Metacello's requires/includes distinction handled that?

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Thu, Jun 24, 2010 at 2:06 AM, Dale Henrichs <[hidden email]> wrote:
> Julian,
>
> That's why I've got the #development blessing for Metacello ... it makes it real easy to flip the switch for production as the last step is to change only the blessing and commit:)

Well, I similarly have a single place to flip the switch. I just made
the mistake of not doing it last a couple of weekends ago and then
this Welcome screen took on its own life and it's a few weeks later.
:)

> The #includes: directive in Metacello does not tightly bind the included packages together, since Metacello has to allow for dependencies that may _need_ to come between the two packages. I can look another look at the algorithm that calculates load order and see if I can tighten up the coupling ... with that said, I have yet to run into initialization issues so it may not actually make a difference. As I think about this, I don't think that there can be a problem here ... Unless I'm mistaken (with SqueakSource down, I can't look at my most recent ConfigurationOfSeaside30) the packages that come between the #included packages are neutral packages ... #includes: tries to ensure that all packages that depend upon Seaside-Environment get loaded after Seaside-Pharo-Environment ... it does not ensure that Seaside-Pharo-Environment is loaded immediately after Seaside-Environment ... I'll take a closer look to make sure that constraint is not violated.

That's probably fine - I just wanted to make sure that the constraint
was enforced that the Pharo version was loaded before anything that
depended on the generic one.

> I'll add the 'Development' group tomorrow with Slime and Seaside-Development...
>
> I'm not sure I understand you comment on Flow being dependent upon the platform (unless you are implying that you want Flow to be part of the 'Base' group except on platforms that don't support Flow).

Yes, that's what I'm saying. Unless a platform can't handle Flow, it
should be in the Base.

> You are already loading Seaside-Examples for Welcome, it may make sense to create a Seaside-Flow-Examples (ignoring package naming problems) that contained a couple examples of Flow...then it wouldn't be necessary to include the Flow-test (and all of it's dependents) s just to get a Task example.

Yes, or just add one in Welcome itself (don't have to use the cheese
one). I'll take a look.

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

It appears that Tests-Functional, Tools-Web, and Welcome depend on
Widgets. This means it will get loaded in Base anyway, so it's not the
end of the world, though I wonder if we should change those
dependencies to make them more explicit. I'm inclined to say yes...
others?

Julian

On Thu, Jun 24, 2010 at 1:29 AM, Dale Henrichs <[hidden email]> wrote: _______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian Fitzell wrote:
Julian,

Are you saying that you want Welcome to be made part of the Base? I
thought the point of the Base group was to provide a minimal set of
packages that would be the starting point for anyone that was building a
Seaside app. That meant to me that extra things not really needed (like
Welcome and Tools-Web and Widgets) would be excluded ... If someone is
loading Pier, I wouldn't think that the SeasideWelcome would show up as
the default application, or even be loaded unless explicitly asked for ...

That's why I'm using Magritte-Seaside as my use case right now and
trying to think of the folks building applications no top of Seaside ...

I think the explicit dependencies are already in place, but I can take a
look...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Thu, Jun 24, 2010 at 11:09 AM, Dale Henrichs <[hidden email]> wrote:
No, I thought Tools-Web was included in Base and thus that Widgets
would be loaded. Welcome doesn't want to be in Base, I agree.

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

On Thu, Jun 24, 2010 at 11:12 AM, Julian Fitzell <[hidden email]> wrote:
> No, I thought Tools-Web was included in Base and thus that Widgets
> would be loaded. Welcome doesn't want to be in Base, I agree.

Hrm... well WAComponent>>#inform: et al. are in Widgets so maybe we
*do* need that package in Base since people are used to those being
there? I'd prefer to avoid it if we can get away with it, though...
there's a lot of miscellaneous crud in there. Can we get away with it?

Julian
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2010/6/24 Julian Fitzell <[hidden email]>:
> On Thu, Jun 24, 2010 at 11:12 AM, Julian Fitzell <[hidden email]> wrote:
>> No, I thought Tools-Web was included in Base and thus that Widgets
>> would be loaded. Welcome doesn't want to be in Base, I agree.
>
> Hrm... well WAComponent>>#inform: et al. are in Widgets so maybe we
> *do* need that package in Base since people are used to those being
> there? I'd prefer to avoid it if we can get away with it, though...
> there's a lot of miscellaneous crud in there. Can we get away with it?

I don't think so. As long as #inform: and friends are there I think
-Widgets and -Flow should be in base.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

2010/6/24 Julian Fitzell <[hidden email]>:
I'd like Welcome to be in something like "One-Click" that would also
include Development, Kom and OB. Basically the stuff we want first
time users and people coming form 2.8 to have. That should feel more
or less like 2.8 used to feel.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian Fitzell wrote:
The current group definition is:

   'Seaside-Core' 'Seaside-Canvas' 'Seaside-Session'
   'Seaside-Component' 'Seaside-RenderLoop' 'Seaside-Tools-Core'
   'Seaside-Flow' 'Seaside-Environment'

plus dependents and that doesn't include Tools-Web ... I also assume
that Tools-Web shouldn't be included in Base which would then allow for
Widgets to be left out of Base as well...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Julian Fitzell wrote:
That's probably why Widgets was originally included as an Environment
dependent ...

I'll put Widgets back into the Base (along with Flow)...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Philippe Marschall wrote: Philippe,

Sure, I'll add 'One-Click' as a group .... that's a good idea, then it
is real easy for a developer to easilyduplicate the one-click
environment for a particular version ...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Dale Henrichs wrote:
...And await further instructions:)

I've discovered a cool Metacello bug that I'm hunting down right now
(not related to includes:)...so I'm not being held up...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

Philippe Marschall wrote:
Philippe/Julian,

Are there any tests that you'd like included in the One-Click (or were
planned to be in the One-Click) ... I could wait for Julian to ship the
One-Click image itself and then model the One-Click group, but I would
imagine that it wouldn't be too hard to specify the sets of tests to be
included (if at all)...

Dale
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev