date:20130614

You either write a servlet that loads the mp3 from the jar and sends it to 
the client or dont put your audio files into a jar file. If you put your 
audio files in your war file, e.g. war/audio/file.mp3, then you can access 
it just like any other html/js file from your war. You could also put them 
in your app's public folder. Then, after GWT compilation, your audio files 
will be in war/module-name/audiofile.mp3.

-- J.

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

Re: GWT-RPC: loose vs. tight coupling



 It would be nice, if somehow we could use an annotation or some external 
 file to direct what implementation that is needed.
 We sometimes need to send over things for which we are not allowed to 
 change the sources.

 

 We sometimes need to send over things for which we are not allowed to 
 change the sources.


But then you introduce the risk of runtime serialization exceptions if 
someone changes the server side code but doesn't update the annotations/the 
file. 
If you don't have control on the sources then you can always build DTOs in 
cases where you want/need to optimize. I know they can be pain, but they 
can also be really useful as they allow to build responses that optimally 
fits your GWT client side needs. 
You could also fallback to pure JSON with AutoBeans or pure JavaScript 
Overlay Types if it makes sense. In AutoBean interfaces you can use List 
without problem and with Overlay Types you would have JsArray on the client.

-- J.

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

Re: Fixing a column in DataGrid

2013-06-14 Thread Raphael André Bauer

On Wed, May 29, 2013 at 7:24 PM, Jens jens.nehlme...@gmail.com wrote:
 Before deep diving into DataGrid, I think my first make it work approach
 would be to just use two DataGrids and add both to the same DataProvider, so
 that their data is in sync with each other. The first one would contain the
 static x columns while the second one contains the remaining columns. Only
 the second one would allow horizontal scrolling then.

 Do you also use vertical scrolling in your DataGrid? If not, then I would
 try to add position:fixed to each cell of the first x columns. With
 position:fixed you probably would not need to recalculate anything while
 scrolling horizontally.


Hi Jens,


thanks for the suggestion. I had now time to check it out and it works
nicely :) The problem I have now is with vertical scrolling. The left
datagrid scrolls independently of the right datagrid...

Do you have any suggestions how to sync the scrolling?


Thanks :)

Raphael

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

Re: Fixing a column in DataGrid

Well, add a scroll handler to the right ScrollPanel and set the current 
scroll position on the left ScrollPanel.

-- J.

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

Re: GWT-RPC: loose vs. tight coupling

2013-06-14 Thread David

Hi,

I tend to fall back to pure JSON(P) more and more, but that comes with
other problems (a big leak in our beloved IEwith JSONP for example). The
idea that GWT supports RPC with something similar but not quite the same as
java serialisation somehow falls appart in many bigger projects.

Sometimes it is better to not be compatible and then it is clear that you
need some kind of DTO layer. But it is a lot of extra work in big projects,
even when generating these dtos, and I wonder what the performance and VM
heap impact is of always creating these objects.

David

On Fri, Jun 14, 2013 at 11:01 AM, Jens jens.nehlme...@gmail.com wrote:


 It would be nice, if somehow we could use an annotation or some external
 file to direct what implementation that is needed.
 We sometimes need to send over things for which we are not allowed to
 change the sources.



 We sometimes need to send over things for which we are not allowed to
 change the sources.


 But then you introduce the risk of runtime serialization exceptions if
 someone changes the server side code but doesn't update the annotations/the
 file.
 If you don't have control on the sources then you can always build DTOs in
 cases where you want/need to optimize. I know they can be pain, but they
 can also be really useful as they allow to build responses that optimally
 fits your GWT client side needs.
 You could also fallback to pure JSON with AutoBeans or pure JavaScript
 Overlay Types if it makes sense. In AutoBean interfaces you can use List
 without problem and with Overlay Types you would have JsArray on the client.

 -- J.

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




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

Re: GWT-RPC: loose vs. tight coupling

2013-06-14 Thread Shaun Tarves

Hi Jens -

Thank you for the info. For what it's worth, I was able to successfully use 
the an interface in the Async service interface and then the implementation 
in the RemoteService interface. GWT compiled without complaint even though 
the async method signature was technically different.

That said, I saw no change in the final size of the generated .html, .rpc, 
or .js files.

Certainly something to keep exploring.

- Shaun

On Thursday, June 13, 2013 3:46:25 PM UTC-4, Jens wrote:

 Its not so much about performance its more about the resulting code size 
 of your final JS. If you use List in your interface that extends 
 RemoteService (or any DTO that is used with GWT-RPC) the GWT-RPC code 
 generator can not know which concrete types the server side may return. 
 Thus it has to generate de/serializer for all possible List 
 implementations. This bloats your final JS code.

 The interface that extends RemoteService should have the concrete type. 
 Not sure about the Async interface, but I think GWT forces you that both 
 interfaces match each other. I guess you can easily test it yourself with a 
 small GWT project.

 If you know that you use all possible implementations of an interface, 
 then its totally fine to use the interface instead of a concrete type. E.g. 
 in a command pattern you can have an execute(Command) method because at 
 some point in your app flow you have used all possible commands anyways. 

 -- J.


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

LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread Ed

Hi,
I am curious how people use LESS/SASS/... etc.. in GWT i.c.m. GWT 
Clientbundle mechanism?
I looking into using this (never did before).
Please share your experience? (setup, css parsing, experience, )

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

Design Decision RPC with AsyncDataProvider

2013-06-14 Thread Jochen Schnaidt



Hi all,

 

I need an advice about a design question of my application. I am searching 
for a best practise for the following setup.

 

Project is about an application for maintaining huge amounts of data from a 
database. Therefore I implemented a ui with UIBinder and a CellTable, data 
is provided by AsyncDataProvider. Layout is including paging. So basically 
in my ui class I have something like this:

 

@UiHandler(loadButton)

void onLoadButtonClick(ClickEvent event) {

AsyncDataProviderModel provider = new AsyncDataProviderModel() {

@Override

protected void onRangeChanged(HasDataModel display) {

final int start = display.getVisibleRange().getStart();

int length = display.getVisibleRange().getLength();


// Get the ColumnSortInfo from the table.

final ColumnSortList sortList = cellTable.getColumnSortList();

 AsyncCallbackListModel callback = new AsyncCallbackListModel() {

@Override

public void onFailure(Throwable caught) {

Window.alert(caught.getMessage());

}


@Override

public void onSuccess(ListModel result) { 

updateRowData(start, result);

}

};

dataService.loadData(start, length, callback);

}

};

}

 

I want to add column sorting to my view as well. Colum sorting also works 
with the onRangeChanged method. And here starts my problem. What is the 
best way to differ between my normal search request and a column sorting 
request? Do I need to differ?

In my application so far I calculate which the next datasets for the ui are 
( - sounds strange? MS Word told me so). When processing always the same 
requests I need to analyse the source of the onRangeChanged event to go 
back on page one for a sort event. 

I don’t want to build a wrapping request with internal processing mode or 
something. Also I didn’t thought of the how to until now. 

So please group, what is the best way to get a clean interface with 
different methods for the different ui events?

I hope my question is clear because it was very hard to describe and even 
now I must say the description is not good. I hope the point will be clear.

Thanks in Advance. 

Best regards

Jochen

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

How to set RichTextArea background color in IE10?

2013-06-14 Thread dhoffer

I'm using the following to set the RichTextArea  background color which 
works for Firefox and most IE versions but with IE10 it just ignores the 
method.  After calling the method the developer tools indicate the style 
was not added/set.  Why?  How to do this for IE10?

getElement().getStyle().setBackgroundColor(hexValue);

I'm using GWT 2.5.1

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

Re: LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread RyanZA

Vaadin has a special linker that should let you use SASS. I haven't tried 
it though.

https://vaadin.com/blog/-/blogs/link-to-the-client-side-from-sass

On Friday, June 14, 2013 3:23:43 PM UTC+2, Ed wrote:

 Hi,
 I am curious how people use LESS/SASS/... etc.. in GWT i.c.m. GWT 
 Clientbundle mechanism?
 I looking into using this (never did before).
 Please share your experience? (setup, css parsing, experience, )



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

Re: LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread Ed



 Vaadin has a special linker that should let you use SASS. I haven't tried 
 it though.

https://vaadin.com/blog/-/blogs/link-to-the-client-side-from-sass

Thanks for reminding, I almost forgot it :(.
I am currious when this will also be available in the core gwt? As Vaadin 
is now now an  GWT contributor, what are the plans for these things ?

Could it be possible to just pick up this piece of functionality of Vaadin 
and use it, and how ? (without using anything else of Vaadin).

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

Re: Design Decision RPC with AsyncDataProvider

You can set a string identifier to your columns by using 
Column.setDataStoreName(). The easiest identifier would be the raw database 
column name. Then you can go through the ColumnSortList of your CellTable, 
read the database column name and sort order of each sorted column and pass 
this information to the server. This information can then be used to build 
your ORDER BY clause.

Then you only need to detect if sort order has been changed so you can 
switch back to page one in your CellTable. To do so you can add a 
ColumnSortHandler to each column, which gets notified as soon as sort order 
changes.

-- J.

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

Re: LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread Ed Bras

I think the gwt dev team is thinking about CSS SASS support, from the
looks of issue 7624:
https://code.google.com/p/google-web-toolkit/issues/detail?id=7624
It hasn't become stale yet ... ;)

On Fri, Jun 14, 2013 at 4:19 PM, Ed post2edb...@gmail.com wrote:

Vaadin has a special linker that should let you use SASS. I haven't tried
it though.

https://vaadin.com/blog/-/**blogs/link-to-the-client-side-**from-sasshttps://vaadin.com/blog/-/blogs/link-to-the-client-side-from-sass

Thanks for reminding, I almost forgot it :(.
I am currious when this will also be available in the core gwt? As Vaadin
is now now an GWT contributor, what are the plans for these things ?

Could it be possible to just pick up this piece of functionality of Vaadin
and use it, and how ? (without using anything else of Vaadin).

--
You received this message because you are subscribed to a topic in the
Google Groups Google Web Toolkit group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/google-web-toolkit/mrBctJ2BGtI/unsubscribe
.
To unsubscribe from this group and all its topics, send an email to
google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.

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

Re: LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread Ryan Chazen

According to that article it will work without Vaadin, and just requires
that you replace 'widgetset' with 'module'. How exactly you'd go about
doing that is unclear and I haven't tried, but the article definitely
seems to be saying that it should work without issue.
I've had plans to give it a try, but haven't had a reason to use SASS
recently so haven't tried it out yet. Let us know how it goes if you try.

On Fri, Jun 14, 2013 at 4:19 PM, Ed post2edb...@gmail.com wrote:

Vaadin has a special linker that should let you use SASS. I haven't tried
it though.

https://vaadin.com/blog/-/**blogs/link-to-the-client-side-**from-sasshttps://vaadin.com/blog/-/blogs/link-to-the-client-side-from-sass

Thanks for reminding, I almost forgot it :(.
I am currious when this will also be available in the core gwt? As Vaadin
is now now an GWT contributor, what are the plans for these things ?

Could it be possible to just pick up this piece of functionality of Vaadin
and use it, and how ? (without using anything else of Vaadin).

Re: LESS/ SASS/... style usage in GWT ?

2013-06-14 Thread Ryan Chazen

It's been (erroneously) merged into issue 8162, which is just a generic
CSS3 issue. So I wouldn't get your hopes up too quickly.

https://code.google.com/p/google-web-toolkit/issues/detail?can=2q=8162colspec=ID%20Type%20Status%20Owner%20Milestone%20Summary%20Starsid=8162

On Fri, Jun 14, 2013 at 4:22 PM, Ed Bras post2edb...@gmail.com wrote:

I think the gwt dev team is thinking about CSS SASS support, from the
looks of issue 7624:
https://code.google.com/p/google-web-toolkit/issues/detail?id=7624
It hasn't become stale yet ... ;)

On Fri, Jun 14, 2013 at 4:19 PM, Ed post2edb...@gmail.com wrote:

Vaadin has a special linker that should let you use SASS. I haven't tried
it though.

https://vaadin.com/blog/-/**blogs/link-to-the-client-side-**from-sasshttps://vaadin.com/blog/-/blogs/link-to-the-client-side-from-sass

Thanks for reminding, I almost forgot it :(.
I am currious when this will also be available in the core gwt? As Vaadin
is now now an GWT contributor, what are the plans for these things ?

Could it be possible to just pick up this piece of functionality of
Vaadin and use it, and how ? (without using anything else of Vaadin).

Re: RequestFactory Issue 6115

2013-06-14 Thread Nermin

Hello Thomas,

Open Session In View is the right approach to go for. Thank you for this 
advice!
I have implemented it and it works fine now.

However, I have one question regarding OSIV-Pattern: 
In the Hybernate example (see link below) they *begin transaction* before 
doFilter() and *commit on transaction* after it.
https://community.jboss.org/wiki/OpenSessionInView

I am using standard GWT setting with DataNucleus. For some reason it does 
not let me call em.getTransaction().begin(); and 
em.getTransaction().commit(); within the filter.
In my current implementation I can *create EntityManager* before 
doFilter()  and *close it* afterwards (this works), but cannot commit nor 
rollback transaction

Here is the error which I get when trying to open and commit the 
transaction:
org.datanucleus.exceptions.NucleusFatalUserException: Illegal argument

Caused by: java.lang.IllegalArgumentException: cross-group transaction need 
to be explicitly specified, see TransactionOptions.Builder.withXGfound both 
Element {
  type: JobCategory
  id: 1
}
 and Element {
  type: JobCategory
  id: 13
}

Do you have any Idea what might be the reason?
It must probably have something to do with my persistence.xml settings:

persistence-unit name=emajstor_persistence
... some Entities
exclude-unlisted-classestrue/exclude-unlisted-classes
properties
property name=datanucleus.NontransactionalRead value=true/
property name=datanucleus.NontransactionalWrite 
value=true/
property name=datanucleus.ConnectionURL value=appengine/
/properties
/persistence-unit

Thank you in advance:

Nermin



Am Donnerstag, 13. Juni 2013 15:05:56 UTC+2 schrieb Thomas Broyer:



 On Thursday, June 13, 2013 2:57:02 PM UTC+2, Nermin wrote:

 Hello group,

 Is the issue 6115 Fixed in GWT 2.5 or not??
 http://code.google.com/p/google-web-toolkit/issues/detail?id=6115

 My problem is that on a entity with recursive relation the ancestors are 
 not loaded when calling with(ancestors).

 Here is my code:

 @Entity
 public class *JobCategory *{
 // -- Recursive Relation mainCategory - SubCategories
 @*OneToMany*(mappedBy = mainCategory, cascade = CascadeType.ALL)
 private Set*JobCategory* *subCategories *= new 
 HashSetJobCategory();
 @ManyToOne
 private *JobCategory *mainCategory;

 ... Getters / Setters 

 public static ListJobCategory findAllJobCategories() {
 EntityManager em = EMFService.get().createEntityManager();
 try {
 Query query = em.createQuery(SELECT e FROM + 
 JobCategory.class.getSimpleName() +  e ORDER BY i18nKey);
 return (ListJobCategory) query.getResultList();
 } catch (Exception e) {
 e.printStackTrace();
 } finally {
 em.close();
 }
 return new ArrayListJobCategory(); // Return empty list.
 }
 }


 When I call: 
 JobCategoryRequest jobCategoryReq = 
 this.requestFactory.jobCategoryRequest();
 RequestListJobCategoryProxy req = 
 jobCategoryReq.findAllJobCategories().with(*subCategories*);
 req.fire(receiver);

 ... The call will return categories but without subcatgeories. (The list 
 is always empty).
 I checked the DB, it is all fine there.

 Can it be that the Bug 6115 has not been fixed, even though its status 
 says so, or am I doing something wrong here?


 Have you checked whether the caller is called? if it is, does it return a 
 populated set?

 You're supposed to use an open-session-in-view (aka session-per-request) 
 pattern with RequestFactory, rather than creating/closing an EntityManager 
 in each service method. In this simple example (a single service method 
 call in the RequestContext, with no shared object between the request 
 –arguments– and the response), it shouldn't cause any harm *except* if 
 you lazy-load your linked entities.



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

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-14 Thread Joseph Lust

Seth,

Currently I can do this by setting ui:style 
 src='relativepath/MyCss.css in A and B and it works nicely, uibinder 
 takes care of injecting the styles and everything. However I'm not sure if 
 this is the best way. There's also the issue that if I move A and B then 
 the relative path breaks (since absolute paths still aren't 100% functional 
 issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).
  
 Does anyone have a clue or is this the preferred method?


You might want to look at this previous 
answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.
 
If you do the overriding in the Java class backing your UI binder, then the 
refactoring worries won't be a problem. You can still handle the 
refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice) 
to do FQN replacements in all .xml files.


Sincerely,
Joseph

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

Re: Best practices for inlining build (revision) number into GWT App?

2013-06-14 Thread Joseph Lust

Thanks for sharing. That's what I was using before. A real *chicken and the 
egg *problem while I sounds so simple in principle.

I've also pondered a direct string replacement against the compiles JS 
files (i.e. $$BUILD_NUMBER) with filters in the war building plugin 
as ostensibly strings are still the same string in the compiled JS, but 
that would not be nearly as dependable and could certainly blow up with 
future compiler changes.


Sincerely,
Joseph

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

Re: CodeMirror and GWT.

2013-06-14 Thread Joseph Lust

Håvard Moås, checkout the Chrome Markdown 
extensionhttps://chrome.google.com/webstore/detail/markdown-here/elifhakcjgalahccnjkneoccemfahfoa?hl=ento
 format code for these forums. :)

Sincerely,
Joseph



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

Is ValueProxy similar to AutoBean type object?

2013-06-14 Thread Yan

Hi,

With my GWT 2.5.1, I am revisit the way I am using EntityProxy. There is an 
existing post about a parent entity proxy holding a list of children entity 
proxy, changes in children in UI does not trigger an update in backend. 

So, I thought to change to use ValueProxy, that way, I do not have this 
problem, as everything is sent to server. There is not that much data, so 
it won't be a performance problem.

But, is not using AutoBean more straightforward?  Just define an interface, 
both client/server are serializing and unserializing the objects into JSON 
string. 

Is ValueProxy essentially the same as object being serialized using 
AutoBean?

Thanks,
Yan

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

Re: Uibinder inheriting and extending css classes (not just sharing them), best method?

2013-06-14 Thread GWTter

Hi Joseph,

Thanks for the reply. You're right and I actually do this elsewhere
extending cssresource interfaces and using the @shared which also works;
it's definitely the way to go for larger extensions/additions that aren't
as local.
However what I like about the ui:binder approach is you don't have to worry
about ensuring the styles are injected and less boilerplate to utilize the
cssresource (even though it's not THAT much of a hassle). The other really
nice thing is you can override/extend styles more easily with the approach
I described for local changes (at least in my opinion). That's why I just
wanted to see if there was a way to extend it without having to specify the
src like in the approach above, or if it's even recommended.

Thanks again,

-Seth

On Friday, June 14, 2013 6:01:12 PM UTC+2, Joseph Lust wrote:

Seth,

Currently I can do this by setting ui:style
src='relativepath/MyCss.css in A and B and it works nicely, uibinder
takes care of injecting the styles and everything. However I'm not sure if
this is the best way. There's also the issue that if I move A and B then
the relative path breaks (since absolute paths still aren't 100% functional
issue#7230http://code.google.com/p/google-web-toolkit/issues/detail?id=7230).

Does anyone have a clue or is this the preferred method?

You might want to look at this previous
answerhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/lust$20cssresource/google-web-toolkit/XDTiBioiIuo/ZFHeGB1jT0IJ.

If you do the overriding in the Java class backing your UI binder, then the
refactoring worries won't be a problem. You can still handle the
refactoring in UiBinder, but you'll have to set Eclipse (or IDE of choice)
to do FQN replacements in all .xml files.

Sincerely,
Joseph

Re: How to play audio from the jar?

2013-06-14 Thread Magnus

Hi Jens,

so the URL would be /audio/file.mp3? Where is the root?

And is mp3 a format that most browsers support?

Thanks
Magnus

Am Freitag, 14. Juni 2013 10:27:52 UTC+2 schrieb Jens:

 You either write a servlet that loads the mp3 from the jar and sends it to 
 the client or dont put your audio files into a jar file. If you put your 
 audio files in your war file, e.g. war/audio/file.mp3, then you can access 
 it just like any other html/js file from your war. You could also put them 
 in your app's public folder. Then, after GWT compilation, your audio files 
 will be in war/module-name/audiofile.mp3.

 -- J.


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

Re: Problem in sending large size of data from GWT client to server by cross domain scripting

2013-06-14 Thread Shashank Beerla

if u knw the answer y dont u give a detail procedure to follow instead 
scribblin somethin in vague

On Thursday, May 12, 2011 4:09:52 AM UTC-4, Thomas Broyer wrote:

 There are tricks using a hidden form (FormPanel in GWT), but well, they're 
 a bit hackish... (what's hackish is communicating the result back to your 
 app: you have to send a redirect to a page that's the same origin as the 
 app, and this will call 2 FormPanel.SubmitEvent to be fired; or you could 
 use the window.name trick...)
 Maybe not that helpful to you as i'm a bit vague, but the point is: yes, 
 it's possible.


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

[gwt-contrib] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...


Hello Thomas Broyer,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3211

to look at the new patch set (#3).

Change subject: FileUpload: extending FocusWidget instead of Widget so as  
it exposes many features which already are in the file-input element:  
click(), focus(), mouseevents, keyevents, etc.

..

FileUpload: extending FocusWidget instead of Widget so as it exposes
many features which already are in the file-input element: click(),
focus(), mouseevents, keyevents, etc.

Now it is possible open the file browser calling fileupload.click().
This allows customize widgets to upload files.
It works in almost supported browsers: IE6+, Chrome, Safari, FF (from 4.0)
and Opera (from 12).

Documented css rules noticing that browsers impose many constrains to
input file styling.

Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Bugs: issue 2262, issue 4078, issue 1998
---
M user/src/com/google/gwt/dom/client/DOMImplMozilla.java
M user/src/com/google/gwt/user/client/ui/FileUpload.java
M user/test/com/google/gwt/user/client/ui/ButtonTest.java
M user/test/com/google/gwt/user/client/ui/FileUploadTest.java
4 files changed, 78 insertions(+), 28 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Patrick Tucker tucker...@gmail.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 GWT 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]: FileUpload: extending FocusWidget instead of Widget so as it...


Hello Thomas Broyer,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3211

to look at the new patch set (#4).

Change subject: FileUpload: extending FocusWidget instead of Widget so as  
it exposes many features which already are in the file-input element:  
click(), focus(), mouseevents, keyevents, etc.

..

FileUpload: extending FocusWidget instead of Widget so as it exposes
many features which already are in the file-input element: click(),
focus(), mouseevents, keyevents, etc.

Now it is possible open the file browser calling fileupload.click().
This allows customize widgets to upload files.
It works in almost supported browsers: IE6+, Chrome, Safari, FF (from 4.0)
and Opera (from 12).

Documented css rules noticing that browsers impose many constrains to
input file styling.

Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Bugs: issue 2262, issue 4078, issue 1998
---
M user/src/com/google/gwt/dom/client/DOMImplMozilla.java
M user/src/com/google/gwt/user/client/ui/FileUpload.java
M user/test/com/google/gwt/user/client/ui/ButtonTest.java
M user/test/com/google/gwt/user/client/ui/FileUploadTest.java
4 files changed, 77 insertions(+), 27 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Patrick Tucker tucker...@gmail.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 GWT 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]: FileUpload: extending FocusWidget instead of Widget so as it...


Hello Thomas Broyer,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3211

to look at the new patch set (#5).

Change subject: FileUpload: extending FocusWidget instead of Widget so as  
it exposes many features which already are in the file-input element:  
click(), focus(), mouseevents, keyevents, etc.

..

FileUpload: extending FocusWidget instead of Widget so as it exposes
many features which already are in the file-input element: click(),
focus(), mouseevents, keyevents, etc.

Now it is possible open the file browser calling fileupload.click().
This allows customize widgets to upload files.
It works in almost supported browsers: IE6+, Chrome, Safari, FF (from 4.0)
and Opera (from 12).

Documented css rules noticing that browsers impose many constrains to
input file styling.

Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Bugs: issue 2262, issue 4078, issue 1998
---
M user/src/com/google/gwt/dom/client/DOMImplMozilla.java
M user/src/com/google/gwt/user/client/ui/FileUpload.java
M user/test/com/google/gwt/user/client/ui/FileUploadTest.java
3 files changed, 81 insertions(+), 31 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Patrick Tucker tucker...@gmail.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 GWT 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]: Use JSON.parse() instead of eval() to deserialize rpc callba...

2013-06-14 Thread Leif Åstrand


Leif Åstrand has posted comments on this change.

Change subject: Use JSON.parse() instead of eval() to deserialize rpc  
callback payload

..


Patch Set 11:

The existing test suite seems to have quite good coverage, but it does not  
help when it only tests the default protocol version, i.e. 7. All the  
problems I mentioned were discovered by changing the default protocol  
version to 8 and running the RPCSuite.


Vaadin has fixes for those problems in  
https://github.com/vaadin/gwt/commit/9c8f102265c032efc575ed3c070334bf57645aa3  
and  
https://github.com/vaadin/gwt/commit/d3914682163347a9eacee8d3b23e55e62b2a97ea.  
John A is currently on vacation and I won't have time to submit a new  
version here either because I'm leaving today.


--
To view, visit https://gwt-review.googlesource.com/2900
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I6062180397f5fabed1dd5f08140c2bd43a19fa9f
Gerrit-PatchSet: 11
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Artur Signell ar...@vaadin.com
Gerrit-Reviewer: Brian Slesinsky skybr...@google.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John Ahlroos j...@vaadin.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Leif Åstrand l...@vaadin.com
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 GWT 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


Manuel Carrasco Moñino has posted comments on this change.

Change subject: Adding a DOM clear method to RootPanel
..


Patch Set 7:

Sorry if I come later to this change, but I am wondering if Should'nt it  
preserve gwt specific iframes like #__gwtHistoryFrame or #moduleName ?


--
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: 7
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: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
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 GWT 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] Issue 8083, needs some input from GWT team

2013-06-14 Thread David

Hi,

Theoretically you are absolutely right. But practically is another
discussion, I am talking about thousands of lines that need to change just
for the GUI tier limitations. The GUI is just a fraction of the application
because the same Request/Response objects are used internally as well
(command pattern). Redesigning the entire application because of a
limitation of the GUI is nuts. But in the way we use BigInteger, I
understand your point of view.

But the same problem is there with BigDecimal (somebody else filled an
issue so I did not bother to create a duplicate, it is marked as assume
stale).

We show records with BigDecimal in Cell tables. Again RPC is slow here.
While the user will only click on certain records to make modifications.
Again I could refactor to wait with conversion to BigDecimal until the user
changes a value (to validate), but in this case BigDecimal was the right
data-type to use and it is not nice to have to redesign an application
because the RPC system of GWT has limitations.

David

On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote:

 I agree; this seems like a workaround for one application that picked the
 wrong datatype. Maybe we should warn about BigDecimal being slow somewhere?
 If someone wants to do some performance tests of GWT-RPC serialization,
 publishing the results would be useful to the community.

 My recommendation in this case would be create a new class named Id or
 Key that simply contains the BigDecimal, then modify the code to use it,
 then change the implementation to store the data in a string field instead.
 In the end you'll have more readable code.

 - Brian


 On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote:

 John,

 Well, if I don't have support for this patch then I better stop working
 on it. I can understand that this is not seen as a priority for GWT. Worst
 case I just replace the BigInteger/BigDecimal class in the project itself,
 that is basically what I did right now.

 Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27.
 The Oracle JDBC drivers return
 a BigInteger if you force it to the extremes.

 Changing the application is not feasible, that will be too much work, we
 are talking about many thousands of dependencies in a huge codebase where
 BigIntegers and BigDecimals are used - while handling this optimisation on
 the RPC level can be done in just a few lines of code.

 In many cases we send large lists of objects that contain BigInteger,
 BigDecimals but only a few will actually be interacted with. So in that
 case we only need to convert the Strings to BigInteger (or BigDecimal) when
 really needed.

 David

 On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote:

 On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote:

 The lazy parsing would only happen during deserialisation in the
 client. I think it is safe to assume that a BigInteger created through
 toString on the server will not result in a parse exception in the client
 code - or are there known incompatibilities ?

 I don't want that the regular constructor of BigInteger( String ) or
 BigInteger( String, int) would behave differently than before. Not even in
 the client when those BigInts are created in the client. That's why I was
 asking about the possibility to have different serialisers on client and
 server side.

 As the why, well currently the custom field serializer converts the
 BigInteger to a String, the client side needs to parse the string and
 convert it to an int array, which involves multiple substring,
 Integer.parseInt and multiply and add operations. Somehow IE8 has a problem
 with this. IE9 and other browsers are more efficient, but still that is a
 lot of CPU operations that can be avoided in my use case.

 In my particular use case they used BigInteger to represent a key in
 the database (oracle uses sequence numbers that are bigger than what can be
 represented with long). That might have not been the best idea, but those
 decisions have been made a long time ago, when I was not around. On the
 server side there is a usage of equals and compareTo happening, which would
 be hard to implement without a BigInteger, so there is logic in the choice.
 They obviously don't want to have an extra layer of objects to avoid the
 BigInteger in the GWT client since a lot of code is independent of client
 or server, this would hinder code sharing between the tiers.

 On the client side these id's are only send forth and back between
 client and server, no operation is ever performed, so making the custom
 field serialiser and the BigInteger cooperate gives a big performance
 improvement. They only operation needed on the client-side is equals,
 which can also be optimized to do a String comparison when bother have not
 been parsed after RPC.

 
 I'm beginning to think such a change does not belong in GWT.  In your
 example, wouldn't you be better served by only

[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 7:

@Manuel good catch.

We do not need to care about the History Frame (I looked it up before  
submitting the patch), but we care about the iframe with code, especially  
when using Async Loading, because then we still need the frame.


I will follow up with a new patch addressing the bug issue 8200 I just  
filed.


--
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: 7
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: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframei


Daniel Kurka has uploaded a new change for review.

  https://gwt-review.googlesource.com/3430


Change subject: making RootPanel.clear(true) respects GWT loader iframei
..

making RootPanel.clear(true) respects GWT loader iframei

fixes issue 8200

Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
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, 49 insertions(+), 2 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 c4929c6..6cf2e06 100644
--- a/user/src/com/google/gwt/user/client/ui/RootPanel.java
+++ b/user/src/com/google/gwt/user/client/ui/RootPanel.java
@@ -15,11 +15,13 @@
  */
 package com.google.gwt.user.client.ui;

+import com.google.gwt.core.client.GWT;
 import com.google.gwt.core.client.impl.Disposable;
 import com.google.gwt.core.client.impl.Impl;
 import com.google.gwt.dom.client.BodyElement;
 import com.google.gwt.dom.client.Document;
 import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.Node;
 import com.google.gwt.event.logical.shared.CloseEvent;
 import com.google.gwt.event.logical.shared.CloseHandler;
 import com.google.gwt.i18n.client.BidiUtils;
@@ -28,8 +30,10 @@
 import com.google.gwt.user.client.Event;
 import com.google.gwt.user.client.Window;

+import java.util.ArrayList;
 import java.util.HashMap;
 import java.util.HashSet;
+import java.util.List;
 import java.util.Map;
 import java.util.Set;

@@ -317,10 +321,32 @@
 clear();

 if (clearDom) {
-  com.google.gwt.user.client.Element containerElement = getElement();
+  ListNode nodesToReAttach = new ArrayListNode();
+  Element containerElement = getElement();
   while (containerElement.hasChildNodes()) {
-containerElement.removeChild(containerElement.getFirstChild());
+Node child = containerElement.getFirstChild();
+
+if (!shouldNodeBeRemoved(child)) {
+  nodesToReAttach.add(child);
+}
+containerElement.removeChild(child);
+  }
+
+  for (Node node : nodesToReAttach) {
+containerElement.appendChild(node);
   }
 }
   }
+
+  private boolean shouldNodeBeRemoved(Node child) {
+if (Element.is(child)) {
+  Element childElement = (Element) child;
+  // do not remove GWT's iframe that is used for loading code
+  if (iframe.equalsIgnoreCase(childElement.getTagName())
+   GWT.getModuleName().equals(childElement.getId())) {
+return false;
+  }
+}
+return true;
+  }
 }
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 d455bd1..5a3ad2e 100644
--- a/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
+++ b/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
@@ -15,6 +15,7 @@
  */
 package com.google.gwt.user.client.ui;

+import com.google.gwt.core.client.GWT;
 import com.google.gwt.dom.client.DivElement;
 import com.google.gwt.dom.client.Document;
 import com.google.gwt.dom.client.Element;
@@ -69,6 +70,26 @@
 assertEquals(0, rootPanel.getElement().getChildCount());
   }

+  public void testClearRootPanelWithGWTFrame() {
+
+RootPanel rootPanel = createDOM(testClearRootPanel);
+
+rootPanel.add(new Button(a));
+rootPanel.add(new Button(b));
+
+rootPanel.clear(true);
+assertEquals(0, rootPanel.getElement().getChildCount());
+
+Element iFrame = DOM.createIFrame();
+iFrame.setId(GWT.getModuleName());
+rootPanel.getElement().appendChild(iFrame);
+
+assertEquals(1, rootPanel.getElement().getChildCount());
+
+rootPanel.clear(true);
+assertEquals(1, rootPanel.getElement().getChildCount());
+  }
+
   public void testClearRootPanelContainingTextNodes() {

 RootPanel rootPanel = createDOM(testClearRootPanelAndDOM);

--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newchange
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
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 GWT 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] Manuel (google-web-toolkit-contributors@googlegroups.com)

2013-06-14 Thread Daniel Kurka (Google Drive)


I've shared an item with you:

Manuel
https://docs.google.com/document/d/1-y6jum0PO7rRqLu7IBtm1PKxJ21eGlIXl_XDjz2NNcc/edit?usp=sharing

It's not an attachment -- it's stored online. To open this item, just click  
the link above.


--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 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]: making RootPanel.clear(true) respects GWT loader iframei


Manuel Carrasco Moñino has posted comments on this change.

Change subject: making RootPanel.clear(true) respects GWT loader iframei
..


Patch Set 1:

(2 comments)


File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
Why are you maintaining a list with this nodes?, I think you just skip them  
instead of detaching reataching

if (shouldNodeBeRemoved()) {
  containerElement.removeChild()
}


Line 346:GWT.getModuleName().equals(childElement.getId())) {
What about the __gwtHistoryFrame, it is still being used in IE6 History. I  
think if we remove it we will break History in this permutation.

I know we are getting rid of IE6 in future releases though.


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframei


Daniel Kurka has posted comments on this change.

Change subject: making RootPanel.clear(true) respects GWT loader iframei
..


Patch Set 1:

(2 comments)


File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
If I don't remove them we will see the same node in the next iteration and  
since iterating this way is the fastest way to do it. I am okay with  
reatttaching an element.



Line 346:GWT.getModuleName().equals(childElement.getId())) {
You are right this will break IE6 History, but I am not willing to add  
extra complexity just to keep IE6 happy, since this will get released with  
GWT 2.6, its fine.



--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframei


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3430

to look at the new patch set (#2).

Change subject: making RootPanel.clear(true) respects GWT loader iframei
..

making RootPanel.clear(true) respects GWT loader iframei

fixes issue 8200

Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
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, 49 insertions(+), 2 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 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]: making RootPanel.clear(true) respects GWT loader iframe


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3430

to look at the new patch set (#3).

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..

making RootPanel.clear(true) respects GWT loader iframe

fixes issue 8200

Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
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, 49 insertions(+), 2 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 3
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 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]: making RootPanel.clear(true) respects GWT loader iframe

2013-06-14 Thread Thomas Broyer


Thomas Broyer has posted comments on this change.

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..


Patch Set 1:

(1 comment)


File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
Deattaching/reattaching an iframe should result in reloading its page, and  
I don't think that's what we want:


 When an iframe element is inserted into a document, the user agent must  
create
 a nested browsing context, and then process the iframe attributes for the  
first

 time.

 When an iframe element is removed from a document, the user agent must
 discard the nested browsing context.

 This happens without any unload events firing (the nested browsing context  
and

 its Document are discarded, not unloaded).

— Source:  
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element


Because it's only about one element (for now, but it should remain only a  
handful elements in the future at most), and it's inserted at the end of  
the body (well, OK, the module could then add other elements after that,  
but the original purpose of clearDom was to clear everything on load), how  
about skipping it in each iteration? Would it really slow down things?


 while (containerElement.hasChildNodes()) {
   Node child = containerElement.getFirstChild();
   while (!shouldNodeBeRemoved(child)) {
 child = child.getNextSibling();
   }
   containerElement.removeChild(child);
 }

Also, is there really a big difference between hasChildNodes/getFirstChild  
and igetChildCount()/getChild(i) ? (and one that matters here, because I  
don't expect clearDom to be used that much, and in 99% of the cases it'll  
be used to remove a loading message, so losing a few milliseconds  
wouldn't really matter as the loading message would still be visible in  
the interim)


Another alternative would be to search for the first node that we want to  
keep and remove everything before it, and repeat that process until we  
reached the last child node. Or even better, mix getFirstChild and  
getNextSibling to really walk the DOM, skipping the appropriate nodes:


 Node child = containerElement.getFirstChild();
 while (child != null) {
   Node next = child.getNextSibling();
   if (shouldNodeBeRemoved(child)) {
 containerElement.removeChild(child);
   }
   child = next;
 }


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframe


Hello Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3430

to look at the new patch set (#4).

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..

making RootPanel.clear(true) respects GWT loader iframe

fixes issue 8200

Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
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, 43 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframe

2013-06-14 Thread Thomas Broyer


Thomas Broyer has posted comments on this change.

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..


Patch Set 4: Code-Review+1

(1 comment)


File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 338:   if (iframe.equalsIgnoreCase(childElement.getTagName())
Ah sorry, missed it the first time: use  
childElement.hasTagName(IFrameElement.TAG)



--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframe


Hello Thomas Broyer, Leeroy Jenkins,

I'd like you to reexamine a change.  Please visit

https://gwt-review.googlesource.com/3430

to look at the new patch set (#5).

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..

making RootPanel.clear(true) respects GWT loader iframe

fixes issue 8200

Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
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, 44 insertions(+), 3 deletions(-)


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.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 GWT 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]: making RootPanel.clear(true) respects GWT loader iframe


Daniel Kurka has posted comments on this change.

Change subject: making RootPanel.clear(true) respects GWT loader iframe
..


Patch Set 4:

(1 comment)


File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 338:   if (iframe.equalsIgnoreCase(childElement.getTagName())
Done


--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.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 GWT 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] Issue 8083, needs some input from GWT team

2013-06-14 Thread Brian Slesinsky

Okay, fair enough. Making BigDecimal deserialize faster would certainly be
a good thing. I just don't want it to result in hard-to-diagnose errors if
there's some kind of mismatch between client and server. If there's any
difference then we should probably have a configuration property or an
annotation on the remote service interface to turn laziness on.



On Fri, Jun 14, 2013 at 1:02 AM, David david.no...@gmail.com wrote:

 Hi,

 Theoretically you are absolutely right. But practically is another
 discussion, I am talking about thousands of lines that need to change just
 for the GUI tier limitations. The GUI is just a fraction of the application
 because the same Request/Response objects are used internally as well
 (command pattern). Redesigning the entire application because of a
 limitation of the GUI is nuts. But in the way we use BigInteger, I
 understand your point of view.

 But the same problem is there with BigDecimal (somebody else filled an
 issue so I did not bother to create a duplicate, it is marked as assume
 stale).

 We show records with BigDecimal in Cell tables. Again RPC is slow here.
 While the user will only click on certain records to make modifications.
 Again I could refactor to wait with conversion to BigDecimal until the user
 changes a value (to validate), but in this case BigDecimal was the right
 data-type to use and it is not nice to have to redesign an application
 because the RPC system of GWT has limitations.

 David


 On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky skybr...@google.comwrote:

 I agree; this seems like a workaround for one application that picked the
 wrong datatype. Maybe we should warn about BigDecimal being slow somewhere?
 If someone wants to do some performance tests of GWT-RPC serialization,
 publishing the results would be useful to the community.

 My recommendation in this case would be create a new class named Id or
 Key that simply contains the BigDecimal, then modify the code to use it,
 then change the implementation to store the data in a string field instead.
 In the end you'll have more readable code.

 - Brian


 On Thu, Jun 13, 2013 at 12:03 PM, David david.no...@gmail.com wrote:

 John,

 Well, if I don't have support for this patch then I better stop working
 on it. I can understand that this is not seen as a priority for GWT. Worst
 case I just replace the BigInteger/BigDecimal class in the project itself,
 that is basically what I did right now.

 Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27.
 The Oracle JDBC drivers return
 a BigInteger if you force it to the extremes.

 Changing the application is not feasible, that will be too much work, we
 are talking about many thousands of dependencies in a huge codebase where
 BigIntegers and BigDecimals are used - while handling this optimisation on
 the RPC level can be done in just a few lines of code.

 In many cases we send large lists of objects that contain BigInteger,
 BigDecimals but only a few will actually be interacted with. So in that
 case we only need to convert the Strings to BigInteger (or BigDecimal) when
 really needed.

 David

 On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin j...@jaet.org wrote:

 On Thu, Jun 13, 2013 at 3:14 AM, David david.no...@gmail.com wrote:

 The lazy parsing would only happen during deserialisation in the
 client. I think it is safe to assume that a BigInteger created through
 toString on the server will not result in a parse exception in the client
 code - or are there known incompatibilities ?

 I don't want that the regular constructor of BigInteger( String ) or
 BigInteger( String, int) would behave differently than before. Not even in
 the client when those BigInts are created in the client. That's why I was
 asking about the possibility to have different serialisers on client and
 server side.

 As the why, well currently the custom field serializer converts the
 BigInteger to a String, the client side needs to parse the string and
 convert it to an int array, which involves multiple substring,
 Integer.parseInt and multiply and add operations. Somehow IE8 has a 
 problem
 with this. IE9 and other browsers are more efficient, but still that is a
 lot of CPU operations that can be avoided in my use case.

 In my particular use case they used BigInteger to represent a key in
 the database (oracle uses sequence numbers that are bigger than what can 
 be
 represented with long). That might have not been the best idea, but those
 decisions have been made a long time ago, when I was not around. On the
 server side there is a usage of equals and compareTo happening, which 
 would
 be hard to implement without a BigInteger, so there is logic in the 
 choice.
 They obviously don't want to have an extra layer of objects to avoid the
 BigInteger in the GWT client since a lot of code is independent of client
 or server, this would hinder code sharing between the tiers.

 On the client side these id's are only send forth

[gwt-contrib] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...

2013-06-14 Thread Matthew Dempsky


Matthew Dempsky has posted comments on this change.

Change subject: FileUpload: extending FocusWidget instead of Widget so as  
it exposes many features which already are in the file-input element:  
click(), focus(), mouseevents, keyevents, etc.

..


Patch Set 5:

(2 comments)


File user/src/com/google/gwt/user/client/ui/FileUpload.java
Line 44:  * The developer should be aware that most browsers do not allow  
to style
do not allow to style here sounds funny to me.  Maybe do not allow  
styling?



Line 209:   public void click() {
Is click the best name for this method?  Maybe something more explicitly  
explaining why the user would want to call it,  
like openFileSelectionDialog()?



--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Manuel Carrasco Moñino manuel.carrasc...@gmail.com
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Patrick Tucker tucker...@gmail.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 GWT 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]: Ensure clinits get called for JSO instance methods.

2013-06-14 Thread Matthew Dempsky


Matthew Dempsky has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(3 comments)


File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49:   static final class ClinitStaticFieldFirst extends  
JavaScriptObject {
You have three identical class definitions here.  I suspect that's because  
you have multiple test scenarios, and clinits aren't undoable.  It would be  
nice to have a comment explaining that, so people don't come later on and  
think they can refactor the code and eliminate the extra tests. :)



Line 54:   if (FIELD == null) {
What's the point of all these 'if' statements?  It looks like you should be  
able to eliminate them.


If they're necessary, can you please add a comment explaining why?


Line 84:   static final class ClinitStaticMethodFirst extends  
JavaScriptObject {

Nit: Blank line before new class definition.


--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@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 GWT 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]: Ensure clinits get called for JSO instance methods.

2013-06-14 Thread Colin Alworth


Colin Alworth has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2:

(2 comments)


File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49:   static final class ClinitStaticFieldFirst extends  
JavaScriptObject {

Correct - the commit message documents this, but I'll stick a comment too.


Line 54:   if (FIELD == null) {
Again, commit message touched on it. The bug only manifests in compiled  
code, and the compiler will inline this if it is too simple. I was going  
for the simplest code I could write that would not be optimized out (at  
least in draft mode) without using JSNI. Not that there is an issue with  
JSNI here, just that I wanted to keep the issue on track for following Java  
semantics. Once the method gets inlined, the bug goes away, since the  
outside code is accessing the field, and any static field access requires a  
clinit (which the compiler doesn't forget before this patch).



--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@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 GWT 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] Work to do for bug 3042

2013-06-14 Thread Brian Slesinsky

Another possibility would be to develop a nicer GWT RichTextArea as a
separate open source project. There's no reason it has to be in core GWT
right away and you'll be able to work faster that way. With real-world
usage, you'll probably learn a few things that will make it better quality
if we do merge it back to core later.

However, if you have to patch GWT to make it work, that is the sort of
thing that should be contributed back to GWT.

On Thu, Jun 13, 2013 at 10:03 PM, Manuel Carrasco Moñino
man...@apache.orgwrote:

 In my opinion, having the tool-bar in gwt makes perfectly sense,
 RichTextArea is almost unusable without a bar in any project. It's
 plenty of gwt projects which have copied and pasted the code from the
 showcase.

 I think that you should face this issue in some steps:
 1.- Listen to GWT contributors for the convenience of moving
 RichTextToolbar from samples to gwt. So maintain live this thread
 until you get enough feedback.
 2.- Send a first patch just moving the code from show-case to gwt
 (showcase should use the new code)
 3.- When the patch were accepted, continue adding other features like
 adding/removing widgets from the toolbar, or a panel grouping
 RichTextArea + RichTextToolbar, etc. because each thing needs a
 different review/discussion.

 - Manolo

 On Tue, Jun 11, 2013 at 7:25 PM, Adolfo Panizo Touzon
 adolfo.pan...@gmail.com wrote:
  Oh! Sorry I saw you were the owner and I thought you had plenty of
  responsability.
 
  Thanks, but everything is fine, the installation process is quite
  simple/clear, so, all is up  and running. :D.
 
  Keep an eye into the Issue 1127 because maybe you are interested in
 giving
  instructions related to both issues.
 
  Thanks,
 
  Adolfo.
 
 
  On Tue, Jun 11, 2013 at 10:28 AM, Daniel Kurka danku...@google.com
 wrote:
 
  Hi Adolfo,
 
  this is not my issue and I am not solely responsible for it.
 
  We should see wait and see if anybody opposes to adding this to GWT,
  before you actually start working on it, so that your time will not be
  wasted.
  On the other hand you can already setup your IDE and tools to be able to
  start. James pointed out the resources. If there is anything wrong /
 unclear
  in those resources please let us know. Or you could even send a patch
 for
  the homepage to be updated.
 
  - Daniel
 
 
  On Mon, Jun 10, 2013 at 8:07 PM, Adolfo Panizo Touzon
  adolfo.pan...@gmail.com wrote:
 
  Thanks James!
 
  But I have done those steps yet (indeed I read in that link I should
 ask
  here first :D) . When I said the necessary work I meant the steps for
  develop the RichTextArea according to the GWT steering committee (for
 this
  issue I think Daniel is responsible) so I need to wait for his opinion.
 
  Thanks anyway for your quick response.
 
  Adolfo.
 
 
  On Mon, Jun 10, 2013 at 1:02 PM, James Horsley 
 james.hors...@gmail.com
  wrote:
 
  Adolfo,
 
  To get the source checked out and compiling follow:
  http://www.gwtproject.org/makinggwtbetter.html#workingoncode
 
  To submit the patch use:
  http://www.gwtproject.org/makinggwtbetter.html#submittingpatches
 
  I recently had to move an old svn patch into gerrit and the following
  gave a very simple way to apply it
 
 http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-gitjust
  remember to clean up any leftover .orij and .rej files.
 
  Cheers,
  James
 
 
  On 10 June 2013 10:01, Adolfo Panizo adolfo.pan...@gmail.com wrote:
 
  Hi,
 
  as I wrote in the issue, I am able to do the necessary work for
 solving
  it.  So, can you guide me about the steps that I need to follow in
 order to
  create a patch properly?
 
  Would you like to reuse some code of the old patch?
 
  I am going to contact the creator of it because maybe he continues
  interested on fixing the issue and rebase the patch with the last
 code.
 
  Of course if there are other issues related to RichTextArea I can
 solve
  as well.
 
  Thanks in advance,
 
  Adolfo.
 
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors
  ---
  You received this message because you are subscribed to the Google
  Groups GWT 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 GWT 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.
 
 
 
 
 
 
  --
  El precio es lo que pagas. El valor es lo que recibes.
  Warren Buffet
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors
  ---
  You received this message because you are

[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.

2013-06-14 Thread Roberto Lublinerman


Roberto Lublinerman has posted comments on this change.

Change subject: Ensure clinits get called for JSO instance methods.
..


Patch Set 2: Code-Review+1

(1 comment)


File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
Line 172:   if (program.isStaticImpl(x.getTarget())  
 !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
Is the extra condition needed? I am not too familiar with how the compiler  
handles JSOs but it seems odd to me that statified methods are treated  
differently.



--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings

Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: John A. Tamplin j...@jaet.org
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Matthew Dempsky mdemp...@google.com
Gerrit-Reviewer: Roberto Lublinerman rlu...@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 GWT 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] Work to do for bug 3042

2013-06-14 Thread Goktug Gokdogan

Agreed. We don't need to provide a complex RichTextArea for GWT out of the
box.
It makes sense to quickly iterate on it in a different open source project.
In the meantime, if you end up having small patches to improve the existing
one in GWT, feel free to send them.


On Fri, Jun 14, 2013 at 3:34 PM, Brian Slesinsky skybr...@google.comwrote:

 Another possibility would be to develop a nicer GWT RichTextArea as a
 separate open source project. There's no reason it has to be in core GWT
 right away and you'll be able to work faster that way. With real-world
 usage, you'll probably learn a few things that will make it better quality
 if we do merge it back to core later.

 However, if you have to patch GWT to make it work, that is the sort of
 thing that should be contributed back to GWT.

 On Thu, Jun 13, 2013 at 10:03 PM, Manuel Carrasco Moñino 
 man...@apache.org wrote:

 In my opinion, having the tool-bar in gwt makes perfectly sense,
 RichTextArea is almost unusable without a bar in any project. It's
 plenty of gwt projects which have copied and pasted the code from the
 showcase.

 I think that you should face this issue in some steps:
 1.- Listen to GWT contributors for the convenience of moving
 RichTextToolbar from samples to gwt. So maintain live this thread
 until you get enough feedback.
 2.- Send a first patch just moving the code from show-case to gwt
 (showcase should use the new code)
 3.- When the patch were accepted, continue adding other features like
 adding/removing widgets from the toolbar, or a panel grouping
 RichTextArea + RichTextToolbar, etc. because each thing needs a
 different review/discussion.

 - Manolo

 On Tue, Jun 11, 2013 at 7:25 PM, Adolfo Panizo Touzon
 adolfo.pan...@gmail.com wrote:
  Oh! Sorry I saw you were the owner and I thought you had plenty of
  responsability.
 
  Thanks, but everything is fine, the installation process is quite
  simple/clear, so, all is up  and running. :D.
 
  Keep an eye into the Issue 1127 because maybe you are interested in
 giving
  instructions related to both issues.
 
  Thanks,
 
  Adolfo.
 
 
  On Tue, Jun 11, 2013 at 10:28 AM, Daniel Kurka danku...@google.com
 wrote:
 
  Hi Adolfo,
 
  this is not my issue and I am not solely responsible for it.
 
  We should see wait and see if anybody opposes to adding this to GWT,
  before you actually start working on it, so that your time will not be
  wasted.
  On the other hand you can already setup your IDE and tools to be able
 to
  start. James pointed out the resources. If there is anything wrong /
 unclear
  in those resources please let us know. Or you could even send a patch
 for
  the homepage to be updated.
 
  - Daniel
 
 
  On Mon, Jun 10, 2013 at 8:07 PM, Adolfo Panizo Touzon
  adolfo.pan...@gmail.com wrote:
 
  Thanks James!
 
  But I have done those steps yet (indeed I read in that link I should
 ask
  here first :D) . When I said the necessary work I meant the steps for
  develop the RichTextArea according to the GWT steering committee (for
 this
  issue I think Daniel is responsible) so I need to wait for his
 opinion.
 
  Thanks anyway for your quick response.
 
  Adolfo.
 
 
  On Mon, Jun 10, 2013 at 1:02 PM, James Horsley 
 james.hors...@gmail.com
  wrote:
 
  Adolfo,
 
  To get the source checked out and compiling follow:
  http://www.gwtproject.org/makinggwtbetter.html#workingoncode
 
  To submit the patch use:
  http://www.gwtproject.org/makinggwtbetter.html#submittingpatches
 
  I recently had to move an old svn patch into gerrit and the following
  gave a very simple way to apply it
 
 http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-gitjust
  remember to clean up any leftover .orij and .rej files.
 
  Cheers,
  James
 
 
  On 10 June 2013 10:01, Adolfo Panizo adolfo.pan...@gmail.com
 wrote:
 
  Hi,
 
  as I wrote in the issue, I am able to do the necessary work for
 solving
  it.  So, can you guide me about the steps that I need to follow in
 order to
  create a patch properly?
 
  Would you like to reuse some code of the old patch?
 
  I am going to contact the creator of it because maybe he continues
  interested on fixing the issue and rebase the patch with the last
 code.
 
  Of course if there are other issues related to RichTextArea I can
 solve
  as well.
 
  Thanks in advance,
 
  Adolfo.
 
 
  --
  http://groups.google.com/group/Google-Web-Toolkit-Contributors
  ---
  You received this message because you are subscribed to the Google
  Groups GWT 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 GWT Contributors group.
  To unsubscribe from this group and stop receiving emails from it,
 send
  an

[gwt-contrib] Working on a patch to fix Exception wrapping/unwrapping in compiler

2013-06-14 Thread Goktug Gokdogan

I just wanted to give you a heads up that Roberto and I are working on a
compiler patch so that catch statement will not break js originated
exceptions.

To give you some background, if you put any try/catch statement in Java, js
originated exceptions will be converted into JavaScriptException even if
you are not catching a JavaScriptException or any of its parents.
Because of this problem there are workarounds in SDK to avoid catch
statements if there are no UncaughtExceptionHandlers registered. By
avoiding catch statements and repeating code, we are making sure a js
exception can correctly escape and reported by the browser.

Also with this patch, we can make some exceptions escape to the
browser asynchronously without breaking the code flow. This is useful to
fix problems like issue #6833 and similar others in the SDK.

-- 
http://groups.google.com/group/Google-Web-Toolkit-Contributors
--- 
You received this message because you are subscribed to the Google Groups GWT 
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]: FileUpload: extending FocusWidget instead of Widget so as it...