[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.
http://create.seasidehosting.st
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
Keith
> 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