Why can't you just simply define your getter method as follows:
public String getLabelProp() {
return getLabel() == null ? getId() : getLabel();
}
I think it's pretty legal to implement getter in a such way.
пятница, 9 августа 2013 г., 1:37:21 UTC+4 пользователь Chulbul Pandey
написал:
I
Hi,
firefox doesn't support standard calc yet - this works for me:
width: -moz-calc(100% -16px);
Pavel
Dne pátek, 9. srpna 2013 19:13:33 UTC+2 Wayne Rasmuss napsal(a):
I have the following css entry that I'm accessing via a CSS resource
.form-input-line-cell {
position: absolute;
I guess your are using this for GXT grid. Since the PropertyAccess is used
later to define a Column in the ColumModel of your grid, you need to define
your how implementation of LabelProvider since the one generated through
GWT.create(FieldProperties) will not work. Then, you create an instance
Thanks! Using literal fixed it. It turned out I didn't need the special web
kit value either. This seems to work in IE 10, Firefox, and Chrome (latest
or very recent updates of each)
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To
For anyone who cares the final css looks like this:
I'm actually thinking of trying position relative and using the same calc
method for the height as well.
.form-input-line-cell {
position: absolute;
left: 8px;
top:3px;
bottom: 3px;
font-size: 32px;
text-indent: 8px;
Christ!
I have never seen a hover effect so sluggish (probably because the
hover/graying effect is being added programatically by CellTable
implementation code of the mouse out and mouseover).
The online sample goes fast on the browser,
I created a GWT project [without using the option of generate sample code].
I have added Entry Point class, html page, module file. The bootstrap js
file is getting generated under war/com.travelpeeps.travelpeeps folder and
its name is com.travelpeeps.travelpeeps.nocache.js. When i looked at
The one triggered by mvn gwt:run is a disaster.
Mouseout: 176 ms, mouseover 208 ms, according to speed tracer, but it
looks even slower.
gwt:run starts GWT's DevMode which is always a lot slower than compiled
JavaScript. You should not measure timings in DevMode. Compile your app to
Regarding hello world app running using separate compilation: can you
elaborate on that? Do you mean support for two distinct compilation units
within the same page?
Regards,Heiko
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are
There aren't really two concepts: you can mix and match generate-with and
replace-with for the same type, and/or switch from one to the other over time.
Actually, replace-with is only a shorthand for a generator returning a constant
value (of a class that already exists).
--
I don't think APT is good enough. Java8 has a compiler plugin API for
code-gen that might work. APT has limitations that make it problematic to
replace generators. Stephen Haberman brought this up at the GWT meetup.
On Fri, Aug 9, 2013 at 4:16 PM, Goktug Gokdogan gok...@google.com wrote:
I
On Fri, Aug 9, 2013 at 7:16 PM, Goktug Gokdogan gok...@google.com wrote:
I think in the long-run we should separate the two concepts that is being
tackled by GWT.create today.
First purpose is the class replacement, especially used by permutations. I
think this one should not have anything
2. IDE support: IDE can trigger codegen (esp. for debugging)
My experience with this has been pretty poor, and running GWT with -gen is
at least as useful.
Also, Super Dev Mode gives you access to all the generated code. You can
either use the browser's debugger with SourceMaps turned
On Sat, Aug 10, 2013 at 2:18 PM, Brian Slesinsky skybr...@google.comwrote:
2. IDE support: IDE can trigger codegen (esp. for debugging)
My experience with this has been pretty poor, and running GWT with -gen
is at least as useful.
Also, Super Dev Mode gives you access to all the
This reminds me a lot of Scala macros research. As you probably know, Scala
solves code-gen issues with experimental support for several kinds of
macros, distinguishing clearly between expression-level and type-level code
generation/rewriting.
APT covers only a fraction of type-level
I miss this line in my dagger example:
CoffeeApp coffeeApp = objectGraph.get(CoffeeApp.class);
El sábado, 10 de agosto de 2013 16:23:50 UTC-3, Andrés Testi escribió:
This reminds me a lot of Scala macros research. As you probably know,
Scala solves code-gen issues with experimental support
Now that I understand it (hopefully), I think Ray's proposal is a good way
to define new API's by writing Java wrappers that configure generated
objects at runtime. Adding parameters to GWT.create() calls seems somewhat
orthogonal as a way to pass arguments to generators at compile time.
As often
On Sat, Aug 10, 2013 at 4:42 PM, Brian Slesinsky skybr...@google.comwrote:
Now that I understand it (hopefully), I think Ray's proposal is a good way
to define new API's by writing Java wrappers that configure generated
objects at runtime. Adding parameters to GWT.create() calls seems somewhat
Hi Brian,
Our plan is to make Super Dev Mode compile faster.
Have you gotten to discovering what parts are the slow ones?
- Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups GWT
19 matches
Mail list logo
