Re: Any chance of an InterfaceGenerator overhaul to support GSS?

[Abraham Lin]

Good to hear! I've opened an issue for 
this: https://code.google.com/p/google-web-toolkit/issues/detail?id=9171

On Thursday, April 2, 2015 at 9:24:41 AM UTC-4, Julien Dramaix wrote:
>
> This is in my todo list and will be done for GWT 2.8 (where GSS will 
> become the default syntax). Feel free to open an issue in order to track 
> this.
>
> On Thursday, April 2, 2015 at 4:24:03 AM UTC+2, Abraham Lin wrote:
>>
>> The GWT distribution currently contains an InterfaceGenerator tool for 
>> generating CssResource interfaces from a CSS source file; however, this 
>> tool is still using the old Flute parser and thus does not support CSS3 
>> syntax.
>>
>> Is there any chance that this tool will be overhauled/ported to support 
>> GSS as part of GWT proper?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Any chance of an InterfaceGenerator overhaul to support GSS?

[Abraham Lin]

The GWT distribution currently contains an InterfaceGenerator tool for 
generating CssResource interfaces from a CSS source file; however, this 
tool is still using the old Flute parser and thus does not support CSS3 
syntax.

Is there any chance that this tool will be overhauled/ported to support GSS 
as part of GWT proper?

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: CssResource interface conflict?

[Abraham Lin]

I believe I came across this as well (see issue 
8251). 
I wasn't able to pinpoint the root cause as you did, but there's a test 
case attached to the issue that might be helpful.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

Re: Unusual (for me) GWT compile messages

[Abraham Lin]

Integer#compare(int, int) was added in Java 7, which isn't supported by GWT 
2.5.1.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Space between widgets in FlowPanel ?

[Abraham Lin]

What you want is the "margin" property, not the "padding" property.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to download a file from server without browser opening new window?

[Abraham Lin]

What you really want is 
#setHref: 
http://google-web-toolkit.googlecode.com/svn/javadoc/latest/com/google/gwt/user/client/ui/Anchor.html#setHref(java.lang.String)

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [POLL RESULTS] Maven project layout, what to "standardize"?

[Abraham Lin]

This is typically caused by incorrect project classpath settings (check the
includes/excludes for the resources folder). It's not clear whether m2e or
GPE is to blame here.

-Abraham


On Mon, Jan 28, 2013 at 4:02 AM, Olivier NOUGUIER <
olivier.nougu...@gmail.com> wrote:

> Hum
>   Sorry to say, that :
>
> On Fri, Nov 16, 2012 at 2:34 PM, Thomas Broyer  wrote:
>
>>
>> Poll results: option 3, aka src/main/resources + src/main/super.
>>
>> Bonus: it apparently works with the latest version of the GPE (wasn't the
>> case before, where it –basically– only looked into src/main/java)
>>
>> Is not true :(
> In fact, from a fresh project, the *.gwt.xml file are not detected if they
> lies in src/main/resources ...
> Once the Launch configuration exists the file can be moved from
> src/main/java to src/main/resources.
>
>>
>> On Tuesday, November 13, 2012 1:51:36 PM UTC+1, Thomas Broyer wrote:
>>>
>>> Hi all,
>>>
>>> As some of view may already know, I'm porting GWT to use Maven as the
>>> build system (instead of Ant). I'm also about to "reboot" GWT+Maven
>>> integration (more to come by the end of the week, stay tuned).
>>>
>>> As part of this effort, I'm wondering which project structure to use as
>>> the default, "standard" layout for GWT projects using Maven? I'm
>>> particularly looking for advice/preferences for GWT library projects (such
>>> as GWT itself, mgwt, Errai, GXT, etc.), not much for GWT applications (the
>>> one you run the GWT Compiler on).
>>>
>>>
>>> NOTE: this poll is cross-posted to the GWT and gwt-maven-plugin groups,
>>> please answer only once! (wherever you want)
>>>
>>>
>>> The question is about where to put files such as: GWT module descriptors
>>> (*.gwt.xml), GWT "processed resources" (*.ui.xml, etc.), and super-sources.
>>> It comes without saying (for me at least) that Java sources would go
>>> into src/main/java and "public resources" (i.e. the things within
>>> **/public/**, e.g. the CSS and image files from the themes) into
>>> src/main/resources, so the "everything" below only refers to those other
>>> files listed above.
>>> Remember I'm only interested in defining the "standard layout" for GWT *
>>> libraries*, and please think about them as *GWT-only* libraries, not
>>> the kind with server-side and client/server-shared code!
>>> Note that in any case, src/main/java is also added as a resource folder
>>> (packaged within the JAR)
>>>
>>> Here are the alternatives I thought about:
>>>
>>>1. everything in src/main/java
>>>super-sources in src/main/resources
>>>2. everything in src/main/resources
>>>3. everything in src/main/resources
>>>super-sources in src/main/super (or gwt-super, or some other name,
>>>let's discuss that later as I suspect it's a bikeshed)
>>>
>>> When casting your vote, do not hesitate to explain *why* you prefer
>>> that particular layout over the others, or why you don't like one of the
>>> proposed layouts. Also feel free to propose a fourth alternative.
>>>
>>  --
>> You received this message because you are subscribed to the Google Groups
>> "Codehaus Mojo gwt-maven-plugin Users" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/codehaus-mojo-gwt-maven-plugin-users/-/JXHDJbf3zW0J
>> .
>>
>> To post to this group, send email to
>> codehaus-mojo-gwt-maven-plugin-us...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> codehaus-mojo-gwt-maven-plugin-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en
>> .
>>
>
>
>
> --
> "Computers are useless. They can only give you answers."
> - Pablo Picasso -
>
> --
> You received this message because you are subscribed to the Google Groups
> "Codehaus Mojo gwt-maven-plugin Users" group.
> To post to this group, send email to
> codehaus-mojo-gwt-maven-plugin-us...@googlegroups.com.
> To unsubscribe from this group, send email to
> codehaus-mojo-gwt-maven-plugin-users+unsubscr...@googlegroups.com.
> Visit this group at
> http://groups.google.com/group/codehaus-mojo-gwt-maven-plugin-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: GWT/CSS text align problem

[Abraham Lin]

Have you tried using either of DockLayoutPanel or LayoutPanel? Since you're 
already using layout panels, it should be fairly straightforward to use 
absolute positioning to create three DIVs of approximately equal width. 
Then you can just set the text-align property for each DIV as necessary.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/FrYmcaupQiMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Tracking down an erroneous brace

[Abraham Lin]

Looks like there's an extra comma on line 20 (right before the opening 
brace). Not sure why the line number is off, but the column offset is 
correct.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/U38brj6hoUIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Code reuse in GWT from common Java projects

[Abraham Lin]

I think that Joerg's proposal is exactly what you're looking for, though 
what may not be immediately obvious is how the various components relate to 
one another. The basic idea is that myproject-componentN-client depends on 
myproject-componentN-shared and that myproject-componentN-server depends 
on myproject-componentN-shared as well. For multiple components (number 
them #1 and #2), you may also have myproject-component2-client depend on 
myproject-component1-client, myproject-component2-shared depend on 
myproject-component1-shared, and myproject-component2-server depend on 
myproject-component1-server.

Having multiple "server" modules for a given component is straightforward 
as well - just have them all depend on the "shared" module.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/JJMdSHdEfDEJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: [POLL] Maven project layout, what to "standardize"?

[Abraham Lin]

> This is option 3 then (you agreed that "It comes without saying (for me at 
> least) that Java sources would go into src/main/java", and I suppose that 
> by "public resources" you mean not only **/public/** but also  *.ui.xml and 
> the like)
>

Ah sorry, I had misread your definition of "everything" to include 
non-super sources as well. But yes, I think that all non-Java files (e.g. 
module descriptors, UiBinder templates, **/public/** resources) should go 
in src/main/resources.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/QpSSkwO7CHIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: [POLL] Maven project layout, what to "standardize"?

[Abraham Lin]

> It comes without saying (for me at least) that Java sources would go into 
> src/main/java and "public resources" (i.e. the things within **/public/**, 
> e.g. the CSS and image files from the themes) into src/main/resources
>

I agree with this.
 

> everything in src/main/java
> super-sources in src/main/resources
>
 
The major drawback to this is that putting everything in src/main/java 
makes it more difficult to re-use filtering configuration for 
maven-resources-plugin. Placing the super-sources in src/main/resources may 
also cause filter-related "surprises."
 

> everything in src/main/resources
>

 I suspect that this may cause problems/annoyances because 
project.build.sourceDirectory points to src/main/java by default. This also 
is subject to potential filtering issues.

everything in src/main/resources
> super-sources in src/main/super (or gwt-super, or some other name, let's 
> discuss that later as I suspect it's a bikeshed)


I like the idea of having the super-sources in a separate source directory. 
Objections to putting everything in src/main/resources are noted for option 
#2 above.
 

> Also feel free to propose a fourth alternative.
>

I'd propose keeping non-super sources in src/main/java, public resources in 
src/main/resources, and super-sources in src/main/super. As different as 
GWT projects may be from other "normal" Java projects, I think there's 
still value in keeping to convention if it's possible and sensible to do so.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/FHCWDOv2imkJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: RPC interface declares throws statement, server side implementation doesn't complain about not having it

[Abraham Lin]

This is specified by Java and is by design. The rationale is here: 
http://docs.oracle.com/javase/tutorial/essential/exceptions/runtime.html

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/VEqFojW83vIJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Security considerations for GWT applications

[Abraham Lin]

On Wednesday, October 24, 2012 5:41:06 AM UTC-4, Flying-w wrote:

> I am investigating security considerations around the user login for a GWT 
> application in respect of the following strategy:
>
>- User enters their id and password in a dialogue;
>- Client transmits the login request with the above details to the 
>server using RPC;
>- Server returns a token unique to the client.  The client stores this 
>in a cookie such that if they press F5 to reload the application, or 
>navigate away and come back, they do not need to login again (within a 
>timeout period);
>- On every request the client sends to the server, the token is 
>included in the payload of the request to authenticate the request;
>
> This sounds awfully similar to a session cookie - any reason why you can't 
just use that? If you want to persist identity across browser sessions, 
then you'd need a separate cookie, but that would generate additional 
security concerns.

>
>- Use SSL.  Any good guides about doing this with GWT?  Does SSL also 
>defeat the "Mallory" attacker that can also modify network data?
>
> Yes, use SSL/TLS. Configuration of SSL is primarily a hosting concern and 
doesn't really affect GWT per se, though there are some settings that you 
may want to specify in the server-side configuration (e.g. only transmit 
cookies over SSL).

If you're using SSL, the "Mallory"-style attacks require user intervention 
(i.e. accepting an untrusted SSL certificate), so you are somewhat "safe" 
in that regard.

>
>- Any non-SSL solutions?
>
> You could always write your own application-level encryption scheme, but 
this is likely to be much slower. Since you're already using HTTP, you 
might as well take advantage of the existing SSL facilities.

On Wednesday, October 24, 2012 2:38:51 PM UTC-4, Manuel Carrasco wrote:
>
> - You could compute and send the MD5 hash of the password instead of the 
> clear one if the server is storing the password in MD5
>
 
This doesn't really work against MITM attacks. As written, the proposal 
substitutes a password equivalent in place of the original password, which 
doesn't really provide any protection against unauthorized access to the 
system because intercepting the password equivalent would still be 
sufficient for access. It does protect the original password, though that's 
typically a lesser concern.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/wGJyLkMhP8EJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Cookie path and domain issue...

[Abraham Lin]

Use the 
ProxyPassReverseCookieDomain
 and 
ProxyPassReverseCookiePath
 directives 
in your httpd config. Depending on how your virtual hosts are configured, 
you may want to make use of the environment variable interpolation.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/eUmG35OSPTMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Cookie path and domain issue...

[Abraham Lin]

The path rewriting should be done by the proxy, not by your code. What are 
you using as the proxy?

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/ZrFfNsFcEDwJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: HTML without a DIV

[Abraham Lin]

One possibility is to replace the FlowPanel with an HTML widget, generate a 
SafeHtml instance containing your raw HTML, and then call the #setHTML 
method. You could also build the markup using the DOM API, though that will 
almost certainly be slower and more verbose.

GWT adds wrapper DIV/SPAN elements to widgets because that is the only way 
to ensure (mostly) consistent behavior in different contexts. It's a 
necessary trade-off for producing reusable components.

And in any case, the fact that your third-party library can't handle 
intermediate container elements makes it appear rather suspect - a simple 
call to element.getElementsByTagName would easily handle this case.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/T9IhLDNiPu0J.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: INHERITANCE FROM JAR FILE , DOESN'T WORK

[Abraham Lin]

Does your JAR file contain the source code for your library? The GWT 
compiler needs to have access to the source files, not just the compiled 
class files.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/0AjHUzCMjjkJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: super-source and eclipse

[Abraham Lin]

On Friday, October 5, 2012 1:46:54 PM UTC-4, Thomas Broyer wrote:

> It's not only about client vs. server, it also affects non-GWTTestCase 
> unit tests of your client code.
>
 
This doesn't seem right. Given that your client classes will be relying on 
the super-sourced logic at runtime, why shouldn't the tests utilize the 
same logic as well? There are almost certainly going to be slight 
differences between the original non-translatable classes and the 
super-sourced equivalents, so I'm not seeing why the tests would be 
structured to make use of the former when the fully-compiled code makes use 
of the latter. In the best case, the two have the exact same semantics. and 
it doesn't matter which one you use. But in the general case, the two are 
not quite the same, so it would seem to make more sense to depend on the 
version that will actually be in use at runtime.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/Je0QEXFI9loJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: super-source and eclipse

[Abraham Lin]

On Friday, October 5, 2012 10:47:33 AM UTC-4, Thomas Broyer wrote:

>
> Don't do that: Eclipse will then compile you super-source and you then 
> risk making your non-client code using those classes fail (unit-tests, 
> server-side, etc.)
>

Ah, that's true. I'm used to separating client and server code into 
separate projects, so this hadn't occurred to me.
 

> And if you want the "full power" of Eclipse for super-source classes, then 
> create another Eclipse project where you import the super-source folder as 
> a Source Folder (again, that's what GWT does: 
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/user/.classpath
>  vs. 
> http://code.google.com/p/google-web-toolkit/source/browse/trunk/eclipse/lang/.classpath
> )
>

Doesn't this lead to the same problem as adding the super-source folder 
directly as a source folder? If the fundamental problem is that client-side 
tests and server-side tests need different classpath configurations, then 
you would presumably need separate projects or separate testing 
configurations (with includes/excludes as appropriate).

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/SuC37bV3K5wJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: super-source and eclipse

[Abraham Lin]

Add the root of your super-source folder as a source folder (right-click 
the folder, open the "Build Path" submenu, and click "Use as Source 
Folder"). Eclipse should automatically make the necessary modifications to 
the parent source folder, but you might want to check to make sure.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/qqiCk1UtOBsJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Open new tab in dev mode with window.open

[Abraham Lin]

On Tuesday, September 11, 2012 3:54:55 PM UTC-4, Thomas Lefort wrote:
>
> This is my code for the anchor 
>
> AnchorElement anchor = 
> DOM.createAnchor().cast(); 
> anchor.setHref("#EISearchResultPlace:" + 
> result); 
> anchor.setTarget("_blank"); 
> clickAnchor(anchor); 
>
> public static native void clickAnchor(Element element)/*-{ 
> element.click(); 
> }-*/; 
>

In both Firefox and Internet Explorer, it looks like you have to attach the 
element to the document first (Chrome doesn't seem to care).

You should also note that windows opened programmatically in this fashion 
will generally be blocked by built-in popup blockers.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/ThChvSXUYSkJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: KeyCodes.KEY_ESCAPE

[Abraham Lin]

The keypress event tends to be handled inconsistently by different 
browsers/environments:  http://www.quirksmode.org/js/keys.html

As noted in the link above, you should probably stick with keyup or keydown 
events.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/OyDdpf5RpAoJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Ajax € (euro) character problem

[Abraham Lin]

I just re-read your original post, and I think the problem is that you're 
using utf8_decode on the server side. According to the 
documentation, 
utf8_decode converts a UTF-8 string into ISO-8859-1, which doesn't support 
the euro symbol. Have you tried removing that call? (You should probably 
specify the encoding on the client side anyway, as that's really the only 
way to authoritatively communicate the encoding to the server).

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/OZ4B5Zb9RQoJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: Ajax € (euro) character problem

[Abraham Lin]

You'll need to set the encoding as part of the "Content-Type" header:

builder.setHeader("Content-Type", "application/x-www-form-urlencoded; 
charset=UTF-8");


The default encoding is ISO-8859-1, which does not support the euro symbol 
(I believe the standard was established prior to the formation of the EU).

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/0iTSncPVd7wJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: fundamental problems with predictive layout

[Abraham Lin]

>
> the only empty DIV I see is the label, and it's empty because the label 
> does not contain text.
>

Right, and that's why it has zero height as you observed.
 

> Do you agree to the statement posted in this thread that the GWT's layout 
> panels should be used for the overall page layout (defining the main areas 
> of a page) and that the small layouts (widgets and so on) should be 
> positioned with CSS?
>

Generally, yes. Granted, the absolute positioning scheme isn't appropriate 
for every use case, but if your entire application is GWT-based, then 
that's the way to go.
 

> Maybe you misunderstood my posting: I also said that GWT compiles to HTML 
> and CSS. But it produces different compilations for different browsers. In 
> contrast, everything you put directly into the element attributes will 
> go unchanged into the client.
>

The different compilations exist to produce mostly-uniform behavior across 
browsers, but only to a certain extent. It is generally not possible to 
avoid having to write your own CSS and deal with the browser-specific 
quirks that come with it.
 

> However, even Google states that in strict mode many panels do not work as 
> expected, e. g. HorizontalPanel, which should be replaced by a FlowPanel 
> where all children should float to the left (which does'nt work in some 
> cases).
>

This is a difference in expectations. In this case, the FlowPanel approach 
is not a drop-in substitute; it does work if you ensure that the FlowPanel 
is wide enough to prevent wrapping of the children (and that the children 
are statically positioned, etc.). For HorizontalPanel specifically, there 
shouldn't be any reason why it wouldn't work properly in strict mode, 
though using tables for layout has been frowned upon in the web development 
world for quite some time now (whether that's justified is a whole 
different story).
 

> The goal was "predictive layout", but it seems to be more like "trial and 
> error", at least in some cases.
>

While I wouldn't necessarily consider it "trial and error," using CSS 
effectively certainly has a steep learning curve. Again, the "issue" is 
that GWT is a leaky abstraction - you still need to know how CSS works (and 
in some cases, what markup is being generated by GWT). If you have the 
necessary knowledge CSS knowledge, then the layout *is* predictable.

-Abraham

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/MkvL89zhCUAJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: fundamental problems with predictive layout

[Abraham Lin]

I think you're misunderstanding how GWT works. Everything written using GWT 
compiles down to HTML, CSS, and other "native" web technologies - there is 
no difference between panels (LayoutPanels or otherwise) and widgets as far 
as "mapping" goes.

What seems to be the issue here is that the abstraction provided by GWT can 
be rather leaky. If you don't understand what the generated code looks like 
and how it is rendered, then you will likely run into problems. For 
example, the HTML markup you posted previously contains an empty, 
(presumably) statically positioned DIV - this is rendered by the browser as 
an element with zero height. It's not a problem with GWT per se; if 
anything, the problem is that your expectations don't match those of the 
framework.

It's also worth noting that while GWT offers fairly reliable abstractions 
for some things (e.g. basic layout, scripted behaviors), it does not 
eliminate the need to understand how CSS influences presentation. What it 
does do is provide mechanisms for cleanly separating browser-specific 
requirements, so that you or someone else can do the hard work just once 
and have it available for re-use in the future.

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/Lmq_d16h2VQJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT Compilation Time Performance Improvement

[Abraham Lin]

>
> What could possibly help is to precompile the modules into *.gwtar files, 
> but it's something that's supposed to only be used by GWT itself (you'll 
> find such gwtar files in the gwt-user.jar) AFAIK. At least it's not 
> designed to build "libraries", as the gwtar files depend on the version of 
> GWT that produced them (IIUC).
>

I've found that pre-compiling gwtar files has a negligible impact on 
overall compilation time, as most of the processing time is spent during 
the CompilePerms phase. Granted, this is dependent on the project 
architecture, but it seems unlikely that this will be a silver bullet for 
reducing overall compilation time (at least in its current state).

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/RzBld5KNo6cJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: building a GWT project with fails due to dependency on GWT 2.4.0 (at least 2.5.0-rc1 required)

[Abraham Lin]

In sample/pom.xml, add the following after line 34 (after 
"gwt-maven-plugin"):

${gwtversion}

Then add the following between "" and "" (following line 
71 after the first step):




org.apache.maven.plugins
maven-war-plugin

false





These are problems with the POM and should be fixed in the original project.

-Abraham


On Friday, August 31, 2012 3:40:58 PM UTC-4, koma wrote:
>
> Hi Hilco,
>
> thx for the advice ...
>
> I am anything but a maven expert, this is a 3rd party project I am trying 
> to include.
>
> Can you give me some pointers on how to do that ?
> the pom is https://github.com/jDramaix/gwtchosen
>
> or a sample of a GWT maven project done right ?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/LYAwnYSJSEUJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: import common style rules?

[Abraham Lin]

Why don't you define a CSSResource with the shared rules and import it 
where needed? See  
https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#Imported_scopes
 (and 
possibly  
https://developers.google.com/web-toolkit/doc/latest/DevGuideClientBundle#Shared_scopes
 depending 
on your particular use case).

On Monday, July 16, 2012 3:23:43 AM UTC-4, Ed wrote:
>
> Might it be an idea if the @ClassName annotation allows for an array of 
> String value's (currently not possible)?
> This could solve the problems described above I think. Example:
>
> public interface WidgetStyle extends CssResource {
>  @ClassName({"Bla", "General"})
>  String bla(); {
> }
>

This should be equivalent to just adding multiple classes to the widget 
itself. 

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/AZGVVRu45pMJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Re: GWT offline

[Abraham Lin]

The following should work:

 site:developers.google.com/web-toolkit/


You can use the same construct in the general Google search engine.

-Abraham 

-- 
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/google-web-toolkit/-/Qk_Z2sp8SZ8J.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.