[Seaside] Re: FileLibrary / css files confusion - diagnosis:
trying to change '/seaside/' in URL messes up FileLibrary ??
keith_hodges at yahoo.co.uk
Wed Jan 2 15:38:54 UTC 2008
Lukas Renggli wrote:
>> I am speaking of WASession-application:
> The way the session stores its application is an internal
> implementation detail of the framework. Seaside instantiates and
> initializes the session objects for you and this is usually something
> you shouldn't bother about.
Unfortunately Seaside is rarely the be-all and end-all of an application
it is merely one front end presentation of that application.
Given that I have made a design choice to have my applications present
all of their settings in seaside/config when I want to do something in a
workspace, or offline script I need to instanciate a mock session so
that I can work in the context of the chosen application and its
settings. This used to be just a little bit simpler and has become a
very common pattern for me. It is used in a number of places:
The 'pier' and 'magma' control panels which appear as configuration
application plugins are rendered in a session of the configuration app,
while they operate upon the preferences and data structures of a mock
session of the actual app which they control.
The Jetsam package defines WASession forApp: name during: [ ]
This provides the ability to run code in a workspace in the context of a
chosen seaside application (i.e. the settings and WACurrentSession is
defined while in the block).
Finally Magma-seasideHelper uses a variant of this, "WAMagma forApp:
name", in order to access or commit to the database as configured in
So thats 4 use cases which is sufficient for me to think that putting
#application: back is worthwhile, which indeed I do in Jetsam
I have separated Jetsam out into some separate packages, so that the
Helper framework is available as a separate entity. Please would you
consider adopting this properly into the mainstream 2.9 release.
many thanks in advance
More information about the seaside