[jira] Commented: (CLK-606) common click core depends on Velocity

["Joseph Schmidt (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CLK-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12840603#action_12840603 ] 

Joseph Schmidt commented on CLK-606:
------------------------------------

I think too that this is not a but but a feature.

>From what I understood, Click supports several template languages:
Velocity, JSP, FreeMarker, and it's possible to add new ones too quite simply.

Click internally however and the official components too, use Velocity.
The fact that Click supports FreeMarker or JSP too (or your own template) means that users
can write their own pages with that - not that Click Core should be implemented in those too.

E.g. JSP is present in Click since very very long ago (to allow the easy migration of Struts and JSP applications too), but still, no component is duplicated with JSP too.

The Velocity JAR is quite small (and also included in click.jar), so there's no reason not to have it, and why the architecture of click should be made even more abstract and complicated.


> common click core depends on Velocity
> -------------------------------------
>
>                 Key: CLK-606
>                 URL: https://issues.apache.org/jira/browse/CLK-606
>             Project: Click
>          Issue Type: Bug
>          Components: core
>    Affects Versions: 2.1.0 RC1, 2.0.1
>         Environment: click-nodeps-2.1.0-RC1-incubating.jar , click-extras-2.1.0-RC1-incubating.jar, ognl-2.6.9.jar, freemarket2.3.16.jar
>            Reporter: Andrey Rybin
>
> I use freemarker and dependencies in separate jars. 
> I haven't 'velocity' in my classpath.
> So I found bug: common click core depends on Velocity.
> Namely:
> org.apache.click.ClickServlet.java
> org.apache.click.util.ErrorReport.java
> They both depend on
> org.apache.velocity.exception.ParseErrorException   (search:
> instanceof ParseErrorException)
> and require Velocity be present in classpath even if freemarker are used.
> My workaround:
> I made fake public class ParseErrorException extends Exception {}.
> But you can make generic solution, for example:
> TemplateService
> + boolean isParseErrorException (Exception e)
> + Map<String, Object> describeParseErrorException (Exception e)
> or your own ClickTemplateException to wrap low level velocity/freemarker exceptions.

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