click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joseph Schmidt <>
Subject Re: AW: Some features - was: "Re: [VOTE] Propose Click for Graduation" by Gabor.
Date Sat, 18 Apr 2009 11:24:35 GMT
> May I defend my points?
Sure. Sorry if I wasn't specific enough :).

> CSS templating:
> It think dynamically generated CSS files are acceptable and they work 
> wonderfully.
> They allow to change border colors background colors, background images 
> on the fly.
> Example:
> input {
>  border-color: $objectStyle.borderColor;
>  border-width: 1px;
>  border-style: solid;
> }
> body{
>  background-image: url($context/content?id=1&file=101&cat=0);
>  background-repeat: repeat;
> }
I understand you point, and technically you are right :).
However, here's the deal with CSS (what I've heard from CSS experts - 
I'm just a newbie :) ):
- CSS is very very hard to get it right for the most user, even
if it's static. As a proof is the majority of websites that are butt 
ugly - users simply can't get it right. Even if CSS is "smart" and 
cascaded, and like a scripting language, etc, etc, users barely get it.
- making it dynamic, just complicates the whole mess with an order of 
This is why so many experts recommend not to use CSS frameworks at all
(at most a good CSS Reset file), but not CSS frameworks or dynamic tricks.

In case of Click what you describe it is still simply possible with:
- a #parse(myCSS_template.vm) to include those changing variables in the 
body, or
- I saw the in trunk (as of Click 2.1), there's a CSSStyle class that 
allows this even simpler without #parse().

> XML files and RSS files:
> RSS and list like XML files can be generated with templating too.
> ...
> Here are the living sitemap examples. 
> (The sitemap xml is requested as html so the browser will display it as 
> html.
> Please open the source in the browser to be able to see the xml.)
Sorry, now I see the sitemap :). I expected to browser to render
it nicely :). It's looking good.

> Javascript templating.
> Sometimes javascript components need several configuration parameters. 
> These configuration parameters could be supplied by objects placed in 
> the context.
Now you could do this with the equivalent of CSSStyle mentioned above, 
called JSScript (or the old way using inside the page body those elements)

> In general any kind of textual content (except json) can be served by 
> templating mechanism.
> It may not be efficient to create custom control for everything.
Now I see the big picture :).
Basically you want to use Click as a templating framework, but Click is 
*not* that: Click is *using* a templating framework like Velocity.

I think Click is a Page and Component oriented framework (and it should 
remain so). In the case of your requests, in Click those should be 
Controls not Pages, so no extension changes are required.

Also, if you want so much other extensions, URLRewrite filter should be 
a much better choice:
You could have a rule that changes the extension for a file like:
/dynamic-css.htm    to be rewritten (in and out) to
so that to the browser to appear with the right extension.

Or you can combine the rule that with directory convention to apply it 
on many many files at once:
/css/file_xxx.htm -> /file_xxx.css
/js/file_xxx.htm -> /file_xxx.js
/xml/file_xxx.htm -> /file_xxx.xml

Here's another short article how to clean URLs with URLRewrite:
So in your case, instead of having:
with such a rule, the rule could look like: /shop/details/001.htm
(or /shop/details/001 - without extension like Rails)


View raw message