Re: Compile Error after switching to 2.6 in first compile run

[Jan Thewes]

I understand your points BUT one thing. If I compile my modules alone I 
don't get any compile error. So compiling every single module works. It has 
to do something with the order and caches. I just can't nail it down.
We're running a real real big GWT application here.
I'm close to go back to 2.5.1 because the compiles fail too often but not 
always...

-- 
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: Compile Error after switching to 2.6 in first compile run

[Boris Lenzinger]

May be the algorithm to compute the compilation order has changed. Can you
get the sequence of compilation in 2.5.1 and 2.6.0 so you can currently
hard code the build sequence (and continue to use 2.6). Then you can post a
bug report.


2014-02-19 9:04 GMT+01:00 Jan Thewes :

> I understand your points BUT one thing. If I compile my modules alone I
> don't get any compile error. So compiling every single module works. It has
> to do something with the order and caches. I just can't nail it down.
> We're running a real real big GWT application here.
> I'm close to go back to 2.5.1 because the compiles fail too often but not
> always...
>
> --
> 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.
>

-- 
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.

Safety of public helper methods in RemoteServiceServlet

[Matthew Wood]

I can't seem to track down the answer to this question. In GWT-RPC is any 
validation done to enforce that only methods in the RemoteService interface 
can be invoked? For example, if you had a public helper method in the 
RemoteServiceServlet that wasn't described in the interface could it be 
invoked by forging an RPC request?

I'm trying to get a handle on what is exactly exposed in a 
RemoteServiceServlet and what enforces that exposure. I'm assuming a 
malicious client directly accessing the server and bypassing a provided 
client.

I'd love to see the code that was responsible, too. I poked around 
com.google.gwt.user.server.rpc but could only find implementsInterface, 
which I don't think does what I'm asking.

-- 
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: Diagnose GWT DMP Plugin crashes on Chrome

[Anirban Chakravarty]

To fix the GWT DMP plugin crash, in your eclipse IDE , go under 
window->preferences
Select google
Make sure the latest app engine and Web toolkit are selected. In my case 
they are App engine - 1.8.2 , Web Toolkit 2.5.0

On Wednesday, January 25, 2012 6:39:47 PM UTC-5, JoseM wrote:
>
> We are having issues testing our application in Dev Mode on the Chrome 
> browser.  Whenever we run our application in Dev Mode we can hardly 
> use Chrome to test our application because the GWT DMP Plugin crashes 
> within a few minutes.  I can run the same application in Firefox 
> without the plugin crashing or having so much issues. 
>
> Is there a way us to diagnose why the plugin crashes so easily and so 
> often? When we compile the application and run it in deployed mode it 
> works fine in Chrome and we don't have so many issues.

-- 
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.

GWT + Eclipse + Existing Website

[brendentowey]

Hi all.  I'm new to GWT and its Eclipse plugin.  I was hoping to get some 
advice on how to approach making a small GWT app and integrating it into an 
existing Java EE website.

The first thing I noticed when I made my first GWT app, "FirstGWT", was the 
web application with the plugin used that name, /firstgwt, for the path to 
all of the generated JavaScript code.  So I was thinking that a longer path 
than just right off the web root would be appropriate in the long run, like 
/api/apps/firstgwt for example.  

Is there a way to change the path the plugin made?  Can I just copy the .js 
code to another directory/path on my websever and everything will just 
work, or the path /firstgwt embedded in the various scripts and other 
components?  What would recommend to meet the goal of a more flexible 
server side path (especially if the final path isn't known during 
development, for example)?

OK, next question is regarding the sever side stuff.  I assume I can place 
the GWT servlets in a jar/war file and place it in the /lib directory of 
the final war/ear file I deploy.  Is that true?  What files besides just 
the servlets should I include?  What does GWT need to configure itself, for 
example?

That's it for now, I think.  Hopefully soon I'll get a better grasp on how 
GWT fits into the larger picture of web development.  Thanks for helping 
out if you can.


-- 
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: Safety of public helper methods in RemoteServiceServlet

[Thomas Broyer]

RPC.decodeRequest resolves the method from the interface:

Method method = serviceIntf.getMethod(serviceMethodName, parameterTypes);

so only methods declared on the interface can be called.

On Wednesday, February 19, 2014 3:37:48 AM UTC+1, Matthew Wood wrote:
>
> I can't seem to track down the answer to this question. In GWT-RPC is any 
> validation done to enforce that only methods in the RemoteService interface 
> can be invoked? For example, if you had a public helper method in the 
> RemoteServiceServlet that wasn't described in the interface could it be 
> invoked by forging an RPC request?
>
> I'm trying to get a handle on what is exactly exposed in a 
> RemoteServiceServlet and what enforces that exposure. I'm assuming a 
> malicious client directly accessing the server and bypassing a provided 
> client.
>
> I'd love to see the code that was responsible, too. I poked around 
> com.google.gwt.user.server.rpc but could only find implementsInterface, 
> which I don't think does what I'm asking.
>

-- 
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: CssResource inheritance and avoiding rule repetition on injection, possibility of an @Require?

[Thomas Broyer]

On Tuesday, February 18, 2014 6:38:36 PM UTC+1, GWTter wrote:
>
> Hi all,
>
> Let me just go with an example right off the bat.
>
> Let's say I have the following:
>
> === Pseudocode ===
>
> SuperCssResource: This is injected onModuleLoad before anything else
> .genButton{
> color: black;
> }
>
> Widget1 consists of:
> --- css ---
> MyCssResource:
> .myButton{
> color: red;
> }
>
> --- html ---
> 
>
> Widget2 consists of:
> --- css ---
> XCssResource extends SuperCssResource:
> ... rules that use classes from SuperCssResource
>
> --- html ---
> ...elements
>
> My problem is that if I display Widget1 first and then display Widget2 
> then the button in Widget1 will have a color of black instead of red.
>
> I know that this is expected behavior (GWT will merge the stylesheets 
> together) since inheritance is basically the cssresource equivalent of CSS 
> @import 
>

Er, no.

Inheritance of CssResource interfaces only deals with that: inheriting 
methods. The actual CSS backing the resource is given by the @Source 
annotation on your ClientBundle method, and if you use the same CSS file 
for 2 different CssResource interfaces, the CSS will be duplicated, because 
obfuscation of the class names is based on the interface fully-qualified 
name: 
http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html#Scope (the 
order of the files in @Source will impact merging, just as they'd impact 
precedence in CSS).
 

> but I thought since this was GWT maybe there was a way to use inheritance 
> in the sense that the inherited stylesheet would only be injected if
> not injected already. Is this currently possible? or could it be done with 
> like a @Require annotation on the extending interface which would indicate
> that merging of the super stylesheet should not be done but rather a check 
> would be made to see if it already exists and if not to inject it.
> This would easily resolve the specificity overriding issue in the example 
> when it's not the desired behavior.
>
> I know I could also get around this by importing with a prefix, however I 
> still don't like the idea of essentially reinjecting the same styles.
>

If you don't want duplication, then you need a "shared scope" or "imported 
scope". In any case, that means you should only use the shared/imported 
class names in more complex selectors, you shouldn't change the styles 
attached to the selector by itself.

None of this applies if you use "@external" though, then it just works like 
standard CSS.

…and no, there's no way to say "please make sure that other stylesheet is 
injected when injecting that one", because, to begin with, it'd be hard to 
define what "that other stylesheet" is (the interface is not enough, given 
that the @Source is set on the ClientBundle method, so you'd have to say 
"this method from this ClientBundle interface", but it wouldn't even be 
enough: what if you composed that interface with another one and 
GWT.create()d the composed interface? should that @Require mean that GWT 
would do a GWT.create() of the lone interface, therefore duplicating 
efforts? –in all honesty, I haven't looked closely at the impact in terms 
of generated code and how it could be optimized, but it could limit future 
evolutions of ClientBundle in which code it generates, just to make sure 
that feature would still be correctly optimized–)
No really, given that ensureInjected() is a no-op if already injected, just 
make sure you call ensureInjected() on your "required" CssResource before 
calling ensureInjected() on the one that requires it, and document it 
thoroughly in the javadoc of the requiring ClientBundle method.

-- 
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: SubmitCompleteHandler not always called

[jaga]

Hi,

You might need to set the response type in servlet to txt/html. E.g.  
content-type 
= 'text/html'

jaga

On Tuesday, 18 February 2014 00:22:10 UTC, Bruce Grant wrote:
>
> I am interested in implementing the following using GWT...
>
>1. Create client-specific form variants in HTML, with shared/core 
>field definitions, but unique look and feel
>2. User logs in to front-end application, clicks a link and proper 
>form HTML is streamed from server (via RPC) 
>3. Html is added to a FormPanel
>4. User completes the HTML form and clicks submit 
>
> When I use submit with POST and a servlet, the form is submitted as 
> expected and my SubmitCompleteHandler is called. However, if there are 
> other GWT widgets on the page or I move the HTML to a popup then the 
> SubmitCompleteHandler does not get called. More specifically, if the 
> injected HTML is not put into a FormPanel that is defined before any other 
> widgets then the SubmitCompleteHandler does not work. I have read much 
> about SubmitCompleteHandler but couldn't find anything specific to this 
> issue.
>
> So, I would like to either find a way to get this scenario to work, OR, 
> find an alternative (e.g., serve up HTML forms in the same way, but extract 
> data from HTML fragment client side [how?] and then submit to server via 
> RPC).
>
> Any ideas/thoughts are very much appreciated.
>
> Many Thanks,
> Bruce. 
>
>
>

-- 
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: Safety of public helper methods in RemoteServiceServlet

[Matthew Wood]

That's exactly what I was looking for. Thank you!

On Wednesday, February 19, 2014 3:38:05 AM UTC-6, Thomas Broyer wrote:
>
> RPC.decodeRequest resolves the method from the interface:
>
> Method method = serviceIntf.getMethod(serviceMethodName, parameterTypes);
>
> so only methods declared on the interface can be called.
>
> On Wednesday, February 19, 2014 3:37:48 AM UTC+1, Matthew Wood wrote:
>>
>> I can't seem to track down the answer to this question. In GWT-RPC is any 
>> validation done to enforce that only methods in the RemoteService interface 
>> can be invoked? For example, if you had a public helper method in the 
>> RemoteServiceServlet that wasn't described in the interface could it be 
>> invoked by forging an RPC request?
>>
>> I'm trying to get a handle on what is exactly exposed in a 
>> RemoteServiceServlet and what enforces that exposure. I'm assuming a 
>> malicious client directly accessing the server and bypassing a provided 
>> client.
>>
>> I'd love to see the code that was responsible, too. I poked around 
>> com.google.gwt.user.server.rpc but could only find implementsInterface, 
>> which I don't think does what I'm asking.
>>
>

-- 
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: SubmitCompleteHandler not always called

[Bruce Grant]

Thanks Jaga,

I am setting the content-type response to text/html on the servlet 
response. The issue occurs when the form is moved in the uibinder and other 
GWT widgets are defined before the form.

Cheers,
Bruce.

On Wednesday, 19 February 2014 09:54:36 UTC-5, jaga wrote:
>
> Hi,
>
> You might need to set the response type in servlet to txt/html. E.g.  
> content-type 
> = 'text/html'
>
> jaga
>
> On Tuesday, 18 February 2014 00:22:10 UTC, Bruce Grant wrote:
>>
>> I am interested in implementing the following using GWT...
>>
>>1. Create client-specific form variants in HTML, with shared/core 
>>field definitions, but unique look and feel
>>2. User logs in to front-end application, clicks a link and proper 
>>form HTML is streamed from server (via RPC) 
>>3. Html is added to a FormPanel
>>4. User completes the HTML form and clicks submit 
>>
>> When I use submit with POST and a servlet, the form is submitted as 
>> expected and my SubmitCompleteHandler is called. However, if there are 
>> other GWT widgets on the page or I move the HTML to a popup then the 
>> SubmitCompleteHandler does not get called. More specifically, if the 
>> injected HTML is not put into a FormPanel that is defined before any other 
>> widgets then the SubmitCompleteHandler does not work. I have read much 
>> about SubmitCompleteHandler but couldn't find anything specific to this 
>> issue.
>>
>> So, I would like to either find a way to get this scenario to work, OR, 
>> find an alternative (e.g., serve up HTML forms in the same way, but extract 
>> data from HTML fragment client side [how?] and then submit to server via 
>> RPC).
>>
>> Any ideas/thoughts are very much appreciated.
>>
>> Many Thanks,
>> Bruce. 
>>
>>
>>

-- 
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: SubmitCompleteHandler not always called

[Jens]

Do you do any strange things with your HTML  tag? FormPanel creates a 
hidden IFrame which loads the server response from your form submit. If 
this IFrame is removed from the DOM before the server response is loaded 
into that IFrame then your SubmitCompleteHandler will not be called.

This hidden IFrame will automatically be removed from the DOM if your 
FormPanel gets detached from the DOM. For example if your FormPanel is 
inside a PopupPanel and that PopupPanel closes before the server response 
is loaded then your SubmitCompleteHandler will not be called.

Other than that FormPanel just works. How does your non-working code look 
like?

-- J.


-- 
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.

Chrome Touch Emulation and GWT

[Alexander Zbiek]

Hi all,
hope it is not wrong to post a question here.

I have a problem with touch events when emulated via the Chrome Emulation. 
I have a simple Canvas with an added Touch Handler:

 final Canvas ca=Canvas.createIfSupported();
ca.setCoordinateSpaceWidth(wiCo);
ca.setCoordinateSpaceHeight(wiHe);
//ca.sinkEvents(Event.TOUCHEVENTS);
ca.sinkEvents(Event.ONTOUCHSTART);




ca.addTouchStartHandler(new TouchStartHandler() {
 @Override
 public void onTouchStart(TouchStartEvent event) {
 // TODO Auto-generated method stub
 Touch t=event.getTargetTouches().get(0);
 ca.getContext2d().setStrokeStyle("#fff");
 ca.getContext2d().clearRect(0, 0, 800, 200);
 ca.getContext2d().setStrokeStyle("#000");
 ca.getContext2d().strokeText("Move "+(t.getPageX()-ca.getAbsoluteLeft())+
","+(t.getPageY()-ca.getAbsoluteTop()),10,60);
 consoleLog("Touch move ");
 }
 });


It works perfect on my Nexus7 but it doesnt work on my chrome when 
emulating Nexus7 and touches. Other Touch web apps (nativ JavaScript ? ) 
work in Emulation mode. But my (working) GWT app doesnt react to the 
(emulated) touch events. :(

Any experiences with it?

Many thanks in advance
 alex

-- 
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: Development Mode will not be supported in Firefox 27+

[Jeff Evans]

On Tuesday, February 18, 2014 4:30:50 AM UTC-5, Aleksander Gralak wrote:
>
> That is pretty bad information for all GWT developers. 
> For now I can stick with FF 24.2, however in the future we need to develop 
> on the most up to date browsers. 
>
> When do you estimate Super Dev Mode will be production ready? If it is 
> more then 6 months then we should think of some workaround. Is is possible 
> to do a custom build of FF with all necessery symbols exported? According to
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731
>
> they have switched it off. But if someone (sorry I am not C++ developer so 
> I will not do it myself) can build GWT development version with those 
> symbols. Then we would be able to do development for several more months on 
> the latest browser and wait till Super Dev Mode if fully functional.
>
 
Can someone clarify what is meant by "fully functional" for Super dev mode? 
 In my view, debugging the client-side GWT code in the IDE debugger, 
alongside server-side Java code, is the "killer feature."  I can't believe 
anyone would ever consider in-browser Javascript debugging to be an 
acceptable replacement.  Or perhaps I'm missing something?

-- 
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: Development Mode will not be supported in Firefox 27+

[Brian Slesinsky]

Super Dev Mode works and we have many teams that use it. The Chrome
debugger is quite good and I recommend learning it well; anyone working on
web apps will benefit from knowing this tool. For other browsers, adding a
GWT.debugger() call to the Java code and recompiling is an easy way to stop
in the right place. I discussed other workarounds in my GWT.create talk [1].

It's an unfortunate transition and this experience is not as smooth as it
could be yet, but that's where we are.

- Brian

[1]
https://docs.google.com/a/google.com/presentation/d/1DTWZ_06dQsTPhinIwzHSdoPMndRr92wpZoZWicK97YQ/edit?forcehl=1&hl=en#s

On Wed, Feb 19, 2014 at 8:37 AM, Jeff Evans  wrote:

> On Tuesday, February 18, 2014 4:30:50 AM UTC-5, Aleksander Gralak wrote:
>>
>> That is pretty bad information for all GWT developers.
>> For now I can stick with FF 24.2, however in the future we need to
>> develop on the most up to date browsers.
>>
>> When do you estimate Super Dev Mode will be production ready? If it is
>> more then 6 months then we should think of some workaround. Is is possible
>> to do a custom build of FF with all necessery symbols exported? According to
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=920731
>>
>> they have switched it off. But if someone (sorry I am not C++ developer
>> so I will not do it myself) can build GWT development version with those
>> symbols. Then we would be able to do development for several more months on
>> the latest browser and wait till Super Dev Mode if fully functional.
>>
>
> Can someone clarify what is meant by "fully functional" for Super dev
> mode?  In my view, debugging the client-side GWT code in the IDE debugger,
> alongside server-side Java code, is the "killer feature."  I can't believe
> anyone would ever consider in-browser Javascript debugging to be an
> acceptable replacement.  Or perhaps I'm missing something?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Google Web Toolkit" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/google-web-toolkit/QSEjbhhHB4g/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
>

-- 
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.

Getting widgets from a DockLayoutPanel

[Blake McBride]

Greetings,

I have a DockLayoutPanel that I would like to get the Widgets that are in
it.  I'm looking for something like:

DocLayoutPanel panel;

Widget east = panel.getEast();
Widget center = panel.getCenter();
Widget south = panel.getSouth();

Is there anywayI can do this?

Thanks.

Blake McBride

-- 
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: Getting widgets from a DockLayoutPanel

[Jens]

You can iterate through all child widgets using getWidgetCount() and 
getWidget(int). For each widget you can call getWidgetDirection(widget) to 
get its position inside the DockLayoutPanel.

-- J.

-- 
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: Development Mode will not be supported in Firefox 27+

[Jeff Evans]

On Wednesday, February 19, 2014 1:03:15 PM UTC-5, Brian Slesinsky wrote:
>
> Super Dev Mode works and we have many teams that use it. The Chrome 
> debugger is quite good and I recommend learning it well; anyone working on 
> web apps will benefit from knowing this tool. For other browsers, adding a 
> GWT.debugger() call to the Java code and recompiling is an easy way to stop 
> in the right place. I discussed other workarounds in my GWT.create talk [1].
>
> It's an unfortunate transition and this experience is not as smooth as it 
> could be yet, but that's where we are.
>
> - Brian
>
> [1] 
> https://docs.google.com/a/google.com/presentation/d/1DTWZ_06dQsTPhinIwzHSdoPMndRr92wpZoZWicK97YQ/edit?forcehl=1&hl=en#s
>

Thanks, this presentation looks useful.
 

-- 
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: Development Mode will not be supported in Firefox 27+

[Ed Bras]

>  The Chrome debugger is quite good and I recommend learning it well;
It depends on your project. I been down this road, tried it several times
with several projects (few months ago last one).
Currently the Super Dev mode is "Hello World ready", but not "Enterprise
ready"

With new projects, I like to start with Super dev mode, but when it becomes
bigger... I am forced to jump back to FF/Chrome plugin usage.

Using it with bigger code base makes it slow and a code puzzle in chrome
debug.
For bigger projects, Chrome debugger should offer more IDE features that
make debugging easy and friendly, just like we are used to using IDE tools
like Eclipse.
Of course this will change, and I hope this will be soon..

-- 
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: setWidgetSize on DockLayoutPanel does not effectively seem to update anything

[Tom]

i am guessing DockLayoutPanel got fixed size, u can use SplitLayoutPanel, & 
i am sure u can set Size for Splitlayoutpanel.

On Friday, February 14, 2014 9:30:44 AM UTC+11, Thomas Rodenhausen wrote:
>
> I use a DockLayoutPanel using UIBinder like this:
>
>  
>  
> ...
>  
>  
>   
>   ...
>
> 
> 
>  
> 
> 
>
> At some point I want to set the size of the north widget to 100px only.
> I tried dockLayoutPanel.setWidgetSize(northPanel, 100), but it does not 
> work: 
> - When I debug everything looks ok, the doLayout() of DockLayoutPanel 
> seems to be processed correctly, looking at the top and bottom values that 
> are set on the layers of the northPanel and centerPanel. 
> - However, in the browser, it ends up staying the same when I look at the 
> produced HTML + CSS. 
> - I tried to manually call animate() and forceLayout() without a 
> difference.
>
> Any ideas why that could be?
>
>

-- 
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.

Making GWT pull *.js from a non-standard location

[Alexey Panteleev]

Hello,

 I am trying to serve my GWT client side as a static resource in Salesforce 
platform.
I am getting the error "you may have to recompile your module" which I 
think points to the fact that the deferred.js files can't be found by the 
bootstrap process.
The main page is dinamically generated and ends up loading the initial 
script using a custom path (plus the loading is from a ZIP archive)

Re: Getting widgets from a DockLayoutPanel

[Blake McBride]

That did it.  Thanks!


On Wed, Feb 19, 2014 at 1:09 PM, Jens  wrote:

> You can iterate through all child widgets using getWidgetCount() and
> getWidget(int). For each widget you can call getWidgetDirection(widget) to
> get its position inside the DockLayoutPanel.
>
> -- J.
>
> --
> 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.
>

-- 
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.

Laying out a LayoutPanel

[Blake McBride]

Greetings,

I am trying to layout four widgets on a LayoutPanel.  Each of the four take
up 50% of the width.  The bottom two are fixed size (30 pt).  The top two
should take up the remaining height.  None of the widgets should overlap.
 Auto-resize on browser resize is desired.  The closest I've gotten is:

Widget leftBottom = ...;
Widget leftTop = ...;

Widget rightBottom = ...;
Widget rightTop = ...;

LayoutPanel layout = new LayoutPanel();
layout.add(leftTop);
layout.setWidgetLeftWidth(leftTop, 0, Style.Unit.PCT, 50,
Style.Unit.PCT);
layout.setWidgetBottomHeight(leftTop, 33, Style.Unit.PT, 100,
Style.Unit.PCT);

layout.add(rightTop);
layout.setWidgetRightWidth(rightTop, 0, Style.Unit.PCT, 50,
Style.Unit.PCT);
layout.setWidgetBottomHeight(rightTop, 33, Style.Unit.PT, 100,
Style.Unit.PCT);

layout.add(leftBottom);
layout.setWidgetLeftWidth(leftBottom, 0, Style.Unit.PCT, 50,
Style.Unit.PCT);
layout.setWidgetBottomHeight(leftBottom, 5, Style.Unit.PT, 28,
Style.Unit.PT);

layout.add(rightBottom);
layout.setWidgetRightWidth(rightBottom, 0, Style.Unit.PCT, 50,
Style.Unit.PCT);
layout.setWidgetBottomHeight(rightBottom, 5, Style.Unit.PT, 28,
Style.Unit.PT);

It comes close to correct except that part of the top two are cut off.  I
think this is because I have them at 100% but not starting at the bottom.
 I don't know how to tell it to, in essence, reserve some space at the
bottom and take up the rest of the space.

Any value I could use in the hight parameter of the top two would only be
accurate for one browser size so I can use a fixed measurement or a fixed
percent.  I need a way of saying start x distance from the bottom and use
the rest of the vertical space.

I have spent some time on this.  Some help would be greatly appreciated.

Blake McBride

-- 
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.

Using Cells for 2D representation

[Jambi]

Hey there,

is it possible to define a 2D cell list (->grid) which is based on the cell 
paradigm to utilize functionality like paging etc? Basically I want to have 
a grid based representation like for example pinterest without having to 
rewrite functionality already given with cells.

Cheers,

Michael 

-- 
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: CssResource inheritance and avoiding rule repetition on injection, possibility of an @Require?

[GWTter]

On Wednesday, February 19, 2014 10:59:51 AM UTC+1, Thomas Broyer wrote:
>
>
>
> On Tuesday, February 18, 2014 6:38:36 PM UTC+1, GWTter wrote:
>>
>> Hi all,
>>
>> Let me just go with an example right off the bat.
>>
>> Let's say I have the following:
>>
>> === Pseudocode ===
>>
>> SuperCssResource: This is injected onModuleLoad before anything else
>> .genButton{
>> color: black;
>> }
>>
>> Widget1 consists of:
>> --- css ---
>> MyCssResource:
>> .myButton{
>> color: red;
>> }
>>
>> --- html ---
>> 
>>
>> Widget2 consists of:
>> --- css ---
>> XCssResource extends SuperCssResource:
>> ... rules that use classes from SuperCssResource
>>
>> --- html ---
>> ...elements
>>
>> My problem is that if I display Widget1 first and then display Widget2 
>> then the button in Widget1 will have a color of black instead of red.
>>
>> I know that this is expected behavior (GWT will merge the stylesheets 
>> together) since inheritance is basically the cssresource equivalent of CSS 
>> @import 
>>
>
> Er, no.
>
> Inheritance of CssResource interfaces only deals with that: inheriting 
> methods. The actual CSS backing the resource is given by the @Source 
> annotation on your ClientBundle method, and if you use the same CSS file 
> for 2 different CssResource interfaces, the CSS will be duplicated, because 
> obfuscation of the class names is based on the interface fully-qualified 
> name: http://www.gwtproject.org/doc/latest/DevGuideClientBundle.html#Scope 
> (the 
> order of the files in @Source will impact merging, just as they'd impact 
> precedence in CSS).
>

Hi Thomas,

I guess I should have specified that it is inheritance along with 
specifying the source css that for all intents and purposes acts like CSS 
@import. I know that GWT will error if you extend the super resource and 
don't include it's source to match the classes, unless you're 
reimplementing them in the extending css resource which is not what I'm 
after and not the best idea IMHO. 

>  
>
>> but I thought since this was GWT maybe there was a way to use inheritance 
>> in the sense that the inherited stylesheet would only be injected if
>> not injected already. Is this currently possible? or could it be done 
>> with like a @Require annotation on the extending interface which would 
>> indicate
>> that merging of the super stylesheet should not be done but rather a 
>> check would be made to see if it already exists and if not to inject it.
>> This would easily resolve the specificity overriding issue in the example 
>> when it's not the desired behavior.
>>
>> I know I could also get around this by importing with a prefix, however I 
>> still don't like the idea of essentially reinjecting the same styles.
>>
>
> If you don't want duplication, then you need a "shared scope" or "imported 
> scope". In any case, that means you should only use the shared/imported 
> class names in more complex selectors, you shouldn't change the styles 
> attached to the selector by itself.
>
> None of this applies if you use "@external" though, then it just works 
> like standard CSS.
>

I know, like you mentioned, that I could avoid the precedence override by 
importing with prefix for example. And my use case is only to increase 
specificity on the extending css resource, definitely not to change the 
super's rule def by redefining the super selector in the extending 
resource. But I'm not thrilled with essentially reinjecting all the same 
rules with just different prefixes and @external does really fit my need as 
I don't want to forgo the obfuscation. 

>
> …and no, there's no way to say "please make sure that other stylesheet is 
> injected when injecting that one", because, to begin with, it'd be hard to 
> define what "that other stylesheet" is (the interface is not enough, given 
> that the @Source is set on the ClientBundle method, so you'd have to say 
> "this method from this ClientBundle interface", but it wouldn't even be 
> enough: what if you composed that interface with another one and 
> GWT.create()d the composed interface? should that @Require mean that GWT 
> would do a GWT.create() of the lone interface, therefore duplicating 
> efforts? –in all honesty, I haven't looked closely at the impact in terms 
> of generated code and how it could be optimized, but it could limit future 
> evolutions of ClientBundle in which code it generates, just to make sure 
> that feature would still be correctly optimized–)
>

Originally I did think that the interface would be enough but as you 
pointed out you can technically use another source css to attach to the 
interface when defining it in the Clientbundle, wouldn't necessarily always 
be the same one. I only thought of what I think you alluded to which would 
have been to specify the clientbundle such as in the 
@Required(MyClientbundle). In that composed case you mention isn't that 
what's currently happening? From what I can see in the generated css, the 
exte

Re: Laying out a LayoutPanel

[Tom]

don't use LayoutPanel but instead using DockLayoutPanel or SplitLayoutPanel 
& u can put them in East West, North, South easily & meet all ur 
requirements (such as widgets taking up all spaces & autorize when browser 
resizing). Your MainPresenter must use a panel that has word "Layout" such 
as LayoutPanel. 

On Thursday, February 20, 2014 9:31:19 AM UTC+11, Blake wrote:
>
> Greetings,
>
> I am trying to layout four widgets on a LayoutPanel.  Each of the four 
> take up 50% of the width.  The bottom two are fixed size (30 pt).  The top 
> two should take up the remaining height.  None of the widgets should 
> overlap.  Auto-resize on browser resize is desired.  The closest I've 
> gotten is:
>
> Widget leftBottom = ...;
> Widget leftTop = ...;
>
> Widget rightBottom = ...;
> Widget rightTop = ...;
>
> LayoutPanel layout = new LayoutPanel();
> layout.add(leftTop);
> layout.setWidgetLeftWidth(leftTop, 0, Style.Unit.PCT, 50, 
> Style.Unit.PCT);
> layout.setWidgetBottomHeight(leftTop, 33, Style.Unit.PT, 100, 
> Style.Unit.PCT);
>
> layout.add(rightTop);
> layout.setWidgetRightWidth(rightTop, 0, Style.Unit.PCT, 50, 
> Style.Unit.PCT);
> layout.setWidgetBottomHeight(rightTop, 33, Style.Unit.PT, 100, 
> Style.Unit.PCT);
>
> layout.add(leftBottom);
> layout.setWidgetLeftWidth(leftBottom, 0, Style.Unit.PCT, 50, 
> Style.Unit.PCT);
> layout.setWidgetBottomHeight(leftBottom, 5, Style.Unit.PT, 28, 
> Style.Unit.PT);
>
> layout.add(rightBottom);
> layout.setWidgetRightWidth(rightBottom, 0, Style.Unit.PCT, 50, 
> Style.Unit.PCT);
> layout.setWidgetBottomHeight(rightBottom, 5, Style.Unit.PT, 28, 
> Style.Unit.PT);
>
> It comes close to correct except that part of the top two are cut off.  I 
> think this is because I have them at 100% but not starting at the bottom. 
>  I don't know how to tell it to, in essence, reserve some space at the 
> bottom and take up the rest of the space.
>
> Any value I could use in the hight parameter of the top two would only be 
> accurate for one browser size so I can use a fixed measurement or a fixed 
> percent.  I need a way of saying start x distance from the bottom and use 
> the rest of the vertical space.
>
> I have spent some time on this.  Some help would be greatly appreciated.
>
> Blake McBride
>
>
>

-- 
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: Using Cells for 2D representation

[Jens]

Give your CellList a width of 100% and your cells a fixed width along with 
display:inline-block.

Doing so using the GWT showcase results in:



Alternatively you can use CellWidget to wrap your cell in a widget and then 
use it in the widget land.

-- J.

-- 
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: Laying out a LayoutPanel

[Jens]

Use setWidgetTopBottom() for the upper layers:


LayoutPanel layout = new LayoutPanel();
layout.add(leftTop);
layout.setWidgetLeftWidth(leftTop, 0, Style.Unit.PCT, 50, 
Style.Unit.PCT);
layout.setWidgetTopBottom(leftTop, 0, 
Style.Unit.PCT, 
30, Style.Unit.PT);

layout.add(rightTop);
layout.setWidgetRightWidth(rightTop, 0, Style.Unit.PCT, 50, 
Style.Unit.PCT);
layout.setWidgetTopBottom(rightTop, 0, 
Style.Unit.PCT, 
30, Style.Unit.PT);

layout.add(leftBottom);
layout.setWidgetLeftWidth(leftBottom, 0, Style.Unit.PCT, 50, 
Style.Unit.PCT);
layout.setWidgetBottomHeight(leftBottom, 0, 
Style.Unit.PCT, 
30, Style.Unit.P T);

layout.add(rightBottom);
layout.setWidgetRightWidth(rightBottom, 0, Style.Unit.PCT, 50, 
Style.Unit.PCT);
layout.setWidgetBottomHeight(rightBottom, 0, 
Style.Unit.PCT, 
30, Style.Unit.PT );


-- J.

-- 
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.

gwt compilation issue

[fedex]

For my current Gwt project when I compile the project it creates  web-inf 
folder outside the war folder. 

Initially While working on project I accidentally deleted war folder and I 
kind of setup the folder manually by copying the files from my backup 
folder. I am not sure if this is the reason for it..if yes what I am 
suppose to do.

-- 
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.