click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [JIRA] Commented: (CLK-288) Consider making getStyleBlock and getScriptBlock first class citizens
Date Sun, 01 Feb 2009 18:22:56 GMT

    [ http://issues.apache.org/click/browse/CLK-288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=11668#action_11668
] 

Bob Schellink commented on CLK-288:
-----------------------------------

test ignore

> Consider making getStyleBlock and getScriptBlock first class citizens
> ---------------------------------------------------------------------
>
>                 Key: CLK-288
>                 URL: http://issues.apache.org/click/browse/CLK-288
>             Project: Click
>          Issue Type: Improvement
>          Components: core
>    Affects Versions: 1.5 M1
>         Environment: Click 1.5
>            Reporter: Bob Schellink
>            Assignee: Bob Schellink
>             Fix For: 2.1.0
>
>
> Javascript and stylesheets can either be external or embedded in the html.
> Currently Click support getHtmlImports which can return both external and embeded code.
However there is a restriction: each line from getHtmlImport must be unique for the page.
> For external files this works out quite well. But <script> and <style> blocks
makes for some messy strings in java. Custom controls especially AJAX ones, could really benefit
from this. Also it is extremely hard to debug javascript code which appear on one line. 
> Since Velocity can render javacsript and css equally well it would be nice to write these
blocks in Velocity. Javascript id's and css paths could be passed into the template. Off course
one can still use HtmlStringBuffer, but without the restriction of having the block in one
line.
> Another advantage is the separation of embedded vs external code. Placing the embedded
code below the external code means the javascript libraries will be available when the embedded
code are executed.
> Thinking about implementation we need methods getStyleBlock and getScriptBlock that PageImports
can slurp up. Adding these to Control might be asking too much, so perhaps AbstractControl?
PageImports can check for AbstractControl instances just like it does for Form,Table etc and
append the blocks from those controls.
> It might be worth thinking about exposing these methods on Page as well. Since Page maps
one-to-one to the html page, it seems quite logical that a Page could contribute and customize
<style> and <script> blocks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message