BorderLayout - Size requires INT where GXT API expects FLOAT

[GoogleCodeExporter]

What steps will reproduce the problem?
1. BorderLayout size expects an "int" and only allows the size to be set in 
pixels

Please provide any additional information below.
The GXT API shows BorderLayoutData::setSize(float size) as allowing a float 
such that values < 1 are interpretted as a percentage.

Issue has been discussed here: 
http://groups.google.com/group/gxt-uibinder/browse_thread/thread/a623950de858c75
c

Original issue reported on code.google.com by ShieldsJ...@gmail.com on 23 Mar 2011 at 8:09

[GoogleCodeExporter]

Thanks for this catch.  Didn't realize it when I wrote the parser.

Original comment by jus...@jhickman.com on 23 Mar 2011 at 8:14

• Changed state: Accepted
• Added labels: Milestone-0.10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Just tested a fix.  In BorderLayoutParser.java, lines ~81-82 can be updated as 
follows:

Double size = Double.valueOf(child.consumeRequiredDoubleAttribute("size"));
writer.addStatement("%1$s %2$s = new %1$s(%3$s.%4$s, %5$f%6$s);", 
     GxtClassnameConstants.BORDERLAYOUTDATA, 
     layoutDataName, 
     GxtClassnameConstants.LAYOUTREGION, 
     region.toUpperCase(), size.floatValue(), "f");

Original comment by ShieldsJ...@gmail.com on 23 Mar 2011 at 9:53

[GoogleCodeExporter]

I just pushed a refactoring of the BorderLayoutParser.  This was one of my 
original ElementParsers for this project, so I revamped it to be more like the 
rest of the LayoutParsers.  I'll have to test more with using the Double and 
then converting to a floatValue.  For the time being, I've been able to 
successfully use the raw value and plop an "f" at the end of it (if it doesn't 
already have one).

Original comment by jus...@jhickman.com on 24 Mar 2011 at 4:32

[GoogleCodeExporter]

Good call on the "plopping" the f and using the raw value.... Less things to 
break during conversion/parsing (probably).

Original comment by ShieldsJ...@gmail.com on 24 Mar 2011 at 12:44

[GoogleCodeExporter]

I'll need to do more testing for this.  I may have to execute regular 
expressions against the value.  The problem comes into play when the generator 
generates the java code, but it fails on compilation.   It doesn't give much 
indication as to where the problem was.  It'd be better if the parser was able 
to use writer.die() and provide enough context to fix the problem. 

Makes more sense for this logic to go back into the 
ElementParserUtil.applyAttributes() method. That way, handling float parameter 
types for setter methods will be handled in a global (GXT global) way.  

I'm still planning on a Sunday release however.

Original comment by jus...@jhickman.com on 24 Mar 2011 at 1:17

[GoogleCodeExporter]

Applied changes to the ElementParserUtil so that any float property type that 
uses this utility will receive the benefit of this change.

Original comment by jus...@jhickman.com on 26 Mar 2011 at 3:05

• Changed state: Fixed