[Seaside] inline or link to styles and scripts

Keith Hodges keith_hodges at yahoo.co.uk
Tue Jun 13 23:11:55 UTC 2006

Indeed I have been pondering the distribution problem myself.

Perhaps you would be interested to take a look at the first shot of my 
approach to handling styles entirely within pier. As a first go, it may 
have some rough edges but let me know hat you think of the concept.


you may login as per normal to have a look around.

1. I moved the layout from "/environment" to "/environment/layout" which 
frees up "/environment" for some contextual information, instructions 
and presentation of environment features, which now include a 
stylesheet, and color tables.
(I think that a user manager should go in here also, so as to avoid 
cluttering up the rest of the interface. A save image (copy) action 
button might be a useful administrative tool which could go in here too)

2. I wrote a visitor that collects the text in a page, includes the 
content text of any embedded pages, and  inserts a url for  any embedded 
images. This is used beginning at "/environment/stylesheet/main", and 
the process assembles a stylesheet. embedded text pages can be used as 
variables (see see "/environment/colors" ).

3. The stylesheet is collated into the htmlRoot by PRPierFrame, which 
currently has things like environmentSelector, layoutSelector, 
stylePageSelector, hard coded.

The plan is to take all of this configuration and refactor it into a 
decorator (PRManager and sons). The PRPierDefaultEnvironmentManager 
decorator is applied to the root page by default, and it uses this to 
tell where to find its environment (because when localized it might be 
called something else).

4. (planned) PRManagers may be applied to any page in the wiki tree to 
override styles and layouts for siblings.
Sibling environments should only need to modify bits of the environment 
since they are inherited from the parent environment.

PRManagers will be able to do lots of other useful functions, such as 
maintaining an alias list, colour -> color, for example, or managing the 
"new page as sibling", "new page as child" policies.

I haven't made any effort to present the stylesheet correctly, at the 
moment it is at the mercy of wiki syntax, when displayed (hence comments 
are spread accross two lines to avoid double stars /*not a link*/ being 
interpreted as links)

I have a notion of micro content (which I implemented in a thing called 
tiddlypom) where sub parts of a page are marked and tagged. They may 
even use different parsers. With this in place, the stylesheet 
information could be a sub part of a page with its own non-wiki-syntax 
parser. And colors could be listed in a single page because links such 
as "/environment/colors//broken" would resolve to a marked part of the 
"/environment/colors" page.
I am really impressed with seaside and pier too now I have had a chance 
to get my teeth into it.

best regards

> He mainly uses that becuase there currently is no easy way to
> distrubute images and css files that reference them with Seaside
> applications. There is a package called FileLibrary that does that.
> Philippe
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html

More information about the Seaside mailing list