[Seaside] [Fwd: Re: [Moose-dev] Re: why Glamour configuration
is loading Refactoring and all the rest?]
dhenrich at vmware.com
Sat May 29 20:36:08 UTC 2010
Julian Fitzell wrote:
> On Sat, May 29, 2010 at 12:32 AM, Dale Henrichs <dhenrich at vmware.com> wrote:
>> To directly answer your question...I agree, loading Grease should not load
>> Slime by default and yes, Slime can certainly be in it's own Metacello
>> configuration (not package:).
> Looking at the Metacello chapter PDF that's circulating, it looks like
> what I meant was "project". Are you sure these things want their own
> configurations? It seems to me that Slime is "part of" Grease and all
> those other packages are "part of" Seaside, they're just not part of
> the core. Again, apologies if I'm just misunderstanding the
> terminology or the repercussions.
Project and configuration are very similar in meaning, When I say
"configuration" I am specifically referring to a "ConfigurationOf package".
In my opinion I think that "these things" do want their own
configuration. That is why I mentioned them:) However, the confguration
vs group decisions should be made by the developers themselves since
that structure influences how users of the configurations/groups view
From my perspective Slime is built on top of Grease rather than being a
fundamental part of Grease. Grease is supposed to be a portability layer
and Slime doesn't implement portability methods. Slime is a tool that
is used to analyze the portability of a body of code, but at the moment
Slime itself has not been ported to either Squeak or GemStone nor is it
_required_ for "Grease" functionality on the other platforms.
So from that perspective Slime could be separated out into a separate
configuration without affecting the basic functionality of Grease as a
In the end it is a judgment call as to when a chunk of functionality
should be split out separately, because in terms of pure functionality
the following two statements end up loading _exactly_ the same packages:
ConfigurationOfSlime project latestVersion load.
ConfigurationOfGrease project latestVersion load: 'Grease-Slime'.
The factors that I think drive one towards choosing a configuration over
a group are:
1. how independent is the chunk of functionality?
- does the chunk of functionality have a utility outside of the
- does the chunk of functionality have an identity independent of
the original project?
- if either of the above are largely true, then a separate
configuration may be a good choice
2. how critical is the chunk of functionality to the project?
- is it an option or an addon, where an "option" is something that
you have to choose one from many and an "addon" is something that
can be completely left off without affecting functionality?
3. how heavy weight is the chunk of functionality?
- an addon that is complex in terms of the number of individual mcz
files or in terms of "required projects" may be easier to manage
if it is in its own configuration
4. how tight is the coupling of the chunk of functionality?
- if the chunk of functionality is tightly coupled to the "core"
then it makes sense to embed the functionality in main
I think that you went through a similar decision process when you
originally split Grease out from Seaside.
In my opinion Slime should be separated out for points 1 (outside
functionality and independence), 2, and 3.
Scriptaculous) I think the strongest arguments are points 2 and 3 ... I
don't know about 4 as for point 1, they don't have much utility outside
of a Seaside context so I would lean toward using a group with the
caveat that point 3 could be a reason for moving them all into a
RSS seem to me to be candidates because it is more like an addon.
Comet could be called a group because of point 4.
So the first order decision would be are any of those chunks candidates
for separate configurations or not ... in your opinion?
>> So if I add Slime to the list, then here are the projects that are currently
>> embedded in the Grease and Seaside30 configurations that should be broken
>> out into their own configurations:
>> - JQuery
>> - Prototype
>> - RSS
>> - Scriptaculous
>> - Comet
>> - Slime
>> - Grease
>> - Seaside30
>> If that makes sense to you I can start building up the configurations (I can
>> do the work without interfering with current users) for your consideration.
> I'd think you'd also want to be able to load or not load:
> Seaside-Base, Seaside-Development, Seaside-Admin-OmniBrowser,
> Seaside-Admin-Web, Seaside-Examples for a start. These functionality
> groupings don't seem conceptually any different to the ones above to
Once your past the configuration decision then defining groups to make
it easy for users to make load/not load decisions.
What packages do you consider part of the Seaside-Base and where does
Seaside-Environment fit in?
More information about the seaside