Here's some of my thoughts (from 30,000ft): On an enterprise level, where organizations consist of Java developers and html page authors, the page authors should retain all control of the CSS. To me, this means keeping all css definitions and generation out of any java code or build scripts. The application should code should be completely separate, allowing for page authors to drop in changes to their html and css w/out making any modifications to the app. With this in mind, I think it would be most useful to provide CSS as a Hivemind service, where the page authors can be trained to alter the hivemodule.xml file to simply add new css file to the file (and specifty directory). Ideally, by default, the Hivemeind service (with Tapestry) would do the following:
1- Include an application-scope css file. If my application is Doonesbury (which it aint), doonsebury.css will be referenced in each pages html as an external file (<link rel="stylesheet" type="text/css" href="/styles/doonesbury.css">) 2- Include a page-scope file: if it exists a css file with the same name of the page (page=DailyDose, dailyDose.css) exists, it will be referenced as an external file in the html: (<link rel="stylesheet" type="text/css" href="/styles/dailyDose.css">) 3- Include a component-scope file: essentially the samething..but this needs more thought. On 11/7/05, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > I don't know how css caching workings from browser to browser but I have > confirmed that js asset urls do seem to cache successfully, at least in > firefox. This extension should alleviate any doubts for most things when > running on firefox: > > http://tamperdata.mozdev.org/ > > It tells you whether it's using cached data or new data for each and every > io transmission. > > I am wary of dyn generated js/css as well though. I know the dyn js is > giving me performance hits I'd rather not have, which is why I've been > slowly re-factoring some of my .script include logic into static js > package > methods taking more arguments. > > The shell component and all the assets it works with are still special and > should be addressed directly. Only because you can only have one(or > ~should~ > only have one..), and what's the point in saying components can bundle > their > own assets if they sort of really can't? Besides images/js of course. > Global > asset pool contributions or some other similar concept might help > this...Or, > the service managing assets can specifically address css/js includes > differently than the others. The shell component could specify > allow-global="yes/no" or something. ...? > > jesse > On 11/7/05, Patrick Casey <[EMAIL PROTECTED]> wrote: > > > > > > Assuming the URL to your css doesn't change, it should still be > > cacheable whether it's generated by a servlet or it's a static file, > neh? > > I've definitely had to work around the opposite problem from time to > time > > where my browser was caching dynamic images I didn't *want* it to cache > > (solutions ranged from using 32 bit guids for links to adding 16 bits of > > random noise to every link). > > > > So in theory, each piece of generated CSS should be rendered once > > per cache window which is going to be more expensive than serving a > static > > file, but it shouldn't be anywhere near as bad as once per page render. > > > > -- Pat > > > > > -----Original Message----- > > > From: Hensley, Richard [mailto:[EMAIL PROTECTED] > > > Sent: Monday, November 07, 2005 8:35 AM > > > To: Tapestry users > > > Subject: RE: Tapestry and CSS - asking for feedback > > > > > > My biggest concern about generated CSS is site performance. One of the > > big > > > gains our site made by implementing CSS was much smaller downloads > > because > > > our HTML was smaller, and the CSS was cached by the browser. I've seen > > > Vignette portal sites suffer from performance problems because of the > > CSS > > > generation issues that can be caused by create use of the portal > > software. > > > > > > Richard > > > > > > -----Original Message----- > > > From: Ron Piterman [mailto:[EMAIL PROTECTED] > > > Sent: Sunday, November 06, 2005 11:53 AM > > > To: [email protected] > > > Subject: Tapestry and CSS - asking for feedback > > > > > > Hi, > > > Feedback on > > > http://www.tutim.net/wiki/index.php/Tapestry_Css > > > would be most appreciated... > > > Cheers, > > > Ron > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > >
