You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@click.apache.org by "Bob Schellink (JIRA)" <ji...@apache.org> on 2009/02/01 19:22:56 UTC

[JIRA] Commented: (CLK-288) Consider making getStyleBlock and getScriptBlock first class citizens

    [ 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.