Re: Best approach from consuming REST(Jetty) webservice

2014-07-10 Thread Subhrajyoti Moitra
+1 for Errai.


On Thu, Jul 10, 2014 at 6:11 AM, Slava Pankov pank...@gmail.com wrote:

 Or use Errai JAX-RS
 https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS

 On Tuesday, July 8, 2014 7:12:06 AM UTC-7, Thomas Broyer wrote:



 On Tuesday, July 8, 2014 10:11:11 AM UTC+2, Santhosh Thadaka wrote:

 I have my backend with EJB and REST webservice and I want to consume the
 REST service with GWT as a front end can any one suggest with which is the
 best approach

 RPC
 RequestFactory
 RequestBuilder

 and I am not allowed to use any external api's. Please let me know what
 all should be taken care.


 GWT-RPC is an RPC protocol and API, and RequestFactory is a protocol too.

 If you want to consume REST services, you'll have to use either
 RequestBuilder or XMLHttpRequest (the former wraps the latter).
 If the data you exchange is JSON, then you can either use JsonUtils and
 overlay types (unfortunately only works for parsing for now –stringify is
 being added as I write–, but you can defer to JSONObject for
 serialization), JSONParser and friends, or AutoBeans.


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


-- 
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: Making browser save userneme password

2014-07-10 Thread Vassilis Virvilis
Thanks for the insightful post.

I have noticed something similar for chrome. While  remembering
login/password was working for firefox/IE it was not working for chrome
until a reload... It didn't cross my mind to programmatically cause a
reload...

   Vassilis


On Thu, Jul 10, 2014 at 1:48 AM, Blake McBride blake1...@gmail.com wrote:

 After a great deal of work, I finally have the whole browser-save-password
 code working on all browsers I can find (Chrome, IE, Firefox, Safari).  The
 code graciously provided by Saumar Hajjar in this thread does work.  You
 do, however, have to understand it in order to use it in your application.
  Given the state of HTML and browser technology, as well as the various
 specific browsers, this code is incredibly fragile and sequence dependent.
  It took me many days of debugging and trial-and-error coding to get it all
 working.  Now that it does work and I have some degree of understanding, I
 thought I would share some of the important points I discovered.  I hope
 this can be helpful to others.  I apologize in advance to those of you who
 find my observations obvious.

 Notice the line that has Window.Location.reload().  That critical line
 makes the whole thing work differently than anything you would have
 expected.  That line causes the whole page to reload from scratch losing
 all state information (including JavaScript variables, GWT instance and
 static variables, etc.) _except_ session data. You will notice that his
 backend code utilizes session data in order to keep track of the fact that
 he'd been there before (the user logged in).  This is the reason the first
 thing he has to do is call a backend service - to find out which state he
 is in (user logged in or not).  The system must re-load like this
 (according to him) in order for all browsers to execute their save-password
 operation.  Password saving happens at that reload point.

 Interestingly, his note states that the reload call is only necessary for
 Chrome.  Unfortunately, that one line dictates most of the architecture.
  In other words, if that line wasn't required, a far simpler approach could
 be used.

 As has been stated all over the place, the browser will only save the
 password if the password stuff is in the original HTML file - not GWT added
 controls.  This means that you will likely want to make the login HTML
 disappear after they log-in, and re-appear when they log out.  I did that
 by wrapping the whole HTML body in a div like this:

 div class=login-page id=login-page style=display: none; 
  /div

 I could then control its visibility with:

 private void hideLoginPage() {
 RootPanel.get(login-page).setVisible(false);
 }

 private void showLoginPage() {
 RootPanel.get(login-page).setVisible(true);
 }

 private void reloadLoginPage() {
 Window.Location.reload();
 }

 In my case, I set style=display: none; on the div to prevent it from
 showing at first.  Something I needed.  If you want to show it right away,
 just remove that.  Importantly, I discovered that showLoginPage() can only
 be called _after_ all of the calls to the various wrap() methods have been
 called.

 Another thing I noticed, my call to reloadLoginPage() (in order to get the
 browser to save the password) only worked in response to a backend call -
 as part of the response handler as he does below.  During testing, if I
 eliminated the backend call, the reloadLoginPage() would not cause the
 browser to save the password.

 This is all I can think of.  I hope it is helpful.

 Blake McBride





 On Mon, Jun 9, 2014 at 12:39 AM, Saumar Hajjar sau...@gmail.com wrote:

 Working example
 *PleaseSaveMyPassword.html:*
 !doctype html
 html
   head
 meta http-equiv=content-type content=text/html; charset=UTF-8
 titlePlease Save My Password/title
 script type=text/javascript language=javascript
 src=pleasesavemypassword/pleasesavemypassword.nocache.js/script
 style
 h1 {font-size: 2em; font-weight: bold; color: #77; margin: 40px 0px
 70px; text-align: center;}
 #gwt, table {width: 100%;}
  .loginPanel {width: 300px; margin: 0 auto; border: 1px solid #ccc;
 border-radius: 5px;}
 input {width: 200px; float: right;}
  button {width: 80px; float: right;}
 .loggedInPanel {width: 300px; margin: 0 auto; font-size: 1.5em;}
 .gwt-HTML {float: left;}
  a {float: right;}
 /style
   /head
   body
 h1Please Save My Password/h1
 div id=gwt/div
 div id=login style=display: none;
 form id=login_form action=javascript:;
  input type=text name=username id=login_username /
 input type=password name=password id=login_password /
  button type=submit id=login_submit/button
 /form
 /div
   /body
 /html

 *PleaseSaveMyPassword.java:*
 package com.sh.pleasesavemypassword.client;

 import com.google.gwt.core.client.EntryPoint;
 import com.google.gwt.core.client.GWT;
 import com.google.gwt.event.dom.client.ClickEvent;
 import com.google.gwt.event.dom.client.ClickHandler;

Overlay Instruction

2014-07-10 Thread iya
Is there GWT library that creates overlay instruction similar to Chardin.js 
(http://heelhook.github.io/chardin.js/) for jQuery?

-- 
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: You have to try : Putnami Web Toolkit your next GWT Framework.

2014-07-10 Thread Théophane Charbonnier
Hello Everybody !

I'm pleased to announce you that the Putnami Team as released a 
step-by-step tutorial in order to create a PWT based application from 
scratch, guiding you between the powerful features of PWT

We've created a Github repo 
https://github.com/Putnami/putnami-pwt-tutorial hosting the code 
associated to the tutorial.
Go to the project's wiki 
https://github.com/Putnami/putnami-pwt-tutorial/wiki to read the tutorial 
and don't hesitate to send us some feedback.

If you need more tutorials or if you have some questions about them, don't 
hesitate to use this thread 
https://groups.google.com/forum/#!topic/putnami-web-toolkit/YIfAoIHijdo in 
our  Google group 
https://groups.google.com/forum/#!forum/putnami-web-toolkit!

Regards,
@PutnamiTeam

Le vendredi 27 juin 2014 11:47:16 UTC+2, Fabien Dumay a écrit :

 Hi Eddy,

 Thank you for the congrats. 
 We know that it still an amount of work around the documentation stuff 
 (Completeness, Typos, Javadoc). The framework is young and we keep working 
 hard every day to improve it. 
 We could focus our efforts on right things, simply with feedback on good 
 but mainly on wrong or unclear things. 
 What kind of documentation is missing? (Everything of course but as we are 
 only two full time worker we have to sort them and go step by step)   
- Complete tutorial (video or not?). 
   - More detailed examples. 
   - Javadoc 
   - Overviews of the frameworks and the features. 
   - Other ... 
  
 We also are sorry for the low level of our English on the current 
 documentation. But we did not practiced for a while. Any help is welcome. 

 Concerning the forum, we have created a dedicated group to exchange around 
 PWT. Everyone is welcome.
 https://groups.google.com/forum/#!forum/putnami-web-toolkit

 Also think to follow us on twitter. 
 https://twitter.com/PutnamiTeam

 Regards.

 —
 Fabien
 http://pwt.putnami.org 
 http://pwt.putnami.org/?utm_source=have-you-tryutm_medium=gwt-groups  

 Le 27 juin 2014 à 02:26, Eddy Ponce edy...@gmail.com javascript: a 
 écrit :

 Looks Great, like other serius UI , congratulations¡, I will try to use it 
 the next week, the problem I think it is about the documentation , we must 
 create a forums for this topic




-- 
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: Best approach from consuming REST(Jetty) webservice

2014-07-10 Thread SANTHOSH
Thanks for all your replies. I am not supposed to use third part api's
like  resty-gwt and Errai, I go with requestBuilder.

Thanks
Santhosh




On Thu, Jul 10, 2014 at 11:55 AM, Subhrajyoti Moitra subhrajyo...@gmail.com
 wrote:

 +1 for Errai.


 On Thu, Jul 10, 2014 at 6:11 AM, Slava Pankov pank...@gmail.com wrote:

 Or use Errai JAX-RS
 https://docs.jboss.org/author/display/ERRAI/Errai+JAX-RS

 On Tuesday, July 8, 2014 7:12:06 AM UTC-7, Thomas Broyer wrote:



 On Tuesday, July 8, 2014 10:11:11 AM UTC+2, Santhosh Thadaka wrote:

 I have my backend with EJB and REST webservice and I want to consume
 the REST service with GWT as a front end can any one suggest with which is
 the best approach

 RPC
 RequestFactory
 RequestBuilder

 and I am not allowed to use any external api's. Please let me know what
 all should be taken care.


 GWT-RPC is an RPC protocol and API, and RequestFactory is a protocol too.

 If you want to consume REST services, you'll have to use either
 RequestBuilder or XMLHttpRequest (the former wraps the latter).
 If the data you exchange is JSON, then you can either use JsonUtils and
 overlay types (unfortunately only works for parsing for now –stringify is
 being added as I write–, but you can defer to JSONObject for
 serialization), JSONParser and friends, or AutoBeans.


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


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


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


JSON to ValueProxy

2014-07-10 Thread trayan . simeonov
Is there some way using AutonBean.decode to convert standart json - {name 
: Some name} to 

class NameProxy extends ValueProxy{
  String getName();

 void setName(String name);
}

-- 
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: SuperDevMode not so super

2014-07-10 Thread Jakub Ściuba
Is there any option to debug JS running a browser with sourcemaps in 
IntelliJ? 

On Friday, February 14, 2014 12:19:46 AM UTC+1, Colin Alworth wrote:

 There is a prototype project enabling Eclipse to debug the JS running in 
 the browser with sourcemaps - check it out at http://github.com/sdbg/sdbg 
 http://www.google.com/url?q=http%3A%2F%2Fgithub.com%2Fsdbg%2Fsdbgsa=Dsntz=1usg=AFQjCNEiP1D5xjpSbEyJpC1ACWW0Vlt4Cg.
  


 On Thursday, November 15, 2012 8:46:26 AM UTC-8, Clint Gilbert wrote:

 -BEGIN PGP SIGNED MESSAGE- 
 Hash: SHA1 

 If I could hook Eclipse up to Firefox or Chrome and step through code, 
 that would make SDM much more workable.  Is that currently possible? 

 If so, is it possible to inspect the internal state of an object 
 defined in Java, compiled to JS, and running in a browser VM? 
 Breakpoints and stepping line by line are great, but losing object 
 inspection would be a big step back. 

 On 11/14/2012 09:58 PM, Chris Lercher wrote: 
  On Thursday, November 15, 2012 2:53:37 AM UTC+1, Thomas Broyer 
  wrote: 
  
  SourceMaps could then be used by your IDE so you could put 
  breakpoints in your editor window. 
  
  
  I can see the potential - it could be big. I do have a few doubts 
  though: 
  
  1. Would this also allow me to inspect the internal state of 
  objects from within my IDE? (Is this even possible?) 2. What about 
  super-sourced classes, which are - at least in Eclipse - usually 
  excluded from the build path to avoid error messages (that's 
  probably the smaller problem, as I imagine, that this could be 
  taken care of by the IDE plugins) 
  
  
  
  Embedded browsers, even if using the exact same engine, don't 
  behave like their full blown counterparts (IE, when embedded, 
  has different rules for switching between IE5.5Quirks/IE7/IE8/etc. 
  modes for instance) 
  
  
  I think, living with these differences in Dev Mode would be ok. 
  The situation was different back in Hosted Mode's time, because 
  Super Dev Mode was missing. I believe, that Dev Mode currently has 
  some important use cases, which Super Dev Mode can't cover (yet?) 
  For these use cases, the browser differences are often not that 
  important. 
  
  -- 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/-/65KGTSLnUJ0J. 
  To post to this group, send email to 
  google-we...@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. 

 -BEGIN PGP SIGNATURE- 
 Version: GnuPG v1.4.11 (GNU/Linux) 
 Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ 

 iEYEARECAAYFAlClHDEACgkQ5IyIbnMUeTsejwCcCepJDymqjpECsv7PXhXnbciF 
 L9gAn34/OEEJArXpXU6zq+10OlSmvs2L 
 =QD9T 
 -END PGP SIGNATURE- 



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


How can a GWT served html page have the lang attribute set?

2014-07-10 Thread kannanj


As per GAR compliance, language has to be indicate with page.

Question 2.9. Is the content’s human language indicated in the markup?
E.g. for a page written in all one language, `html lang=fr`, or for a 
multi-lingual page,  `div lang=fr`.

A GWT application indicates its supported locales list in in its gwt.xml, 
and the html page with the locale requested by the client gets served. How 
can a GWT application have the lang attribute set in the html tag? Our 
application is UI widget based, and therefore we don't have a host html 
page, but directly add the widget to the RootPanel().

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


How to render a component after setting its property without calling any implicit method in gwt?

2014-07-10 Thread Mohammed Sameen
Hi,
I am creating my own widgets library using gwt 2.5 for my application to be 
used.But facing issues while creating this widget component.Widgets 
creation will be like this-textbox with label,checkbox with label,datebox 
with label,radio button with label.Here label field is common for all 
widget creation.
See the below code,

/*basebox code which will create the default label with corresponding 
component(widget)*/
public abstract class BaseBox extends FlowPanel{
protected Widget box;
private String title;
private String name;
Widget labelWidget;
private LabelBoxField boxLabel;

public BaseBox(String name){
this.name=name; 
addMembers(name);
}

protected void addMembers(final String name) {
this.name = name;
box = createBox(name);
}

protected abstract Widget createBox(String name);

public void setTitle(String title) {
this.title=title;
labelWidget = createLabel(title);
}

/*code for creating label*/
protected Widget createLabel(final String title) {
if (title == null || title.isEmpty()
|| title.equals(Constants.EMPTY_STRING)) {
this.boxLabel = new LabelBoxField();
} else {
if (getIsHintButtonRequired()) {
this.boxLabel = new LabelBoxField(title,
getIsHintButtonRequired(),getRequired());
} else {
this.boxLabel = new LabelBoxField(title,getRequired());
}
}
boxLabel.setHorizontalAlignment(HasHorizontalAlignment.ALIGN_RIGHT);
return boxLabel;
}

public void showTitle(Boolean showTitle){
this.showTitle=showTitle;
}


/*this method will render the component before adding it to 
main-panelshould not call this method implicitly*/
public void redraw(){

addStyleName(ROW_FLUID);

if(showTitle){
((LabelBoxField)labelWidget).getBoxLabel().setVisible(true);
}else{
if(labelWidget!=null){
((LabelBoxField)labelWidget).getBoxLabel().setVisible(false);
}
}
 if(labelWidget!=null){
labelWidget.addStyleName(getStyleName(labelOrientation));
} 
box.addStyleName(getStyleName(labelOrientation));
 if(showTitle){
add(labelWidget);
}
 add(box);
}


/**code for textbox which extends Basebox*/
public class TextItemBox extends BaseBox {

public TextItemBox(String name) {
super(name);
}

@Override
protected Widget createBox(String name) {
TextBox box = new TextBox();
box.setName(name);

return box;
}
}

/*code which create textbox and added to main-panel*/

TextBox txt=new TextBox(txtItem);
txt.setTitle(Enter the Name to Display);
txt.showTitle(false);
hp.add(txt);


First we create the widget by calling new TextBox() and we set the 
properties like(setTitle,showAlignment,etc).After setting this property how 
do we render the component again.Like for example in smartgwt after 
creating the widget we set the properties,widgets render by itself without 
calling any specific methods like redraw().How can this be achieved in 
GWT?Please give suggestion?

-- 
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: GWT distributed builds

2014-07-10 Thread Артем Крошенинников
Thanks a lot for your detailed answer.

Let me explain in a bit more details: We've got one server (24 cores, ~60 
RAM) that has a master node, where Jenkins (CI tool) is placed. It builds 
our application several times per hour, and yes, we fully rebuild our 
application (we've had problems with incremental builds several times). On 
this server we also have several slave nodes. I was asking whether somebody 
has some working examples how to make it work with Jenkins.

Re development: we do use several permutations, 2 for testing purposes 
(automated tests), 1 as a show-off for our project owner, and... here, 
indeed, you're right, we don't need permutations that are generated for 
another languages, thanks for pointing this out.

Thanks again, I think now it's clear what I need to do. :)

четверг, 10 июля 2014 г., 0:56:54 UTC+4 пользователь Jens написал:

 Well, we fully rebuild our application because it's quite big, and is 
 developed more or less actively. So if we have enough resources (and we do 
 have them), we can build it in parallel and the question is, does anybody 
 has success story?


 Not sure what kind of a story you want to hear? If you have 23 
 permutations and 23 hosts available then its like just compiling one 
 permutation + some overhead because of data distribution and fetching.
 But during development nearly everybody works with a single permutation 
 only. Full builds are most likely done on a CI server as a nightly job or 
 when you do a release.

 The wiki page gives you all the information you need to distribute the GWT 
 compilation. How you design your distributed build environment is up to 
 you. Could be as easy as a set of shell scripts + scp + ssh remote script 
 execution.

 There are some projects building on top of what GWT provides but I don't 
 know how well they work. You will easily find them using google search. 

 -- 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/d/optout.


Re: GWT distributed builds

2014-07-10 Thread Артем Крошенинников
Good advice, but not for this case. :)

четверг, 10 июля 2014 г., 4:38:34 UTC+4 пользователь Slava Pankov написал:

 Use collapse-all-properties / in your gwt.xml when making development 
 builds. Or use superdev mode.



-- 
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: JSON to ValueProxy

2014-07-10 Thread Vasu
If you are looking to generate OverlayTypes. I have created one maven 
plugin which can generate OverlayType but it will generate it from Server 
side Java Bean class and not from Json. You have to add few annotation and 
this plugin will do the job. refer following 
project https://github.com/pandurangpatil/gwt-mvn-helper. You will find a 
sample inside mvn-helper-test module. This plugin is more helpful if you 
are using Request Factory.


[image: Pandurang Patil on about.me] 
Pandurang Patil
about.me/pandurangpatil
  http://about.me/pandurangpatil
website: http://www.agnie.net
twitter: @agniesoftware
Cell : +91-9823241535

On Thursday, 10 July 2014 15:04:03 UTC+5:30, trayan@agilemates.com 
wrote:

 Is there some way using AutonBean.decode to convert standart json - 
 {name : Some name} to 

 class NameProxy extends ValueProxy{
   String getName();

  void setName(String name);
 }


-- 
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: How to render a component after setting its property without calling any implicit method in gwt?

2014-07-10 Thread Jens
The very first advice I can give you is to not implement it they way you 
have done it.

public BaseBox(String name){
  this.name=name; 
  addMembers(name);
}

protected void addMembers(final String name) {
  this.name = name;
  box = createBox(name);
}

protected abstract Widget createBox(String name);

The constructor of BaseBox calls an abstract method that is implemented by 
a sub class of BaseBox. That means when createBox() is called, the 
constructor of your sub class (e.g. TextBox) has not yet been executed and 
fields you may set in your constructor are not initialized yet. If these 
fields are used in createBox() you will get NullPointerException. A 
constructor should never call a method that can be overridden by sub 
classes. To fix that you can override Widget.onLoad() which will 
automatically be called by GWT when the widget is added to the page. You 
could call your create methods in onLoad then.

Also you have used inheritance which is kind of wrong. Inheritance means 
is-a but a TextBox is not a FlowPanel (TextBox is-a BaseBox is-not-a 
FlowPanel). So you should use composition which means you should make your 
BaseBox extends Composite and then call initWidget() to initialize it with 
a FlowPanel. That way you hide methods that you would inherit from 
FlowPanel otherwise, e.g. TextBox.add(new Button()) doesn't make a lot of 
sense right? With composition TextBox.add() does not exist.

Next to your redraw problem: Normally you would directly apply changes, 
e.g. in your showTitle() method you would directly execute the 
corresponding code to change the widget, e.g label.setVisible(! 
title.isEmpty());. GWT also allows you to schedule finally commands that 
are executed at the end of the current event loop. This allows you to batch 
changes and only do the redrawing work once for all changes. For example 
take a look at LayoutPanel.add() which schedules a layout command.


-- 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/d/optout.


Re: SuperDevMode not so super

2014-07-10 Thread Frank Hossfeld
Yes, there is. Create a running configuration for JavaScript, start the 
configuration, install the IntelliJ-Plugin for Chrome... end it works ... 
Really nice.

It seems, that FireFox won't work. I opened a ticket at IntelliJ. Hope theq 
will fix it 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/d/optout.


GWT 1.7.0 is not working with browser IE 10 or above.

2014-07-10 Thread ssg
Good morning everyone,
I am currently using GWT 1.7.0. It was working fine in earlier versions of 
browser IE 10 Compatibility View, IE 9, IE 8.
Our company moved to Windows 7 with browser IE 10. My application is NOT 
working in IE 10 or higher?

Should I migrate to latest versions of GWT.? If yes, Which version of GWT 
should I migrate my application to? 
I am currently using GWT 1.7.0, Spring.
Any help regarding this would be greatly appreciated.

Thanks a lot in advance!

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


IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Corey Bishop
I have a complex web application that I have to get running under IE8 (no 
choice on this). I've been dogged by performance issues for weeks. The 
application runs really slow. I get the annoying Do you want to stop 
running this script? warnings. We've been optimizing for weeks and made 
some progress getting it to run faster with fewer script warnings, but 
still not quite there.

Then, I noticed that the application performs great when I'm hitting 
gwt.codesvr. The application runs quickly. I get no script warnings. This 
is counter-intuitive, because I've found that applications perform worse in 
dev mode than with compiled mode.

I couldn't figure why. So, I went to a colleague and he suggested looking 
at the compiler settings. I found that we had them set like this:

  set-property name=compiler.stackMode value=emulated /
  set-configuration-property name=
compiler.emulatedStack.recordLineNumbers value=true /
  set-configuration-property name=
compiler.emulatedStack.recordFileNames value=true /


I set recordLineNumbers and recordFileNames to false. Instantly, the 
application performed much better in compiled mode. The speed was now 
comparable to what I was seeing with dev mode. I did some more research on 
the forums and found that running stackMode as emulated impacts performance 
as well. So, now I have them set like this:

set-property name=compiler.stackMode value=strip /
  set-configuration-property name=
compiler.emulatedStack.recordLineNumbers value=false /
  set-configuration-property name=
compiler.emulatedStack.recordFileNames value=false /

This helped performance a little. Not as dramatic as changing the other 
settings to false, but there was some improvement.

Here's my problem. I'm still getting the Do you want to stop running this 
script? warnings in compiled mode where I don't get them in dev mode. Is 
there something else I can try to get compiled mode to perform like dev 
mod? Is there a compiler setting (or some other setting) I can look at that 
could help? What compiler settings are being used in the code server? Is 
there anyway I can see how they're set? Any other suggestions?

-- 
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: GWT 1.7.0 is not working with browser IE 10 or above.

2014-07-10 Thread Jens


 I am currently using GWT 1.7.0. It was working fine in earlier versions of 
 browser IE 10 Compatibility View, IE 9, IE 8.
 Our company moved to Windows 7 with browser IE 10. My application is NOT 
 working in IE 10 or higher?


Maybe your Windows 7 IE 10 does not load the app in compatibility view? 
Other than that I have no idea what browsers will work/not work with GWT 
1.7.0 as this GWT version is ancient to me.

 

 Should I migrate to latest versions of GWT.? If yes, Which version of GWT 
 should I migrate my application to? 


Obviously the latest GWT version: 2.6.1. 

-- 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/d/optout.


Re: IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Jens
I think the remaining compiler settings won't buy you a lot additional 
performance. The reason why the above settings cost you so much performance 
is that the generated JavaScript will be 2x+ the size than what it should 
be. Especially recordLineNumbers hurts as GWT will generate one extra line 
of code to record line numbers for each line of your app code.

The most optimized JS you can get is when running the GWT compiler with the 
following parameters:

-XnocheckCasts -XnoclassMetadata -XclosureCompiler -optimize 9

This removes all dynamic class cast checks (no ClassCastException anymore), 
all class metadata (e.g. Class.getName() will return junk) and runs the 
final JS through the closure compiler again to safe some additional bits. 
But again this probably doesn't give you a lot performance and might even 
be dangerous if your app depends on correct class names from 
Class.getName().

If you app is still slow then your app is simply doing too much JS / DOM 
work for IE 8. Most likely you load too much data from the server and 
display too much stuff at once. In IE 8 for large data tables you should 
migrate to CellTable / DataGrid which are a lot faster in IE 8 than 
traditional GWT widgets.

You could also check if you attach a parent widget to the DOM and after it 
is attached you make for loops to append childs to it. This can also hurt 
as the browser will do layout recalculations for each child added. Instead 
first add childs to the parent and then attach the parent to the DOM. Then 
the browser only needs to do one layout recalculation.

-- 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/d/optout.


Re: IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Corey Bishop
I'll try those compiler settings and see if they help (and make sure they 
don't hurt).

And loading a lot of JS/DOM for IE8 is my problem. I'm doing paging and 
progressive loading to alleviate the issue. With long running scripts, you 
can periodically check in with the main browser event loop to prevent them 
if you can break up you work. It's just that it is hard to do when 
rendering in the grid and we're running out of places to do this. We're 
going to keep at it.

In the meantime though, I'm just frustrated by the fact that I get the 
performance I want when running in DEV mode, but not when it's compiled. 
I'd like to understand is happening in DEV mode that is different from 
compiled that improve performance. Ultimately, the GWT Plugin is serving up 
javascript to IE8 to render, correct? It's just compiling that javascript 
on the fly from the java code. What's different about the javascript being 
generated by the plugin from the javascript genereted by the compiler?

-- 
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: IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Corey Bishop
Also, I should note that I'm on GWT 2.5.1. We need to upgrade, but are a 
little too late in the cycle right now.

-- 
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: IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Jens


 In the meantime though, I'm just frustrated by the fact that I get the 
 performance I want when running in DEV mode, but not when it's compiled. 
 I'd like to understand is happening in DEV mode that is different from 
 compiled that improve performance. Ultimately, the GWT Plugin is serving up 
 javascript to IE8 to render, correct? It's just compiling that javascript 
 on the fly from the java code. What's different about the javascript being 
 generated by the plugin from the javascript genereted by the compiler?


Well while in DevMode your Java code is executed inside your JVM and not 
inside the browser as JavaScript. The only thing the browser directly 
executes are JSNI calls as they represent native JavaScript calls. What 
makes DevMode slow are calls to JavaScript which must go through the 
browser plugin. Some GWT SDK classes have optimizations to run faster in 
DevMode by avoiding to ask the browser to execute JavaScript. For example 
you can have something like

if(GWT.isScript()) {
  // choose implementation that is fast when compiled to JS because it uses 
lots of JSNI and native JavaScript features
} else {
  // choose implementation that can run in pure JVM to avoid calls to the 
browser plugin which cost lots of time in DevMode.
}

Because you are using IE 8 which isn't the fastest browser it is not 
surprising that some parts of GWT are faster in DevMode for you simply 
because they are not executed in the browser but instead in the JVM.

-- 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/d/optout.


Re: IE8 application performs better in dev mode than under compiled mode

2014-07-10 Thread Corey Bishop
That makes sense. I wasn't sure exactly how the plugin worked and what 
javascript was actually running in the browser.

On Thursday, July 10, 2014 1:13:09 PM UTC-7, Jens wrote:

 In the meantime though, I'm just frustrated by the fact that I get the 
 performance I want when running in DEV mode, but not when it's compiled. 
 I'd like to understand is happening in DEV mode that is different from 
 compiled that improve performance. Ultimately, the GWT Plugin is serving up 
 javascript to IE8 to render, correct? It's just compiling that javascript 
 on the fly from the java code. What's different about the javascript being 
 generated by the plugin from the javascript genereted by the compiler?


 Well while in DevMode your Java code is executed inside your JVM and not 
 inside the browser as JavaScript. The only thing the browser directly 
 executes are JSNI calls as they represent native JavaScript calls. What 
 makes DevMode slow are calls to JavaScript which must go through the 
 browser plugin. Some GWT SDK classes have optimizations to run faster in 
 DevMode by avoiding to ask the browser to execute JavaScript. For example 
 you can have something like

 if(GWT.isScript()) {
   // choose implementation that is fast when compiled to JS because it 
 uses lots of JSNI and native JavaScript features
 } else {
   // choose implementation that can run in pure JVM to avoid calls to the 
 browser plugin which cost lots of time in DevMode.
 }

 Because you are using IE 8 which isn't the fastest browser it is not 
 surprising that some parts of GWT are faster in DevMode for you simply 
 because they are not executed in the browser but instead in the JVM.

 -- 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/d/optout.