inline or link to styles and scripts

I notice that WAHtmlRoot has methods for (a) rendering style strings
into the document, or (2) linkToStyle: url

Which would be the better approach. Is the browser able to cache
imported stylesheets?
Is it higher performance to send the whole stylesheet inline because
there is only one web hit?

If I try the linkToStyle: approach how do I serve the stylesheet from
seaside.

many thanks in advance

Keith

               
___________________________________________________________
Inbox full of spam? Get leading spam protection and 1GB storage with All New Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Keith Hodges wrote:
There are two simpler ways of applying styles. You can subclass
WAStyleLibrary and define a series of methods that return static text
containing CSS. Then, pick your new style-library class from the
configuration applicaton. A similar process works for javascript by the way.

Alternatively, in any class that is a subclass of WAComponent you can
define a method "style" which returns static text containing CSS.

I prefer the first in most cases, but the second can be useful to
override defaults for specific components.

HTH
--
   Richard Huxton
   Archonet Ltd
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Dear Richard,

I am attempting to add a stylesheet tool to pier, using pier.

Where I am in the heirarchy of pier will determine the stylesheet that
is sent. Since my earlier email I have got this working and I am quite
chuffed with it.

So, the StyleLibrary is a bit static for this, and from what I can tell
uses the inline approach (the styles end up in <style>...</style>
tags.), but lukas has put an "@import ..." in there which I suspect may
cache the stylesheet in the browser.

At the moment I am dynamically generating my stylesheet and sending it
inline, image urls are passed using WADocumentHandler, which gets called
every time to generate the urls on the fly.

I am sure that there is a lot to do to improve efficiency through
caching. At present there is no reason why the stylesheet cannot be
cached when the user saves the stylesheet editing page (unless once the
session expires my image urls go stale)
 
so, would linkToStyle: referencing a text document served by
WADocumentHandler be better than the above?

Keith

               
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Now I can answer my on question, it is taking more than 3 seconds to
render a page if the style is sent every time!
>
> so, would linkToStyle: referencing a text document served by
> WADocumentHandler be better than the above?
>
> Keith


       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 13 Jun 2006, at 16:11 , Keith Hodges wrote:

> Now I can answer my on question, it is taking more than 3 seconds  
> to render a page if the style is sent every time!
>>
>> so, would linkToStyle: referencing a text document served by  
>> WADocumentHandler be better than the above?
>>
>> Keith
>

Using WAStyleLibrary does it all for you, it generates the html link  
to the style sheet, the url,
the WADocumentHandler with the proper content-type and expiry, etc.  
(Have a look at #writeStyle:on:).
As a result it should take advantage of caching by the navigator and  
it should not take 3 seconds.
The same applies to WAScriptLibrary and to the #style and #script  
methods. Like Richard I recommend
using WAScriptLibrary.

HTH
Michel.


_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

I sussed the 3 seconds problem, lots of semaphores and processes hanging...

But isnt WAScriptLibrary global to the application?

               
___________________________________________________________
Try the all-new Yahoo! Mail. "The New Version is radically easier to use" – The Wall Street Journal
http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On 13 Jun 2006, at 17:23 , Keith Hodges wrote:

> I sussed the 3 seconds problem, lots of semaphores and processes  
> hanging...

I do not understand "sussed".

>
> But isnt WAScriptLibrary global to the application?

It is and its url is computed using the application base.
On the other hand, I guess it could be reused by other applications,  
but it is worth
the effort ?

_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> So, the StyleLibrary is a bit static for this, and from what I can tell
> uses the inline approach (the styles end up in <style>...</style>
> tags.),
Nope, links to documents which can be cached by the browser.

> but lukas has put an "@import ..." in there which I suspect may
> cache the stylesheet in the browser.
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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

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

               
___________________________________________________________
Now you can scan emails quickly with a reading pane. Get the new Yahoo! Mail. http://uk.docs.yahoo.com/nowyoucan.html
_______________________________________________
Seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside