[Seaside] Re: FileLibrary / css files confusion - diagnosis: trying to change '/seaside/' in URL messes up FileLibrary ??

[Keith Hodges]

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.
>
> Lukas
>   
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
seaside/config.

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

Keith