You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by "Andrey P.Rybin" <ap...@gmail.com> on 2010/01/14 15:23:55 UTC

Bug fix, small improvements and russian translation

Hello, All!

I'll try to write here.

1. Bug fix:
I like freemarker's, dependencies in separate jars and 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)



===
2. org.apache.click.util.ClickUtils.java
Instead of few .close(SomeIoObject) methods you can use ONE:

public static void close (Closeable someStreamOrWriter) {
    if (someStreamOrWriter != null) {
      try {
        someStreamOrWriter.close();
      } catch (Throwable ignore) {} //don't believe in IOException
    }
  }//close


My own code looks like this:
public static void close (@Nullable Closeable someStreamOrWriter) {
    if (someStreamOrWriter != null) {
      try {
        someStreamOrWriter.close();
      } catch (Throwable e) {
        log.debug("close: can't close "+ someStreamOrWriter, e);
      }
    }//i
  }//close


All them: reader, writer and streams implement Closeable.


====
3. properties files encoding

J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009

So we can try to use some Java6 features with care.

For example (somewhere in Click core):

  private static volatile Boolean java6;//def: null=unknown

public static void loadProperties (Properties properties, InputStream
in, final Charset charset)
    throws IOException, IllegalArgumentException  {

    if (java6 == null) { //1st run
      try {
        java6 = Properties.class.getMethod("load", Reader.class) != null;
      } catch (Exception ignore) {
        java6 = false;
      }//t
    }//i

    if (java6.booleanValue()) {
      properties.load(new InputStreamReader(in, charset));

    } else { //older than 1.6. load(Reader) not supported
      properties.load(in);
    }//i
  }//loadProperties

Profit:  click property files can be in UTF-8 encoding instead of that
ugly \u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234

and it is full backward compatible - you don't need to convert ISO
8859-1 encoded property files (with these \ucafe\ubebe) to UTF-8.
But you can.



4. I made russian translation for click-control_ru.properties
Attached.


> If I have found bug in Click core and have few small improvements -
> can I write about them to this community or must use dev-list or JIRA
> instead?

Re: Bug fix, small improvements and russian translation

Posted by Malcolm Edgar <ma...@gmail.com>.
I think this is more of an oversight as Freemarker support was
introduced after Velocity. To fix this we would need a
TemplateException which would wrap the equivalent Velocity or
Freemarker exception.

regards Malcolm Edgar

On Fri, Jan 15, 2010 at 9:30 AM, Adrian A. <a....@gmail.com> wrote:
>>> 1. Bug fix:
>>> I like freemarker's, dependencies in separate jars and i haven't
>>> 'velocity' in my classpath.
>>> So I found bug: common click core depends on Velocity.
>>
>>
>> Would you mind raising a JIRA for this issue?
>
> If I recall right, this isn't a bug but it's intentional.
> Click supports Velocity, JSP and Freemarker as template languages, but it's
> using internally Velocity.
>
> Adrian.
>
>

Re: Bug fix, small improvements and russian translation

Posted by "Adrian A." <a....@gmail.com>.
>> 1. Bug fix:
>> I like freemarker's, dependencies in separate jars and i haven't
>> 'velocity' in my classpath.
>> So I found bug: common click core depends on Velocity.
>
>
> Would you mind raising a JIRA for this issue?
If I recall right, this isn't a bug but it's intentional.
Click supports Velocity, JSP and Freemarker as template languages, but 
it's using internally Velocity.

Adrian.


Re: Bug fix, small improvements and russian translation

Posted by Bob Schellink <sa...@gmail.com>.
On 15/01/2010 01:23 AM, Andrey P.Rybin wrote:
>
> 1. Bug fix:
> I like freemarker's, dependencies in separate jars and i haven't
> 'velocity' in my classpath.
> So I found bug: common click core depends on Velocity.


Would you mind raising a JIRA for this issue?


> ===
> 2. org.apache.click.util.ClickUtils.java

> Instead of few .close(SomeIoObject) methods you can use ONE:


Thanks, I've checked your change into trunk.


>
> ====
> 3. properties files encoding
>
> J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009
>
> So we can try to use some Java6 features with care.
>
> For example (somewhere in Click core):
>
>    private static volatile Boolean java6;//def: null=unknown
>
> public static void loadProperties (Properties properties, InputStream
> in, final Charset charset)
>      throws IOException, IllegalArgumentException  {
>
>      if (java6 == null) { //1st run
>        try {
>          java6 = Properties.class.getMethod("load", Reader.class) != null;
>        } catch (Exception ignore) {
>          java6 = false;
>        }//t
>      }//i
>
>      if (java6.booleanValue()) {
>        properties.load(new InputStreamReader(in, charset));
>
>      } else { //older than 1.6. load(Reader) not supported
>        properties.load(in);
>      }//i
>    }//loadProperties
>
> Profit:  click property files can be in UTF-8 encoding instead of that
> ugly \u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234
>
> and it is full backward compatible - you don't need to convert ISO
> 8859-1 encoded property files (with these \ucafe\ubebe) to UTF-8.
> But you can.


Looks promising. I think Click uses Java ResourceBundle.getBundle to load its properties, so this 
might require a bit of rework. If you are interested have a look at ClickUtils.getBundle implementation.


>
> 4. I made russian translation for click-control_ru.properties
> Attached.
>

Thanks very much. Can you open a JIRA for this and attach the property file to that issue? Also note 
that click-extras contains a couple of property files as well. Look under the folder 
<click-dist>/extras/src/org/apache/click/extras/control

kind regards

bob

Re: Bug fix, small improvements and russian translation

Posted by "Andrey P.Rybin" <ap...@gmail.com>.
Bob Schellink wrote:
> Looks promising. I think Click uses Java ResourceBundle.getBundle to load its properties, so this
> might require a bit of rework. If you are interested have a look at ClickUtils.getBundle implementation.


Oh. Forget about "properties files encoding" ;-)
As i can see ResourceBundle.getBundle doesn't support encodings other
than ISO8859-1

java.util.ResourceBundle
line 2428:   bundle = new PropertyResourceBundle(stream); //here must
be (reader)

ClassLoader hack (our own classloader, who forward calls to
Thread.currentThread().getContextClassLoader()) looks too troubled.



On Thu, Jan 14, 2010 at 19:23, Andrey P.Rybin <ap...@gmail.com> wrote:
> I'll try to write here.
>
> 1. Bug fix:
> I like freemarker's, dependencies in separate jars and 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)
>
>
>
> ===
> 2. org.apache.click.util.ClickUtils.java
> Instead of few .close(SomeIoObject) methods you can use ONE:
>
> public static void close (Closeable someStreamOrWriter) {
>    if (someStreamOrWriter != null) {
>      try {
>        someStreamOrWriter.close();
>      } catch (Throwable ignore) {} //don't believe in IOException
>    }
>  }//close
>
>
> My own code looks like this:
> public static void close (@Nullable Closeable someStreamOrWriter) {
>    if (someStreamOrWriter != null) {
>      try {
>        someStreamOrWriter.close();
>      } catch (Throwable e) {
>        log.debug("close: can't close "+ someStreamOrWriter, e);
>      }
>    }//i
>  }//close
>
>
> All them: reader, writer and streams implement Closeable.
>
>
> ====
> 3. properties files encoding
>
> J2SE 5.0 reached its End of Service Life (EOSL) on November 3, 2009
>
> So we can try to use some Java6 features with care.
>
> For example (somewhere in Click core):
>
>  private static volatile Boolean java6;//def: null=unknown
>
> public static void loadProperties (Properties properties, InputStream
> in, final Charset charset)
>    throws IOException, IllegalArgumentException  {
>
>    if (java6 == null) { //1st run
>      try {
>        java6 = Properties.class.getMethod("load", Reader.class) != null;
>      } catch (Exception ignore) {
>        java6 = false;
>      }//t
>    }//i
>
>    if (java6.booleanValue()) {
>      properties.load(new InputStreamReader(in, charset));
>
>    } else { //older than 1.6. load(Reader) not supported
>      properties.load(in);
>    }//i
>  }//loadProperties
>
> Profit:  click property files can be in UTF-8 encoding instead of that
> ugly \u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234\u1234
>
> and it is full backward compatible - you don't need to convert ISO
> 8859-1 encoded property files (with these \ucafe\ubebe) to UTF-8.
> But you can.
>
>
>
> 4. I made russian translation for click-control_ru.properties
> Attached.
>
>
>> If I have found bug in Click core and have few small improvements -
>> can I write about them to this community or must use dev-list or JIRA
>> instead?
>