| Previous · Next | |
| User | Message |
|
arjan
|
Date: 9/15/2008 8:17 am · Subject: How about moving YUI css from extras to import node · Rating: 0
Martin suggested an easy solution for this: why not move the YUI css from the extras folder? By making the css files into snippets in the import node designers can: - change the look-and-feel of YUI elements like the date-picker - make WebGUI conform to standards for a particular site As a spinn-off, it makes it easier to update WebGUI to use the latest version of certain css files. Of course it would be even nicer if the forms system didn't put css files in the head, but that's probably a nastier problem to solve.
Kind regards, Arjan Widlak United Knowledge |
| Back to Top |
Rate [ | ]
|
|
JT
|
Date: 9/15/2008 8:55 am · Subject: Re: How about moving YUI css from extras to import node · Rating: 0
The answer is no. This is neither an easy or a good solution. First, it causes a big performance hit, because rather than serving up static files we're serving up the YUI stuff as a dynamic object even though it's not dynamic. Second, we're storing the YUI stuff as many times as there are sites on the server. Third, if you want to modify the YUI stuff then you can also do it via /extras provided you control the server, and if you don't control the server then you shouldn't be modifying it. Fourth, mucking with YUI can cause unpredictable results, there's no reason any normal user should ever have access to it. Fifth, YUI classes are by definition overridable (though I know in your case that doesn't help).A better solution, would be to put a YUI base URL in the config file. Then you could point all of your customers to a single YUI instance that you have modified. This also helps other users in that we could defaultly point to Yahoo's YUI archive because chances are that site visitors have already visited their site, and we'd get the CDN effect. And those users who cannot use the Yahoo CDN could still point it back to their local /extras folder on their server. On Sep 15, 2008, at 8:17 AM, <arjan@unitedknowledge.nl> wrote: arjan wrote: JT Smithph: 703-286-2525 x810fx: 312-264-5382 Create like a god. Command like a king. Work like a slave. |
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 9/15/2008 11:15 am · Subject: Re: How about moving YUI css from extras to importnode · Rating: 0
Hi JT,Thanx for explaining the rationale behind this and you alternative solution. Configuring a YUI-base URL in the WebGUI config is a step that helps, because one can separate a default WebGUI install from custom YUI css adaptations to make them standards compliant. And perhaps more arguments have to be made at the YUI mailing list to convince them to become standards-compliant. However, the more AJAX becomes a normal thing on the web, the more designers have to be able to change the look and feel of these javascript-generated objects. And being templatable will not be being templatable anymore if you can't change these javascript-generated objects. But of course, you are right: YUI classes are overridable. That would be the way to overcome this second problem then. Of course to make that somewhat user-friendly for a designer, some documentation of what is rendered where will become a necessity. Stuff to think about for all of us I guess. Kind regards, Arjan. P.S. I read a really funny email footer recently in a Debian list: "Ubuntu is an ancient African word meaning: I don't know how to configure Debian." On Mon, 2008-09-15 at 08:55 -0500, jt@plainblack.com wrote: > JT wrote: > > The answer is no. This is neither an easy or a good solution. First, > it causes a big performance hit, because rather than serving up static > files we're serving up the YUI stuff as a dynamic object even though > it's not dynamic. Second, we're storing the YUI stuff as many times as > there are sites on the server. Third, if you want to modify the YUI > stuff then you can also do it via /extras provided you control the > server, and if you don't control the server then you shouldn't be > modifying it. Fourth, mucking with YUI can cause unpredictable > results, there's no reason any normal user should ever have access to > it. Fifth, YUI classes are by definition overridable (though I know in > your case that doesn't help). > A better solution, would be to put a YUI base URL in the config file. > Then you could point all of your customers to a single YUI instance > that you have modified. This also helps other users in that we could > defaultly point to Yahoo's YUI archive because chances are that site > visitors have already visited their site, and we'd get the CDN effect. > And those users who cannot use the Yahoo CDN could still point it back > to their local /extras folder on their server. > > > > On Sep 15, 2008, at 8:17 AM, wrote: > arjan wrote: > > > > > Earlier I posted this bug report about the forms system that > puts links to YUI css files in the extras folder in the head. > The reason I experienced this as a bug is that this makes it > impossible to change the look-and-feel of elements such as the > date picker for example and to change the YUI code in a > particular site to make it validate. > > Martin suggested an easy solution for this: why not move the > YUI css from the extras folder? By making the css files into > snippets in the import node designers can: > > - change the look-and-feel of YUI elements like the > date-picker > > - make WebGUI conform to standards for a particular site > > As a spinn-off, it makes it easier to update WebGUI to use the > latest version of certain css files. > > Of course it would be even nicer if the forms system didn't > put css files in the head, but that's probably a nastier > problem to solve. > > > > > Kind regards, > > Arjan Widlak > > United Knowledge > Internet for the public sector > > www.unitedknowledge.nl > > > > http://www.plainblack.com/webgui/dev/discuss/how-about-moving-yui-css-from-extras-to-import-node > > -- > > Plain Black, makers of WebGUI > http://plainblack.com > > > JT Smithph: 703-286-2525 x810fx: 312-264-5382 > Create like a god. Command like a king. Work like a slave. > > > http://www.plainblack.com/webgui/dev/discuss/how-about-moving-yui-css-from-extras-to-import-node/1 > -- Arjan Widlak United Knowledge | Politiek-digitaal.nl |
| Back to Top |
Rate [ | ]
|
|
arjan
|
Date: 9/16/2008 11:43 am · Subject: Re: How about moving YUI css from extras to import node · Rating: 0
For those who are interested in how I solved this. I wanted to solve two things:
In essence this resulted in an output filter that replaces this: link href="/extras/yui/build/calendar/assets/skins/sam/calendar.css" rel="stylesheet" media="all" type="text/css" /> by: link rel="stylesheet" href="/kalender/zoek.css" type="text/css" /> The first css is the css for the search view of the calendar, but this part has nothing to do with YUI. The problem here was that putting css in the head block of the Calendar search template resulted in getting it in the body instead of in the head of the page. This bug was already posted by xootom. The second css file is the css that is connected to YUI and is the same for all browsers. The other two in conditional comments are specific to a certain browser version. This is how we believe it should be. To get this I've written an output filter, based on an example in the mod_perl2 documentation. An output filter can be configured in the in the mod_perl config just below the PerlInitHandler like so: PerlInitHandler WebGUI The filter itself is attached. Suggestions as to how to do this in a better way are of course welcome.
Kind regards, Arjan Widlak United Knowledge Attached Files |
| Back to Top |
Rate [ | ]
|
