Re: Conceptual Doubt
Hi Robson, Have you done any Swing programming before? -- 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: Multiple instances of a view
@Thomas: I am using @Singleton annotation also. Now I am getting friendly with Guice and GWT combination. Thanks all for your support. On Sat, Apr 13, 2013 at 2:40 PM, Thomas Broyer t.bro...@gmail.com wrote: On Saturday, April 13, 2013 12:48:21 AM UTC+2, Andrea Boscolo wrote: This is how GIN works, it always inject a new instance when requested. If you want to inject the same instance, bind the dependency into Singleton scope, using bind(YourClass.class).in(**Singleton.class), inside you GinModule. Or annotating the view class with @Singleton. -- 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. -- Deepak Chauhan -- 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.
Thumbnail interface with infinite scrolling, are cell widgets the best choice?
Hi, I'm writing an app which has a thumbnail interface and in which users may want to browser hundreds if not thousands of custom widgets (images + other). Are data presentation widgets my best choice? Obviously my main concern here is performance and resources usage. -- 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: RequestFactory polymorphic arguments issue, is it possible?
Hi Thomas,
In my case the BarProxyExt is pretty much a wrapper on the entity proxy. I
wasn't sure how RF checked to see if the object given was the entity proxy
it created, but thought that if it was a check based on the ID for example
then any class implementing it (wrapping) should work. But you confirmed
that RF is checking to see that it's the same entity proxy it created so
polymorphism wouldn't work in this case. I just wanted to know how much RF
needed to know about the implementation. Thanks for the answer.
-Seth
On Saturday, April 13, 2013 11:08:12 AM UTC+2, Thomas Broyer wrote:
Not sure what you're trying to do but it's not a supported usecase.
RequestFactory only supports proxies created by its RequestContexts.
On Friday, April 12, 2013 5:32:15 PM UTC+2, GWTter wrote:
Hi all,
I'm having an issue using an implementation of an extended EntityProxy. I
have the setup below, now when I call setBarProxyExt(BarProxyExt
barProxyExt) I get no errors and I am sure that the setBar method is
receiving the correct bar however the field is not set.
This however is not the case if I inside setBarProxyExt(...) I call
setBar(barProxyExt.getBarProxy()) instead of just on the barProxyExt.
Now I'm thinking it may be because the setter is looking for a particular
instance managed by the autobeans. But if that's not the case shouldn't
this work?
Many thanks in advance,
-seth
public interface BarProxy extends EntityProxy{...}
public class BarProxyExt implements BarProxy{
private BarProxy mutableBarProxy;
public BarProxy getBarProxy(){
return mutableBarProxy;
}
}
public interface FooProxy extends EntityProxy{
public BarProxy getBar();
public void setBar(BarProxy bar);
}
public class FooProxyExt implements FooProxy{
private FooProxy mutableFooProxy; //this has already been set and is
editable
@Override
public BarProxy getBar(){
return mutableFooProxy.getBar();
}
@Override
public void setBar(BarProxy bar){
mutableFooProxy.setBar(bar);
}
//issue is using this method
public void setBarProxyExt(BarProxyExt barProxyExt){
setBar(barProxyExt);
}
...
}
--
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: CSS Attribute *= and ^= selectors
I thought that was the problem. tnx!
Is there some roadmap or plan when will this be implemented?
On Saturday, April 13, 2013 11:04:52 AM UTC+2, Thomas Broyer wrote:
On Friday, April 12, 2013 4:19:43 PM UTC+2, Robert Pofuk wrote:
Hi,
In my CSS i have:
@Sprite [class*=icon-], [class^= icon-] {
gwt-image: myImage1;
}
@Sprite .icon-white {
gwt-image: myImage2;
}
[ERROR]- The @sprite rule [] must specify the gwt-image property
While using some other selectors:
@Sprite [class|=icon-], [class~= icon-] {
gwt-image: myImage1;
}
works as espected!
I'm I doing something wrong or is this a bug?
CssResources are limited to CSS 2.1 (with a few additions).
|= and ~= are CSS 2.1:
http://www.w3.org/TR/CSS21/selector.html#attribute-selectors
*= and ^= are from Selectors Level 3: http://www.w3.org/TR/selectors/
--
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: Sending Mail with GWT+Spring
?!
You can't have Spring Beans or resources on the client-side and you can't
just simple execute a sever side function by calling it on the client side.
You have to use RPC, RequestFactory or RequestBuilder to generate a request
for the backend and then call the server-side function (in your case
sending an email).
I would strongly recommend to read the GWT docs and how to client-server
communication works.
On Friday, April 12, 2013 5:39:49 PM UTC+2, vinu raju wrote:
can anybody help me , how to send the mail using gwt and spring.
i tried but getting error as : no source code is available for type
org.springframework.core.io.Resource,did you forget the inherit a required
module?
my code is this:
*Client side:*
Resource res = new
ClassPathResource(classpath:context/applicationContext.xml);
BeanFactory factory = new XmlBeanFactory(res);
Object o = factory.getBean(id2);
GreetingServiceImpl mail = (GreetingServiceImpl)o;
//String password =result.getPassword();
try {
mail.sendMail(fromvinu1,fromvinu1,forgotpassword,password);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
*Server side*:
private MailSender mail;
public void setMail(MailSender mail)
{
this.mail = mail;
}
public String sendMail(String from, String to,String subject,String msg) {
SimpleMailMessage message = new SimpleMailMessage();
message.setFrom(from);
message.setTo(to);
message.setSubject(subject);
message.setText(msg);
mail.send(message);
System.out.println(Mail Sent Successfully...!);
// return UserInfo;
return msg;
*XML file:*
bean id=id1
class=org.springframework.mail.javamail.JavaMailSenderImpl
property name=host value=smtp.gmail.com /
property name=port value=465 /
property name=username value=fromvinu1 /
property name=password value= /
property name=javaMailProperties
props
prop key=mail.smtp.authtrue/prop
prop
key=mail.smtp.socketFactory.classjavax.net.ssl.SSLSocketFactory/prop
prop key=mail.smtp.socketFactory.port465/prop
prop key=mail.debugtrue/prop
prop key=mail.smtp.starttls.enabletrue/prop
/props
/property
/bean
bean id=id2 class=package.GreetingServiceImpl
property name=mail ref=id1 /
/bean
*
*
--
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.
Gwt Request factory
Hi All, I am using gwt request factory. But, there is one design issue I am facing. As per the proxy design in RequestContext interface I can only declare one service in @service annotation. But there are situations where many methods in the context can be served by different services. But, due to design constraint, I have to put the all context methods in same service. Can somebody tell me the better way to get it done -- Deepak Chauhan -- 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: Issue: Gwt-RadioButton Grouping.
No, There is no any problem. you have to specify unique name of all controls. more detail refer http://examples.roughian.com/index.htm#Widgets~RadioButton On Friday, 12 April 2013 21:10:01 UTC+5:30, Satyarao Kambapu wrote: Hello all, I am using same group name for two of my GWT-RadioButtons. When I click one of these, another one gets disabled, which is good. But programmatically (when i do debug) the other radio button value is still remained as 'true' . As per my requirement it should be false. I am thinking that it is problem of GWT-RadioButton Group concept. Does this problem of GWT - RadioButton? Please let me know the solution for it. -- Satya -- 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: Conceptual Doubt
Hi, Aman, No, I haven't. What do I do? Em segunda-feira, 15 de abril de 2013 04h01min33s UTC-3, Aman Sharma escreveu: Hi Robson, Have you done any Swing programming before? -- 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: Gwt Request factory
Can you create a service implementation which forwards to the concrete services? Alternatively you can create a proxy for each service. On 15.04.2013 10:38, deepak chauhan wrote: Hi All, I am using gwt request factory. But, there is one design issue I am facing. As per the proxy design in RequestContext interface I can only declare one service in @service annotation. But there are situations where many methods in the context can be served by different services. But, due to design constraint, I have to put the all context methods in same service. Can somebody tell me the better way to get it done -- Deepak Chauhan -- 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. -- 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: Gwt Request factory
On Monday, April 15, 2013 10:38:49 AM UTC+2, deepak chauhan wrote: Hi All, I am using gwt request factory. But, there is one design issue I am facing. As per the proxy design in RequestContext interface I can only declare one service in @service annotation. But there are situations where many methods in the context can be served by different services. But, due to design constraint, I have to put the all context methods in same service. Why is it so? Why can't you create several RequestContext? If it's about batching, there's RequestContext#append(). -- 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: CSS Attribute *= and ^= selectors
On Monday, April 15, 2013 10:03:38 AM UTC+2, Robert Pofuk wrote: I thought that was the problem. tnx! Is there some roadmap or plan when will this be implemented? AFAICT, Google has plans to contribute a new GssResource backed by Closure Stylesheet, which should bring more of CSS3 to ClientBundle. As for enhancing the existing CssResource, the problem, AFAIK, is finding a CSS3 parser in Java. -- 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.
GWT issues while waiting for gwtproject ?
Hi, Are we allowed to add bugs in the bugtracking in the middle of the migration to gwtproject ? I recently added a few and I hope that sometimes they will be sorted out. My last one was a performance bottleneck on HTMLPanel with many widgets being added (due to the very inefficient WidgetCollection implementation). https://code.google.com/p/google-web-toolkit/issues/detail?id=8105 After looking at my reported bugs, I can see that most of my bug reports never made it to being implemented or even accepted or rejected (one got fixed quickly since I contributed the change) I hope that the gwtproject will improve on this - it is a really frustrating feeling and makes me wonder if I should stick on using GWT and reorient to non google technologies instead (Axing Google Reader will probably drive me over the edge if I don't find a decent alternative pretty soon). David -- 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: GWT issues while waiting for gwtproject ?
Any reason for not using CellWidgets instead of HTMLPanels ? On Monday, April 15, 2013 4:18:33 PM UTC+2, stuckagain wrote: Hi, Are we allowed to add bugs in the bugtracking in the middle of the migration to gwtproject ? I recently added a few and I hope that sometimes they will be sorted out. My last one was a performance bottleneck on HTMLPanel with many widgets being added (due to the very inefficient WidgetCollection implementation). https://code.google.com/p/google-web-toolkit/issues/detail?id=8105 After looking at my reported bugs, I can see that most of my bug reports never made it to being implemented or even accepted or rejected (one got fixed quickly since I contributed the change) I hope that the gwtproject will improve on this - it is a really frustrating feeling and makes me wonder if I should stick on using GWT and reorient to non google technologies instead (Axing Google Reader will probably drive me over the edge if I don't find a decent alternative pretty soon). David -- 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: GWT issues while waiting for gwtproject ?
You can still file bugs to the tracker. I guess its just missing men power to keep the tracker up-to-date and verify/triage issues. Also the tracker is pretty huge and issues can be missed easily, especially if they are not up-voted. Regarding Google Reader: I switched to feedly and it works pretty well. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT issues while waiting for gwtproject ?
Hi, The HTML that is being put in the HTMLPanel is generated and inserted as one big HTML string. The HTML can either be generated in Javascript or on the server. If CellWidgets are an alternative then I am certainly interested in checking them out, but I though they were only useful in CellTable and CellTree. David On Monday, April 15, 2013 4:36:23 PM UTC+2, Ümit Seren wrote: Any reason for not using CellWidgets instead of HTMLPanels ? On Monday, April 15, 2013 4:18:33 PM UTC+2, stuckagain wrote: Hi, Are we allowed to add bugs in the bugtracking in the middle of the migration to gwtproject ? I recently added a few and I hope that sometimes they will be sorted out. My last one was a performance bottleneck on HTMLPanel with many widgets being added (due to the very inefficient WidgetCollection implementation). https://code.google.com/p/google-web-toolkit/issues/detail?id=8105 After looking at my reported bugs, I can see that most of my bug reports never made it to being implemented or even accepted or rejected (one got fixed quickly since I contributed the change) I hope that the gwtproject will improve on this - it is a really frustrating feeling and makes me wonder if I should stick on using GWT and reorient to non google technologies instead (Axing Google Reader will probably drive me over the edge if I don't find a decent alternative pretty soon). David -- 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.
JavaDocs are out of date?
Any chance someone can update the JavaDocs at http://google-web-toolkit.googlecode.com/svn/javadoc/latest/index.html? The header says these docs are for GWT 2.5.0.*rc2*. I don't actually know if that's true, or if there's just a typo, but it'd be more re-assuring if the header was 2.5.1... FWIW, this link is available from https://developers.google.com/web-toolkit/doc/latest/RefGWTClassAPI. Thanks, jay -- 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: GWT issues while waiting for gwtproject ?
Jens, That would be an understatement :-) I am still positive that the bug triage disaster gets fixed because that is fundamental to the success of opensource. And I saw in the gwt-steering news group that they are going for some interesting roadmap, so I live in hope. I would love to contribute, but only if I can be sure that it will get accepted (most of the time). I can not keep on defending the usage of GWT to my boss/company if we don't get some minimal feedback and support. I need to do a technology assessment right now, and I really don't know how to defend the choice right now. Some people have talked about AngularJS, Dart and other interesting technologies, but that is Google tech as well, so potentially subject to be scrapped much faster than what we like. As for Feedly: it does not work in IE. I need Chrome, iOS and IE support for a feed reader. But let's not dwell on this subject in this newsgroup. David On Monday, April 15, 2013 5:00:24 PM UTC+2, Jens wrote: You can still file bugs to the tracker. I guess its just missing men power to keep the tracker up-to-date and verify/triage issues. Also the tracker is pretty huge and issues can be missed easily, especially if they are not up-voted. Regarding Google Reader: I switched to feedly and it works pretty well. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT issues while waiting for gwtproject ?
That would be an understatement :-) I am still positive that the bug triage disaster gets fixed because that is fundamental to the success of opensource. And I saw in the gwt-steering news group that they are going for some interesting roadmap, so I live in hope. I would love to contribute, but only if I can be sure that it will get accepted (most of the time). In fact if GWT would have a really good issue tracker then the issue tracker itself would give you a pretty good picture about the roadmap (excluding features that are not related to source code). I think the GWT team is happy about all contributions and if they pass the code review I don't see an issue with accepting contributions. If an issue isn't noticed but you have a patch ready then you should just ping on the contributors group. I can not keep on defending the usage of GWT to my boss/company if we don't get some minimal feedback and support. I need to do a technology assessment right now, and I really don't know how to defend the choice right now. Some people have talked about AngularJS, Dart and other interesting technologies, but that is Google tech as well, so potentially subject to be scrapped much faster than what we like. Totally understandable. Especially if your boss asks How many open issues does GWT have? and you must answer ~2600 :-) Maybe its worth it to kick the current issue tracker, create a new one and asking people to resubmit their issues if they feel its worth it and the GWT version isn't too old. Issues you loose that way will be resubmitted sooner or later by others. Cleaning up the current issue tracker is probably to much work. -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Gwt Request factory
@Stefan: I am using Spring for injecting the implementation. @Thomas: This is the answer I was looking for. Multiple requestContext is good solution. Thanks for your precious support. On Mon, Apr 15, 2013 at 6:46 PM, Thomas Broyer t.bro...@gmail.com wrote: On Monday, April 15, 2013 10:38:49 AM UTC+2, deepak chauhan wrote: Hi All, I am using gwt request factory. But, there is one design issue I am facing. As per the proxy design in RequestContext interface I can only declare one service in @service annotation. But there are situations where many methods in the context can be served by different services. But, due to design constraint, I have to put the all context methods in same service. Why is it so? Why can't you create several RequestContext? If it's about batching, there's RequestContext#append(). -- 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. -- Deepak Chauhan -- 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: Conceptual Doubt
Take a look at Activities and Place and MVP. There is a lot out there on these topics. I think it is what you are looking for. Mike On Sunday, April 14, 2013 2:04:17 PM UTC-7, Robson Braga wrote: Hi folks! I'm new in GWT and I'm writing a GWT Application from scratch. After studied some google documentation for GWT, I've concluded that the only way to create different kind of forms, in the same application, is by composites. The problem is that, according with I've read, the concept of composites should be create custom widgets, not an entire form, like a configuration form. Should I use composites to create Entries, Addresses, Orders, Configuration forms and such? If not, how do I create different kind of forms in the same GWT Application? Thanks 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: How to globally catch all exceptions?
I recently implemented this and found this article particularly useful: http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/ On Wednesday, April 10, 2013 4:22:03 AM UTC-7, membersound wrote: Hi, how could one best catch all exceptions within the application that occur and are not handled anywhere? Would it just require a try-catch block in the onModuleLoad()? Or maybe an extra Servlet? Thanks -- 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.
NumberFormat output wrong?
Today I noticed that the output of my NumberFormat (GWT 2.5.0) is not what I thought it had been set to. So I played with it a little and found the output to be inconsistent. The formats: 1: NumberFormat.getFormat(#,###.##) 2: NumberFormat.getFormat(#,###.00) 3: NumberFormat.getFormat(#,##0.00) The output is as follows: 1: 3.57, 0.98, 0.6 2: 3.57, .98, .60 3: 3.57, 0.98, 0.60 The NumberFormat class doc states the following: 0 Number Yes Digit # Number Yes Digit, zero shows as absent According to the doc comments, show above, I was expect the following output for each format: 1: 3.57, .98, .6 2: 3.57, .98, .60 3: 3.57, 0.98, 0.60 What going on here? The output for 1 should not have the leading 0, just like the 2nd format. Thanks, Pat -- 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: GWT issues while waiting for gwtproject ?
On Monday, April 15, 2013 4:18:33 PM UTC+2, stuckagain wrote: Hi, Are we allowed to add bugs in the bugtracking in the middle of the migration to gwtproject ? We have no plan to move the issue tracker. At least not in the near-future. -- 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.
GWT compiler error
When I attempt to compile my app I get the following. I have no idea how to correct this. I am using: Juno Service Release 2 GWT 2.5.1 Thanks. Blake McBride Compiling module booklion.BookLion [ERROR] An internal compiler exception occurred com.google.gwt.dev.jjs.InternalCompilerException: Unexpected error during visit. at com.google.gwt.dev.jjs.ast.JVisitor.translateException(JVisitor.java:109) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:276) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116) at com.google.gwt.dev.jjs.ast.JConditional.traverse(JConditional.java:67) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.acceptImmutable(JModVisitor.java:305) at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:250) at com.google.gwt.dev.jjs.ast.JNewInstance.traverse(JNewInstance.java:84) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.acceptImmutable(JModVisitor.java:305) at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:250) at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:241) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116) at com.google.gwt.dev.jjs.ast.JBinaryOperation.traverse(JBinaryOperation.java:81) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116) at com.google.gwt.dev.jjs.ast.JIfStatement.traverse(JIfStatement.java:50) at com.google.gwt.dev.jjs.ast.JModVisitor$ListContextImmutable.traverse(JModVisitor.java:170) at com.google.gwt.dev.jjs.ast.JModVisitor.acceptWithInsertRemoveImmutable(JModVisitor.java:336) at com.google.gwt.dev.jjs.ast.JBlock.traverse(JBlock.java:83) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:137) at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:133) at com.google.gwt.dev.jjs.ast.JMethodBody.traverse(JMethodBody.java:82) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) at com.google.gwt.dev.jjs.ast.JMethod.visitChildren(JMethod.java:434) at com.google.gwt.dev.jjs.ast.JMethod.traverse(JMethod.java:403) at com.google.gwt.dev.jjs.ast.JModVisitor.traverse(JModVisitor.java:361) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:273) at com.google.gwt.dev.jjs.ast.JModVisitor.accept(JModVisitor.java:265) at com.google.gwt.dev.jjs.impl.UnifyAst.mainLoop(UnifyAst.java:900) at com.google.gwt.dev.jjs.impl.UnifyAst.exec(UnifyAst.java:625) at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.precompile(JavaToJavaScriptCompiler.java:640) at com.google.gwt.dev.jjs.JavaScriptCompiler.precompile(JavaScriptCompiler.java:33) at com.google.gwt.dev.Precompile.precompile(Precompile.java:278) at com.google.gwt.dev.Precompile.precompile(Precompile.java:229) at com.google.gwt.dev.Precompile.precompile(Precompile.java:141) at com.google.gwt.dev.Compiler.run(Compiler.java:232) at com.google.gwt.dev.Compiler.run(Compiler.java:198) at com.google.gwt.dev.Compiler$1.run(Compiler.java:170) at com.google.gwt.dev.CompileTaskRunner.doRun(CompileTaskRunner.java:88) at com.google.gwt.dev.CompileTaskRunner.runWithAppropriateLogger(CompileTaskRunner.java:82) at com.google.gwt.dev.Compiler.main(Compiler.java:177) Caused by: java.lang.RuntimeException: Unexpected IOException on in-memory stream at com.google.gwt.dev.javac.CompilationUnit.getTypes(CompilationUnit.java:360) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateUnit(UnifyAst.java:670) at com.google.gwt.dev.jjs.impl.UnifyAst.searchForTypeByBinary(UnifyAst.java:968) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1031) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:942) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateUnit(UnifyAst.java:676) at com.google.gwt.dev.jjs.impl.UnifyAst.searchForTypeByBinary(UnifyAst.java:968) at com.google.gwt.dev.jjs.impl.UnifyAst.translate(UnifyAst.java:1031) at com.google.gwt.dev.jjs.impl.UnifyAst.resolveType(UnifyAst.java:942) at com.google.gwt.dev.jjs.impl.UnifyAst.assimilateUnit(UnifyAst.java:676) at
Re: GWT compiler error
Have you tried to delete your gwt-unitCache directory? -- 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?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: JavaDocs are out of date?
See https://plus.google.com/111739836936169749229/posts/7ZYGmbTE5WE -- 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.
Encoding/decoding POJO to JSON
Are there any JSON encoding/decoding libraries that will work on both
client and server and that will work with inheritance? Here's the basic
structure I'm working with:
Class Recording {
String title;
ListEvent events;
}
abstract class Event {
Long time;
}
class EventOne extends Event {
String someProperty;
}
class EventTwo extends Event {
Long someOtherProperty;
}
My goal is to be able to take the POJO and encode it to JSON on the server
side (actually an android app), and decode the JSON on the client side. I'd
really like to package that functionality up into a jar file that can be
shared between the projects.
I've tried using AutoBeans, which encode just fine, but it seems they do
not support inheritance. RestyGWT supports inheritance, but only works on
the client side. GSON only works on the server side. Is there one library
to rule them all, or do I need to use different libraries for client and
server side processing?
--
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: moveable areas as in iGoogle?
Hi, thank you! There seem to be many ways to go. But does someone know who it's done in iGoogle? Thanks Magnus -- 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: Java 7
It's just my opinion, but in my mind making the JDK compliance to 1.6 and call that fully compatible with JDK 7 is not... well... what I was expecting (at least). I understand that tweaking the compiler to actually and truly support Java 7 is not easy and demand time. But Java 7 is around for ... uh... years? (since July - 2011 according to Wikipedia). I understand that GWT is now handled by a committee, since last year. And still, there's no public roadmap of when we are going to have the real Java 7 support (and I'm not even talking about Java 8). So, eh, am I wrong on asking such things? Should I recommend other frameworks to my teammates for new projects or still wait for news from GWT? I understand we have to wait till you guys commit the code to Gerrit/GitHub, to organize the project, to mavenize it, to deal with contributors, Google itself and so on. But till when? Sorry for my impatience, but at this stage I don't really feel comfortable with the situation. Maybe it's only me. On Wednesday, April 3, 2013 5:09:35 AM UTC-3, Thomas Broyer wrote: On Wednesday, April 3, 2013 8:15:03 AM UTC+2, Max Völkel wrote: How well does this play together with AppEngine 1.7.7? From their release notes: The Java runtime now defaults to Java7. If you still need to use the Java6 runtime, please use the --use_java6 flag when deploying your app. We encourage you to move to Java7 as soon as possible. It sounds I should compile for a 1.7 target. So I should *not* set maven.compiler.source to 1.6, right? I don't know how AppEngine's Java runtime works, but my 7 and 8 JREs are very well capable of running classes compiled with -target 1.6 or earlier, and mixing classes compiled with different -target (you'd never be able to use Maven, or pretty much any third-party dependency actually, if that wasn't the case; btw GWT is compiled with -target 1.6 and is fully compatible with a JDK 7, and we haven't yet heard of anyone having issues using RPC or RequestFactory on AppEngine) -- 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.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Daniel Kurka has posted comments on this change. Change subject: Verify that Timer has not been canceled before firing .. Patch Set 1: Code-Review+1 (4 comments) small nits, see comments File user/src/com/google/gwt/user/client/Timer.java Line 143:* nit white space File user/test/com/google/gwt/user/client/TimerCancelTest.java Line 3: * nit: whitespace Line 6: * nit: whitespace Line 8: * nit: whitespace -- To view, visit https://gwt-review.googlesource.com/2511 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0ac16598bef878ed756f2fe0dc696166f2a3d504 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Leif Åstrand l...@vaadin.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add methods to HasTreeItems
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/2520
Change subject: Add methods to HasTreeItems
..
Add methods to HasTreeItems
-getItem
-getItemCount
-getItemIndex
fixes ISSUE 30
Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157
---
M user/src/com/google/gwt/user/client/ui/HasTreeItems.java
M user/src/com/google/gwt/user/client/ui/Tree.java
M user/src/com/google/gwt/user/client/ui/TreeItem.java
3 files changed, 70 insertions(+), 2 deletions(-)
diff --git a/user/src/com/google/gwt/user/client/ui/HasTreeItems.java
b/user/src/com/google/gwt/user/client/ui/HasTreeItems.java
index cb7ba1e..05f3147 100644
--- a/user/src/com/google/gwt/user/client/ui/HasTreeItems.java
+++ b/user/src/com/google/gwt/user/client/ui/HasTreeItems.java
@@ -69,15 +69,38 @@
TreeItem addTextItem(String itemText);
/**
- * Removes an item.
+ * get the TreeItem at a specific index
*
+ * @param index of the TreeItem to get
+ * @return the TreeItem or null
+ */
+ TreeItem getItem(int index);
+
+ /**
+ * get the number of TreeItems
+ *
+ * @return the number of TreeItems
+ */
+ int getItemCount();
+
+ /**
+ * get the index of a TreeItem
+ *
+ * @param child to get the index for
+ * @return the index of the child element
+ */
+ int getItemIndex(TreeItem child);
+
+ /**
+ * Removes an item.
+ *
* @param item the item to be removed
*/
void removeItem(TreeItem item);
/**
* Removes an item.
- *
+ *
* @param isItem the wrapper of item to be removed
*/
void removeItem(IsTreeItem isItem);
diff --git a/user/src/com/google/gwt/user/client/ui/Tree.java
b/user/src/com/google/gwt/user/client/ui/Tree.java
index 5d062a5..5b73daa 100644
--- a/user/src/com/google/gwt/user/client/ui/Tree.java
+++ b/user/src/com/google/gwt/user/client/ui/Tree.java
@@ -540,6 +540,7 @@
* @param index the index to be retrieved
* @return the item at that index
*/
+ @Override
public TreeItem getItem(int index) {
return root.getChild(index);
}
@@ -549,11 +550,23 @@
*
* @return this tree's item count
*/
+ @Override
public int getItemCount() {
return root.getChildCount();
}
/**
+ * get the index of a TreeItem
+ *
+ * @param child to get the index for
+ * @return the index of the child element
+ */
+ @Override
+ public int getItemIndex(TreeItem child) {
+return root.getItemIndex(child);
+ }
+
+ /**
* Gets the currently selected item.
*
* @return the selected item
diff --git a/user/src/com/google/gwt/user/client/ui/TreeItem.java
b/user/src/com/google/gwt/user/client/ui/TreeItem.java
index d65a2f2..87b5f27 100644
--- a/user/src/com/google/gwt/user/client/ui/TreeItem.java
+++ b/user/src/com/google/gwt/user/client/ui/TreeItem.java
@@ -465,6 +465,38 @@
}
/**
+ * get the TreeItem at a specific index
+ *
+ * @param index of the TreeItem to get
+ * @return the TreeItem or null
+ */
+ @Override
+ public TreeItem getItem(int index) {
+return getChild(index);
+ }
+
+ /**
+ * get the number of TreeItems
+ *
+ * @return the number of TreeItems
+ */
+ @Override
+ public int getItemCount() {
+return getChildCount();
+ }
+
+ /**
+ * get the index of a TreeItem
+ *
+ * @param child to get the index for
+ * @return the index of the child element
+ */
+ @Override
+ public int getItemIndex(TreeItem child) {
+return getChildIndex(child);
+ }
+
+ /**
* Gets this item's parent.
*
* @return the parent item
--
To view, visit https://gwt-review.googlesource.com/2520
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Thomas Broyer has posted comments on this change.
Change subject: Verify that Timer has not been canceled before firing
..
Patch Set 2:
(3 comments)
Where can I find instructions for how to configure Eclipse
to not automatically add that whitespace back when
formatting the code using the formatter settings included
with the project?
No idea. AFAIK, Eclipse and IntelliJ IDEA insist in using 2 distinct rules.
But the problem is not so much about whether those spaces are there or not,
but more about including only the relevant changes in the patch (i.e. git
add -p vs. git add).
File user/test/com/google/gwt/user/client/TimerCancelTest.java
Line 29: private int timerCount;
This field should live in the CountingTimer, which could thus become a
static nested class, and removes the need for the gwtSetUp (which is
probably not needed anyway, even in the current configuration).
Line 51: // Busy wait so that both timers will be added to the event
loop queue the next time it is
Is this really needed? If so, can you please add a comment somewhere
explaining exactly the conditions the issue manifests itself?
Line 97: public String getModuleName() {
Move at the top of the class.
--
To view, visit https://gwt-review.googlesource.com/2511
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I0ac16598bef878ed756f2fe0dc696166f2a3d504
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add methods to HasTreeItems
Thomas Broyer has posted comments on this change. Change subject: Add methods to HasTreeItems .. Patch Set 1: Code-Review+1 Should these methods in Tree and TreeItem be unit-tested? How much do we care about breaking backwards-compatibility for people implementing that interface? (I don't have a strong opinion) -- To view, visit https://gwt-review.googlesource.com/2520 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/2512
Change subject: Adding a DOM clear method to RootPanel
..
Adding a DOM clear method to RootPanel
By calling rootPanel.clear(true) the user can clear
widgets AND DOM elements located under this RootPanel.
fixes Issue 516
Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
---
M user/src/com/google/gwt/user/client/ui/RootPanel.java
M user/test/com/google/gwt/user/client/ui/RootPanelTest.java
2 files changed, 71 insertions(+), 0 deletions(-)
diff --git a/user/src/com/google/gwt/user/client/ui/RootPanel.java
b/user/src/com/google/gwt/user/client/ui/RootPanel.java
index 8d22da0..9ca22f6 100644
--- a/user/src/com/google/gwt/user/client/ui/RootPanel.java
+++ b/user/src/com/google/gwt/user/client/ui/RootPanel.java
@@ -25,6 +25,7 @@
import com.google.gwt.i18n.client.BidiUtils;
import com.google.gwt.i18n.client.HasDirection;
import com.google.gwt.i18n.client.LocaleInfo;
+import com.google.gwt.user.client.DOM;
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.Window;
@@ -300,4 +301,21 @@
super(elem.com.google.gwt.user.client.Element cast());
onAttach();
}
+
+ /**
+ * clear the rootPanel, if eraseDom is true also remove any DOM elements
that
+ * are not widgets
+ * @param eraseDom should the DOM elements be removed as well
+ */
+ public void clear(boolean eraseDom) {
+clear();
+
+if (eraseDom) {
+ com.google.gwt.user.client.Element containerElement = getElement();
+ com.google.gwt.user.client.Element child = null;
+ while ((child = DOM.getFirstChild(containerElement)) != null) {
+DOM.removeChild(containerElement, child);
+ }
+}
+ }
}
diff --git a/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
b/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
index 6584fef..2b730d2 100644
--- a/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
+++ b/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
@@ -19,6 +19,7 @@
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
import com.google.gwt.junit.client.GWTTestCase;
+import com.google.gwt.user.client.DOM;
/**
* Tests {@link RootPanel}.
@@ -28,6 +29,44 @@
@Override
public String getModuleName() {
return com.google.gwt.user.User;
+ }
+
+ public void testClearRootPanelAndDOM() {
+
+RootPanel rootPanel = createDOM(testClearRootPanelAndDOM);
+
+rootPanel.add(new Button(a));
+rootPanel.add(new Button(b));
+
+com.google.gwt.user.client.Element newDiv = DOM.createDiv();
+newDiv.setInnerText(c);
+rootPanel.getElement().appendChild(newDiv);
+
+assertEquals(3, rootPanel.getElement().getChildCount());
+
+rootPanel.clear(true);
+assertEquals(0, rootPanel.getElement().getChildCount());
+ }
+
+ public void testClearRootPanel() {
+
+RootPanel rootPanel = createDOM(testClearRootPanel);
+
+rootPanel.add(new Button(a));
+rootPanel.add(new Button(b));
+
+com.google.gwt.user.client.Element newDiv = DOM.createDiv();
+newDiv.setInnerText(c);
+rootPanel.getElement().appendChild(newDiv);
+
+assertEquals(3, rootPanel.getElement().getChildCount());
+
+rootPanel.clear(false);
+assertEquals(1, rootPanel.getElement().getChildCount());
+
+// clean up
+rootPanel.clear(true);
+assertEquals(0, rootPanel.getElement().getChildCount());
}
public void testDetachNowWithErrorOnDetach() {
@@ -131,4 +170,18 @@
RootPanel.getBodyElement().appendChild(elem);
return elem;
}
+
+ private RootPanel createDOM(String id) {
+// create our own part in the document
+com.google.gwt.user.client.Element div = DOM.createDiv();
+div.setId(id);
+Document.get().getBody().appendChild(div);
+
+// get it via RootPanel
+RootPanel rootPanel = RootPanel.get(id);
+
+// no elements in the DOM prior to test
+assertEquals(0, rootPanel.getElement().getChildCount());
+return rootPanel;
+ }
}
--
To view, visit https://gwt-review.googlesource.com/2512
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Matthew Dempsky has posted comments on this change. Change subject: Verify that Timer has not been canceled before firing .. Patch Set 1: FYI, no need to abandon. That error message was just for posting the message to the mailing list. -- To view, visit https://gwt-review.googlesource.com/2510 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I68fbe0896dc9d494bbdb86fd2220d4b8a3710420 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Leif Åstrand l...@vaadin.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Matthew Dempsky has posted comments on this change.
Change subject: Adding a DOM clear method to RootPanel
..
Patch Set 1: Code-Review+1
(2 comments)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 306:* clear the rootPanel, if eraseDom is true also remove any DOM
elements that
Proper grammar please:
Clear the root panel. If eraseDom is true, then also remove any DOM
elements that are not widgets.
Line 310: public void clear(boolean eraseDom) {
eraseDom seems like an odd variable name to me. What about clearDom
or removeChildren?
--
To view, visit https://gwt-review.googlesource.com/2512
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Matthew Dempsky has posted comments on this change.
Change subject: Verify that Timer has not been canceled before firing
..
Patch Set 3:
(2 comments)
File user/src/com/google/gwt/user/client/Timer.java
Line 52: private static native void clearInterval(int id) /*-{
I know this is pre-existing, but why are these methods native? Can we
change them to be Java calls to Impl.clearInterval and Impl.clearTimeout?
File user/test/com/google/gwt/user/client/TimerCancelTest.java
Line 20: public class TimerCancelTest extends GWTTestCase {
You'll need to add this Test class to a test suite for it to run. I'd pick
MiscSuite arbitrarily, since there doesn't seem to be a more appropriate
one.
--
To view, visit https://gwt-review.googlesource.com/2511
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I0ac16598bef878ed756f2fe0dc696166f2a3d504
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Reduce ClassSourceFileComposer memory and time complexity to...
Matthew Dempsky has abandoned this change. Change subject: Reduce ClassSourceFileComposer memory and time complexity to O(N) .. Abandoned Submitted. -- To view, visit https://gwt-review.googlesource.com/2460 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: abandon Gerrit-Change-Id: I30301a58bad0244a41b08fb534c4cb18b90c9494 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Goktug Gokdogan has posted comments on this change.
Change subject: Verify that Timer has not been canceled before firing
..
Patch Set 3:
(2 comments)
File user/src/com/google/gwt/user/client/Timer.java
Line 52: private static native void clearInterval(int id) /*-{
According to history, converted from @wnd recently. I can't see any reason.
Line 88: private int cancelCounter = 0;
Can you put a short description? Something like:
// To workaround clearTimeout bug in IE:
https://code.google.com/p/google-web-toolkit/issues/detail?id=8101
--
To view, visit https://gwt-review.googlesource.com/2511
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I0ac16598bef878ed756f2fe0dc696166f2a3d504
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leif Åstrand l...@vaadin.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Verify that Timer has not been canceled before firing
Brian Slesinsky has posted comments on this change. Change subject: Verify that Timer has not been canceled before firing .. Patch Set 3: To be specific, it was changed as part of Ray's massive patch to support module unloading, so added Ray as a reviewer. -- To view, visit https://gwt-review.googlesource.com/2511 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0ac16598bef878ed756f2fe0dc696166f2a3d504 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Leif Åstrand l...@vaadin.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leif Åstrand l...@vaadin.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid creating anonymous inner classes with wildcard type pa...
Roberto Lublinerman has uploaded a new patch set (#2). Change subject: Avoid creating anonymous inner classes with wildcard type parameters. .. Avoid creating anonymous inner classes with wildcard type parameters. Under Java 7 wildcards can not be type parameters of superclasses in the extends clause nor superinterfaces in the implementing clause. Anonymous inner classes can not have wildcards in their type parameters. Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea Review-Link: https://gwt-review.googlesource.com/#/c/2470/ --- M dev/core/src/com/google/gwt/core/ext/typeinfo/JParameterizedType.java M dev/core/src/com/google/gwt/dev/javac/typemodel/JParameterizedType.java M user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java M user/test/com/google/gwt/uibinder/UiBinderSuite.java A user/test/com/google/gwt/uibinder/test/client/BadValueChangeWidget.java A user/test/com/google/gwt/uibinder/test/client/UiHandlerTest.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml 8 files changed, 228 insertions(+), 6 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2470 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add methods to HasTreeItems
Goktug Gokdogan has posted comments on this change.
Change subject: Add methods to HasTreeItems
..
Patch Set 1: Code-Review+1
(9 comments)
Nit comments on javadoc style.
Although it is breaking change I guess it is safe to assume this will not
cause trouble for many people; It doesn't look like this will break
anything in google3. So I don't have any objections.
File user/src/com/google/gwt/user/client/ui/HasTreeItems.java
Line 72:* get the TreeItem at a specific index
Gets the tree item at the specified index.
Line 74:* @param index of the TreeItem to get
@param index the index of the tree item to get
Line 75:* @return the TreeItem or null
@return the item at the specified index or {@code null} if the index is out
of range.
Line 80:* get the number of TreeItems
Gets the number of tree items.
Line 82:* @return the number of TreeItems
You don't need a @return here as it is not adding anything new.
Line 87:* get the index of a TreeItem
Gets the index of the specified tree item.
Line 89:* @param child to get the index for
@param child the tree item to get the index for
Line 90:* @return the index of the child element
@return the item's index or {@code -1} if the item is not found.
Line 93:
Can you update the other files accordingly?
--
To view, visit https://gwt-review.googlesource.com/2520
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Removes api-checker reference JARs from the source tree.
Brian Slesinsky has posted comments on this change. Change subject: Removes api-checker reference JARs from the source tree. .. Patch Set 1: It seems like we should have a separate repo in Gerrit for GWT dependencies, with cruft removed; it only needs to work back to a stable release, and before that you can use svn tools. Does Maven have a mode for loading deps from a local cache? We could use whatever directory structure Maven supports. -- To view, visit https://gwt-review.googlesource.com/2500 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3d5a585fb57cfd959504109df35279b3c9c56879 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Goktug Gokdogan has posted comments on this change.
Change subject: Adding a DOM clear method to RootPanel
..
Patch Set 1:
(2 comments)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 306:* clear the rootPanel, if eraseDom is true also remove any DOM
elements that
Actually, I'm little bit hesitant to add this change.
If the user is manipulating the DOM with elements, it is usually best to
leave them the control including cleaning up handlers behind if needed.
This API is coming from Panel class and a similar problem exists with any
GWT Panel widget.
Of course someone can argue that having a convenience method in RootPanel
is a special case and will be helpful to developers.
Anyway, if we end up going in this direction, I think it is better to have
little bit more explanation:
Clears the root panel.
p By default {@link #clear()} will only remove children that are GWT
widgets. This method also provides the option to remove all children
including the non-widget DOM elements that are directly added (e.g.
elements added via {@code getElement().appendChild(...)}.
@param clearDom if {@code true} this method will also remove any DOM
elements that are not widgets.
Line 314: com.google.gwt.user.client.Element containerElement =
getElement();
Having Element#removeAllChildren() would be very useful in many cases
including this one.
--
To view, visit https://gwt-review.googlesource.com/2512
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Brian Slesinsky has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 1: I like that. Perhaps add Element.removeAllChildren() and put documentation in root panel's javadoc showing how to do it? -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Daniel Kurka has uploaded a new patch set (#2). Change subject: Adding a DOM clear method to RootPanel .. Adding a DOM clear method to RootPanel By calling rootPanel.clear(true) the user can clear widgets AND DOM elements located under this RootPanel. fixes Issue 516 Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Review-Link: https://gwt-review.googlesource.com/#/c/2512/ --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 78 insertions(+), 0 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Thomas Broyer has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 2: (1 comment) IMO this should remove all child *nodes*, not only elements. File user/src/com/google/gwt/user/client/ui/RootPanel.java Line 324: DOM.removeChild(containerElement, child); That only removes elements right? So div id=rootpanelSome imixed/i content/div wouldn't be cleared correctly. Any reason this isn't using setInnerHTML() ? -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Add methods to HasTreeItems
Daniel Kurka has uploaded a new patch set (#2). Change subject: Add methods to HasTreeItems .. Add methods to HasTreeItems -getItem -getItemCount -getItemIndex fixes ISSUE 30 Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157 Review-Link: https://gwt-review.googlesource.com/#/c/2520/ --- M user/src/com/google/gwt/user/client/ui/HasTreeItems.java M user/src/com/google/gwt/user/client/ui/Tree.java M user/src/com/google/gwt/user/client/ui/TreeItem.java 3 files changed, 69 insertions(+), 2 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2520 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I0a1a20be6dba36f3978d08178b92269b2736f157 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Removes api-checker reference JARs from the source tree.
Thomas Broyer has posted comments on this change. Change subject: Removes api-checker reference JARs from the source tree. .. Patch Set 1: A lot of people will tell you that putting binaries in a VCS is a Bad Thing™, and 99% of the time they'll be right. That wouldn't be an issue for GWT_TOOLS if we keep the append only rule, otherwise it means that cloning the repo also clones all previous versions of the binaries, that many of us will never use. For once, this is something SVN does well: an easy way to synchronize a snapshot of a directory tree. Maven doesn't play well with dependencies that aren't in a Maven repo (other build tools allow this, not Maven), but it's rather easy to deploy our dependencies in a Maven repo. And for people that don't want Maven to connect to the Internet, you can setup a mirror and have everyone use it in their settings.xml (this is recommended in all organizations anyway). Generally, the mirror downloads from the Internet but you can configure it so that it only hosts artifacts, or possibly allow it to connect from time to time (e.g. when you bootstrap a new build, or you know you'll need new dependencies or new versions of them). That said, if (as?) Google keeps its own non-Maven build, there's no reasons to change the way you deal with 3rd-party libs; the main change is that because it'll be easier for us (using Maven) to add new dependencies or update them, we'll have to try not doing it too often and you'll have to keep an eye on changes on any pom.xml file. You can use then the maven-dependency-plugin to update your GWT_TOOLS with dependencies from Maven (and go through your internal process for updating it): http://maven.apache.org/plugins/maven-dependency-plugin/copy-dependencies-mojo.html It was Ray who first proposed moving to Maven last year, so maybe he already thought about this (and if not, well, you know who to blame ;-) ) -- To view, visit https://gwt-review.googlesource.com/2500 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I3d5a585fb57cfd959504109df35279b3c9c56879 Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Thomas Broyer t.bro...@gmail.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: John A. Tamplin j...@jaet.org Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: No -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Daniel Kurka has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 2: (1 comment) File user/src/com/google/gwt/user/client/ui/RootPanel.java Line 324: DOM.removeChild(containerElement, child); setInnerHTML of course... You are the man, Thomas! -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Daniel Kurka has uploaded a new patch set (#3). Change subject: Adding a DOM clear method to RootPanel .. Adding a DOM clear method to RootPanel By calling rootPanel.clear(true) the user can clear widgets AND DOM elements located under this RootPanel. fixes Issue 516 Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Review-Link: https://gwt-review.googlesource.com/#/c/2512/ --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 75 insertions(+), 0 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka danku...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Goktug Gokdogan has posted comments on this change.
Change subject: Adding a DOM clear method to RootPanel
..
Patch Set 2:
(3 comments)
Daniel, can you also respond to other concerns?
It is a good idea to respond every comment sometimes just with Done so
that it will be clear if you have a missed any comment or not :)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 306:* Clear the rootPanel. If clearDom is true, then also remove
any DOM
When describing a method it is better to use Clears vs Clear.
then also has double space.
Line 309:* By default {@link #clear()} will only remove children that
are GWT widgets.
p otherwise it will not be a new paragraph in generated javadoc.
Line 324: DOM.removeChild(containerElement, child);
This will also remove text nodes. I was also wondering innerHTML but
according to a jsperf comparison it is much slower:
http://jsperf.com/innerhtml-vs-removechild
--
To view, visit https://gwt-review.googlesource.com/2512
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid creating anonymous inner classes with wildcard type pa...
Goktug Gokdogan has posted comments on this change. Change subject: Avoid creating anonymous inner classes with wildcard type parameters. .. Patch Set 1: (1 comment) Sorry, I forgot to publish this one before. File user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java Line 216: handlerSourceName, handlerVarName); addHandler method might be specific but it should be always valid to pass a non specific handler (just for simplification). -- To view, visit https://gwt-review.googlesource.com/2470 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea Gerrit-PatchSet: 1 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid creating anonymous inner classes with wildcard type pa...
Roberto Lublinerman has uploaded a new patch set (#4). Change subject: Avoid creating anonymous inner classes with wildcard type parameters. .. Avoid creating anonymous inner classes with wildcard type parameters. Under Java 7 wildcards can not be type parameters of superclasses in the extends clause nor superinterfaces in the implementing clause. Anonymous inner classes can not have wildcards in their type parameters. Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea Review-Link: https://gwt-review.googlesource.com/#/c/2470/ --- M dev/core/src/com/google/gwt/core/ext/typeinfo/JParameterizedType.java M dev/core/src/com/google/gwt/dev/javac/typemodel/JParameterizedType.java M user/src/com/google/gwt/uibinder/rebind/HandlerEvaluator.java M user/test/com/google/gwt/uibinder/UiBinderSuite.java A user/test/com/google/gwt/uibinder/test/client/UiHandlerTest.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java M user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml A user/test/com/google/gwt/uibinder/test/client/WildcardValueChangeWidget.java 8 files changed, 213 insertions(+), 6 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2470 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Avoid creating anonymous inner classes with wildcard type pa...
Roberto Lublinerman has posted comments on this change.
Change subject: Avoid creating anonymous inner classes with wildcard type
parameters.
..
Patch Set 3:
(3 comments)
File user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.java
Line 229: void onWildcaredValueChangeList(ValueChangeEventList?
event) {
Actually it does not matter. If it has a wildcard then the raw type is
used. Both will work.
File user/test/com/google/gwt/uibinder/test/client/WidgetBasedUi.ui.xml
Line 698: img src={values.aUrl} ui:field='myImage'/
Done
File
user/test/com/google/gwt/uibinder/test/client/WildcardValueChangeWidget.java
Line 40:* Here is the key for the test. ValueChangeHandler is
parameterized by ? and not Tq
Done
--
To view, visit https://gwt-review.googlesource.com/2470
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ifbcd6ecec455512a7da5eb473c6bf2e9f402f0ea
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Roberto Lublinerman has uploaded a new change for review.
https://gwt-review.googlesource.com/2530
Change subject: Fix non deterministic behaviour in TypeTightener.
..
Fix non deterministic behaviour in TypeTightener.
JProgram.generalizeTyeps(CollectionJType) depends on the ordering of the
input collection. It was called with data obtained from HashSets.
Made all HashSets that could flown into the aforementioned funcion into
LinkedHashSet to have a deterministic iteration order.
Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608
---
M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
b/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
index bcc1331..5febd27 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
@@ -467,6 +467,23 @@
/**
* Return the least upper bound of a set of types. That is, the smallest
type
* that is a supertype of all the input types.
+ *
+ * NOTE: This function depends on the collection order because the Java
type
+ * hierarchy is not really a lattice. E.g.
+ *
+ *IO
+ *|\ / \
+ *| A B
+ *\ /
+ * \ /
+ * C
+ *
+ * where I is an interface an {O,A,B,C} are classes.
+ *
+ * generalizeTypes({A,C}) could either be I or O.
+ *
+ * In particular generalizeTypes({I,A,C}) = I and
generalizeTypes({A,C,I}) = O.
+ *
*/
public JReferenceType generalizeTypes(Collection? extends
JReferenceType types) {
assert (types != null);
diff --git a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
index 70ec21c..c628cd3 100644
--- a/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
+++ b/dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java
@@ -59,9 +59,9 @@
import com.google.gwt.dev.util.log.speedtracer.SpeedTracerLogger.Event;
import java.util.ArrayList;
-import java.util.HashSet;
import java.util.IdentityHashMap;
import java.util.Iterator;
+import java.util.LinkedHashSet;
import java.util.List;
import java.util.Map;
import java.util.Set;
@@ -317,7 +317,7 @@
JParameter param = x.getParams().get(j);
SetJParameter set = paramUpRefs.get(param);
if (set == null) {
-set = new HashSetJParameter();
+set = new LinkedHashSetJParameter();
paramUpRefs.put(param, set);
}
for (JMethod baseMethod : overrides) {
@@ -796,7 +796,7 @@
private static T, V void add(T target, V value, MapT, SetV map) {
SetV set = map.get(target);
if (set == null) {
- set = new HashSetV();
+ set = new LinkedHashSetV();
map.put(target, set);
}
set.add(value);
--
To view, visit https://gwt-review.googlesource.com/2530
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Roberto Lublinerman has uploaded a new patch set (#2). Change subject: Fix non deterministic behaviour in TypeTightener. .. Fix non deterministic behaviour in TypeTightener. JProgram.generalizeTyeps(CollectionJType) depends on the ordering of the input collection. It was called with data obtained from HashSets. Made all HashSets that could flown into the aforementioned funcion into LinkedHashSet to have a deterministic iteration order. Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Review-Link: https://gwt-review.googlesource.com/#/c/2530/ --- M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java 2 files changed, 25 insertions(+), 5 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2530 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Ray Cromwell has posted comments on this change.
Change subject: Fix non deterministic behaviour in TypeTightener.
..
Patch Set 2: Code-Review+1
(1 comment)
I'm ok with the solution, but it leaves me wonder if we should opt with
explicit sorting instead of implicit set ordering.
File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
Line 488:* In particular generalizeTypes({I,A,C}) = I and
generalizeTypes({A,C,I}) = O.
Interesting, and somewhat scary. I wonder if we should impose some kind of
sort order. I think in general, we'd prefer O in this case, since a
concrete implementor would be a tighter bounder than an interface I think,
in terms of further optimizations?
--
To view, visit https://gwt-review.googlesource.com/2530
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Brian Slesinsky has posted comments on this change. Change subject: Fix non deterministic behaviour in TypeTightener. .. Patch Set 2: Code-Review+1 (3 comments) Seems fine. I was wondering whether we could replace LinkedHashSet with a plain List since it looks like we just iterate over the sets. However, I think we still need duplicate removal. Commit Message Line 9: JProgram.generalizeTyeps(CollectionJType) depends on the ordering of the generalizeTypes Line 12: Made all HashSets that could flown into the aforementioned funcion into s/could flown/could flow/ s/funcion/function/ File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java Line 472:* NOTE: Ideally we would like to return the least upper bound but it does not exits as s/exits/exist/ Thanks for the clear explanation. -- To view, visit https://gwt-review.googlesource.com/2530 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Linker bug with useSourceMaps
Good catch. The real solution IMHO to these issues is to do linker
processing on a JS AST, not on text. Most of the current linker API relies
on string operations which make designing a non-brittle sourcemap
difficult. If for example, we read the JS for the fragment via the
Closure/Rhino AST, then we could mutate it in all sorts of interesting
ways, and let the serialization of the AST take care of updating the source
maps.
The class ClosureJsAstTranslator already contains the logic neccessary.
What we could do is use it to translate the GWT JsAst to a Closure Ast, and
serialize that in the CompilationResult. The linker API could then get the
fragments as strings, but could also get the AST if it needed. Manipulating
the AST to do things like splitting, wrapping, et al would preserve the
sourcemap.
-Ray
On Tue, Apr 9, 2013 at 11:39 PM, Alex Epshteyn alexander.epsht...@gmail.com
wrote:
I'm trying to fix a bug (
https://code.google.com/p/google-web-toolkit/issues/detail?id=8100
), and I could use some expert advice. I'm a long time GWT user (7
years), but only recently started hacking the internals, and I need
help on this one.
Background:
SelectionScriptLinker.splitPrimaryJavaScript attempts to check whether
the property compiler.useSourceMaps is true and if it is, the
method avoids splitting the javascript into chunks (which would
destroy the accuracy of the line numbers in the source map).
The Problem:
This method tries to get the property value from
LinkerContext.getProperties, which is not a PropertyOracle, and hence
it can't return the correct property value for the current
permutation. In fact, it will return a null value unless the property
has a static value for all permutations (e.g. set-property
name=compiler.useSourceMaps value=true/)
However, something like
set-property name=compiler.useSourceMaps value=true
when-property-is name=user.agent value=safari/
/set-property
will not work because SelectionScriptLinker.splitPrimaryJavaScript can
only read static property values.
Could someone advise me on how to fix this bug?
Here's is there relevant source code for quick reference:
public static String splitPrimaryJavaScript(StatementRanges ranges,
String js,
int charsPerChunk, String scriptChunkSeparator, LinkerContext
context) {
boolean useSourceMaps = false;
for (SelectionProperty prop : context.getProperties()) {
if (USE_SOURCE_MAPS_PROPERTY.equals(prop.getName())) {
String str = prop.tryGetValue();
useSourceMaps = str == null ? false :
Boolean.parseBoolean(str);
break;
}
}
// TODO(cromwellian) enable chunking with sourcemaps
if (charsPerChunk 0 || ranges == null || useSourceMaps) {
return js;
}
...
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an
email to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups
Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
Another downside of DevMode maintenance is all the hacks needed in the codebase around isScript()/@GwtScriptOnly and other magic JVM stuff. There are still lingering bugs in HostedModeClassRewriter around SingleJsoImpls and generics. I agree that there is nothing that works as smoothly and JVM roundtripping, and even if an incremental SDM mode could have equal or superior reload performance, there is still the issue of IDE integration. On the other hand, for debugging integration with JS, and using GWT code in contexts like Chrome extensions, SDM is a lot nicer. It's also way nicer for stuff like games, where the invocation overhead becomes large for stuff like canvas and webgl. On Sat, Apr 6, 2013 at 5:04 PM, Brian Slesinsky skybr...@google.com wrote: As far as I know, there is no schedule for GWT 3.0, or 2.6 for that matter. I was thinking perhaps we should continue with smaller maintenance releases, 2.5.2 and so on. It seems to fit our current working style where we are making gradual changes, not landing major new features. But arguably Java 7 support is a big enough step to make it 2.6. I have a migration plan for getting Google onto Super Dev Mode and it's my top priority. Certainly Super Dev Mode performance is an issue and I plan to tackle that; our largest GWT apps won't be able to use Super Dev Mode without some significant gains. I've put essentially no work into performance issues; it's all about compatibility so far. Besides running applications, there is also the issue that GWTTestCase runs in dev mode by default. Production mode is significantly slower to start, and GWTTestCase is too slow already. That would have to be fixed. Perhaps our effort to speed up the GWT compiler will bear some fruit here, and I am thinking about how to implement a Super Test Mode. It's unclear how long the migration will take will take. Until that happens I will continue to make Firefox releases. At some point we may switch to the Firefox ESR track, or perhaps someone else can take over making Firefox plugin releases from me. If Firefox actually releases SourceMap support (and there are some signs of this), then that would make Super Dev Mode more feasible on Firefox. Other than Firefox, classic Dev Mode isn't a big support burden so I don't think we need to be in a hurry to drop it. But if we decide to support any new browsers, it will only be in Super Dev Mode. - Brian On Saturday, April 6, 2013 12:17:32 PM UTC-7, John A. Tamplin wrote: On Sat, Apr 6, 2013 at 2:05 PM, Stephen Haberman stephen@gmail.comwrote: For me it would be totally fine to have a plugin for FF15 and then for FF20 and the next for FF25 which would reduce your maintaining work. Same for Chrome. I hold off on updating FF as well, but I believe a lot of users got antsy about oh noes! the latest FF isn't supported, GWT is deadz! before Brian got on top of the FF plugin process. FF clearly wants to get rid of all binary plugins, yet they also have no interest in exposing the sort of hooks we would need to use pure-JS plugins. Chrome has some issues, but with the fork of WebKit, perhaps the identity and performance issues can be addressed -- at least part of the reluctance about doing anything more came from the convoluted path from JS code to V8. I know it takes a lot of effort to keep the FF plugins up to date (I did it for a while myself), but I think that cost is less than the cost of losing a usable DevMode. Totally agreed. I think that should be our goal--getting to GWT to the point where it can integrate sexily with today's/tomorrow's web developer tool chain (JS debuggers, etc.). I think the problem is that the technology to make SuperDevMode even close to as useful as debugging in the JVM doesn't exist yet, and it's not clear when it will exist. I have no problem working towards that goal, but in the meantime you can't be talking about ditching what works great now. SDM is nice, but it still feels like the limited experience of debugging a JS app rather than having the tools available for debugging in the JVM. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Roberto Lublinerman has uploaded a new patch set (#3). Change subject: Fix non deterministic behaviour in TypeTightener. .. Fix non deterministic behaviour in TypeTightener. JProgram.generalizeTypes(CollectionJType) depends on the ordering of the input collection. It was called with data obtained from HashSets. Made all HashSets that could flow into the aforementioned function into LinkedHashSet to have a deterministic iteration order. Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Review-Link: https://gwt-review.googlesource.com/#/c/2530/ --- M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java 2 files changed, 25 insertions(+), 5 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2530 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Roberto Lublinerman has uploaded a new patch set (#4). Change subject: Fix non deterministic behaviour in TypeTightener. .. Fix non deterministic behaviour in TypeTightener. JProgram.generalizeTypes(CollectionJType) depends on the ordering of the input collection. It was called with data obtained from HashSets. Made all HashSets that could flow into the aforementioned function into LinkedHashSet to have a deterministic iteration order. Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Review-Link: https://gwt-review.googlesource.com/#/c/2530/ --- M dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java M dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java 2 files changed, 59 insertions(+), 30 deletions(-) -- To view, visit https://gwt-review.googlesource.com/2530 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Roberto Lublinerman has posted comments on this change.
Change subject: Fix non deterministic behaviour in TypeTightener.
..
Patch Set 2:
(4 comments)
Commit Message
Line 9: JProgram.generalizeTyeps(CollectionJType) depends on the ordering
of the
Done
Line 12: Made all HashSets that could flown into the aforementioned funcion
into
Done
File dev/core/src/com/google/gwt/dev/jjs/ast/JProgram.java
Line 472:* NOTE: Ideally we would like to return the least upper bound
but it does not exits as
Done
Line 488:* In particular generalizeTypes({I,A,C}) = I and
generalizeTypes({A,C,I}) = O.
In general I think we might prefer the ones that are closer in some sense
and at the same closeness prefer a class to an interface. This could be
implemented by a careful traversal of the type hierarchy quasi lattice.
Clearly we would prefer an interface to j.l.Object, right?
--
To view, visit https://gwt-review.googlesource.com/2530
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Ray Cromwell cromwell...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com
Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com
Gerrit-HasComments: Yes
--
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
On Mon, Apr 15, 2013 at 8:48 PM, Ray Cromwell cromwell...@google.comwrote: Another downside of DevMode maintenance is all the hacks needed in the codebase around isScript()/@GwtScriptOnly and other magic JVM stuff. Many of those hacks are there for both performance and debugging (ie, where the JS version is a more complicated implementation to get decent performance when compiled to JS), and not all of them are just because of slow boundary crossings. So, I suspect by doing away with them you would simply make everything slower. There are still lingering bugs in HostedModeClassRewriter around SingleJsoImpls and generics. I agree that there is nothing that works as smoothly and JVM roundtripping, and even if an incremental SDM mode could have equal or superior reload performance, there is still the issue of IDE integration. On the other hand, for debugging integration with JS, and using GWT code in contexts like Chrome extensions, SDM is a lot nicer. It's also way nicer for stuff like games, where the invocation overhead becomes large for stuff like canvas and webgl. So it sounds like they each have their place. -- John A. Tamplin -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Change in gwt[master]: Fix non deterministic behaviour in TypeTightener.
Brian Slesinsky has posted comments on this change. Change subject: Fix non deterministic behaviour in TypeTightener. .. Patch Set 4: Code-Review+1 (1 comment) Seems basically okay but I didn't verify anything about when it's safe to skip removing duplicates. File dev/core/src/com/google/gwt/dev/jjs/impl/TypeTightener.java Line 841: private final MapJVariable, ListJExpression assignments = Maybe add javadoc explaining what each of these variables contains? -- To view, visit https://gwt-review.googlesource.com/2530 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I51f551dbf2d5362f710d4e1321f7b7bb35445608 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Brian Slesinsky skybr...@google.com Gerrit-Reviewer: Ray Cromwell cromwell...@google.com Gerrit-Reviewer: Roberto Lublinerman rlu...@google.com Gerrit-Reviewer: Thomas Broyer t.bro...@gmail.com Gerrit-HasComments: Yes -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups Google Web Toolkit Contributors group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
