Mailing-List: contact click-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: click-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of sabob1@gmail.com designates
 74.125.44.155 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=UFf40KPd2RsXIsVb19p3KOr/hnl8R/i0mfZjSnHqYQyF8pld3QyP2sOUNUTCFARzmp
         SuHkSqJSgGojHFpqlDEJ0FcZoS7VJcwXA2+NbUdc7nHDG0HINBdaWycbcmm9NbOO2pOp
         9rVbEgpxvc/RuyZORRmhHz/07lemqB7mQDVkw=
Message-ID: <49E987AE.5040408@gmail.com>
Date: Sat, 18 Apr 2009 09:56:30 +0200
From: Bob Schellink <sabob1@gmail.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: click-dev@incubator.apache.org
Subject: Re: AW: Some features - was: "Re: [VOTE] Propose Click for
 Graduation"
   by Gabor.
References: <4309018.198651240003153718.JavaMail.webmail@ps20zhh.bluewin.ch>
In-Reply-To: <4309018.198651240003153718.JavaMail.webmail@ps20zhh.bluewin.ch>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Jozsef,

Perhaps we can introduce a service which encapsulates the URL mapping 
into a Service. A default implementation can handle .htm and .jsp but 
users can extend it for other purposes as well.

How would the web.xml mapping look like for ClickServlet though? Say 
one wants to serve a *.css template backed by a Click Page how will it 
be mapped in web.xml? If one maps it as '*.css', then all css files, 
regardless if they have a backing Page, will be served by ClickServlet 
and it will need to handle that.

kind regards

bob


jozsef.gabor@bluewin.ch wrote:
> May I defend my points?
> 
> 
> 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;
> }
> 
> 
> XML files and RSS files:
> RSS and list like XML files can be generated with templating too.
> Very complex XML files require a library.
> Sitemap Index and Sitemap files are same as XML
> 
> Example sitemap template:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
> #foreach ($pData in $pageData)
> <sitemap>
>  <loc>$pData.location</loc>
>  <lastmod>$pData.lastModified</lastmod>
> </sitemap>
> #end
> </sitemapindex>
> 
> 
> 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.)
> http://217.114.115.252/sitemap.htm?cat=346
> http://217.114.115.252/sitemap.htm?cat=883
> http://217.114.115.252/sitemap-index.htm
> 
> 
> Json data file can be generated with the xstream library.
> If the Json data set is not huge the entire content can be collected 
> into a single string.
> 
> 
> Javascript templating.
> Sometimes javascript components need several configuration parameters. 
> These configuration parameters could be supplied by objects placed in 
> the context.
> 
> 
> For example a flash object can be implemented as a custom control.
> Instances of this the flash controls can be placed in the middle of 
> pages for example.
> 
> It is also possible to create a flash-panel that use html template.
> 
> Instances of the panel can be added to a page.
> 
> Both solution would work. Selection is the question of preference. (I 
> prefer custom control for flash.)
> 
> 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.
> 
> 
> Kind Regards.
> Jozsef Gabor
> 
> 
> 
> 
>