Re: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
well well, 4 years later, I came across the same problem. here's my solution: open regedit.exe ( really hate Microsoft and their regedit.reg). change the permission of key: HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft.Right click the icon, then change the permission to full operation. On Saturday, June 27, 2009 3:03:20 PM UTC-4, Farinha wrote: The subject has it all. Eclipse 3.4.2 GWT Eclipse Plugin Windows 7 Thanks in advance for the help. -- 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 2.4 Validation Tool not picking up @ExtraTypes on superclasses
I have a related follow-up question. I was getting a stack overflow at runtime because of the polymorphic hierarchy and was not using @ExtraTypes. My hierarchy was 3 levels deep. Top level is GenericType, next level is CategoryType and EventType, and next level is four subtypes of CategoryType and 4 subtypes of EventType. I finally got it working by putting @ExtryTypes in my request factory. It only worked when I put the @ExtraTypes with the full list of 10 types above GenericType. Initially I had tried to put @ExtraTypes with just 2 types above GenericType and @ExtraTypes with 4 types each above CategoryType and EventType. This did not work. Is this how it is intended to work? A related question. At one point I download all GenericTypes in the datastore (I use Objectify) and I want to see which of the lowest 8 types a particular entity is. I am currently comparing the String of the class I am looking for with substring of the class name of the GenericType. When I do getClass().getName() on the GenericType, returned from the datastore, I get something like: com.packagename.shared.proxy.LevelThreeTypeProxyAutoBean_com_google_web_bindery_requestfactory_shared_impl_EntityProxyCategory_com_google_web_bindery_requestfactory_shared_impl_ValueProxyCategory_com_google_web_bindery_requestfactory_shared_impl_BaseProxyCategory$1 If I am trying to see if this is a 'com.packagename.shared.proxy.LevelThreeTypeProxy', i compare that string to the left substring with length of whatever the fully qualified name I'm looking for is. Is there a better way to do this? Thanks, Jonathan On Saturday, February 23, 2013 6:33:55 AM UTC-5, Thomas Broyer wrote: On Saturday, February 23, 2013 5:20:23 AM UTC+1, Bademus ᵗʰᵉ wrote: It seems that GenTool goes into infinite loop again Version: gwt 2.5.1-rc1 Code: public interface EntityBaseProxy extends EntityProxy { ... } @ExtraTypes(AuthorProxy.class) public interface UserProxy extends EntityBaseProxy { ... } public interface AuthorProxy extends UserProxy { ... } It's no news actually (and Brad was right, and I was wrong): https://code.google.com/p/google-web-toolkit/issues/detail?id=6912 Workaround: don't put @ExtraTypes on the super-interface of the extra interfaces (e.g. move @ExtraTypes to a RequestContext) -- 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
Jens, 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. David On Thu, Jun 13, 2013 at 9:46 PM, Jens jens.nehlme...@gmail.com 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. -- 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: How to play audio from the jar?
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
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
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
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 ?
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
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?
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 ?
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 ?
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 ?
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 ?
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). -- 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 ?
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). -- 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 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: RequestFactory Issue 6115
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?
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?
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.
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?
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?
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 -- 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: How to play audio from the jar?
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
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...
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
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)
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
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
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
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...
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.
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.
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
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.
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
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
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...
Manuel Carrasco Moñino 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: (1 comment) File user/src/com/google/gwt/user/client/ui/FileUpload.java Line 209: public void click() { click() is the name we use in other widgets (inputs, button, submit), so I think we should use the same to be coherent. I think developers know that click does a different thing in different elements, and the expected behavior in file-input is open the file dialog. -- 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.