Re: How to play audio from the jar?
Hi Magnus, Am 15.06.2013 03:58, schrieb Magnus: so the URL would be /audio/file.mp3? Where is the root? http-root per Webapp is in the directory war of a GWT-project. The URL Jens provided as example for a file residing in war/audio/ missed the audio-directory, so the complete URL would be http://server/module-name/audio/file.mp3. The program base URL can be got by calling GWT.getModuleBaseURL() so you can create the URL with GWT.getModuleBaseURL() + audio/file.mp3 so you don't need to hardwire the names in your source. And is mp3 a format that most browsers support? No, but what formats are supported wasn't your question so Jens used a common format as example. I suppose you look at the doumentation of the class you want to use, what formats can be used. Regards, Lothar -- 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?
And is mp3 a format that most browsers support? To support all browsers that support HTML 5 audio you would need mp3 as well as ogg. Browser support for HTML 5 audio: http://caniuse.com/#search=audio Audio formats: http://www.w3schools.com/html/html5_audio.asp -- 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: Uibinder inheriting and extending css classes (not just sharing them), best method?
I might be way off here, but is there any reason to extend myTestClass at
all? You can have multiple css classes per element, so simply doing:
ui:style
.myLOCALTestClass{ ...more properties specific for this binder...}
/ui:style
And then assigning both myTestClass and myLOCALTestClass to the element
should have the local specific changes overwriting the global ones.
On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:
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: Uibinder inheriting and extending css classes (not just sharing them), best method?
Hi Ryan,
I don't think you're way off, this is definitely a way to do it but there
are a few caveats.
You have to consider that in order to do it this way (assuming you're style
is coming from another cssresource) you would have to:
- declare the cssresource that had the original style via ui:with and then
make sure it is injected since uibinder only takes care of injecting the
ui:style.
- (maintainability): you would have to make sure to set all the styles that
were set on the object originally (or any future ones if other classes are
added) including your new extension since setStyleName would clear them all
out (this would make your local style less maintainable and have to know
more about the external one than just what it wanted to extend). With the
extension approach even if the original style is deleted the local
extension would still apply with no errors.
These were the things I was trying to avoid with this approach. Either way
thanks for your reply, it should help clarify options.
-Seth
On Saturday, June 15, 2013 3:35:25 PM UTC+2, RyanZA wrote:
I might be way off here, but is there any reason to extend myTestClass at
all? You can have multiple css classes per element, so simply doing:
ui:style
.myLOCALTestClass{ ...more properties specific for this binder...}
/ui:style
And then assigning both myTestClass and myLOCALTestClass to the element
should have the local specific changes overwriting the global ones.
On Saturday, June 15, 2013 2:59:35 AM UTC+2, GWTter wrote:
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: WARNING: Could not open/create prefs root node Software\JavaSoft\Prefs at root 0x80000002. Windows RegCreateKeyEx(...) returned error code 5.
Just had the same problem myself, and found that to fix it I had to do what you suggested, but I also had to manually create a Prefs key under JavaSoft too, as mentioned here: http://www-01.ibm.com/support/docview.wss?uid=swg21496098 On Friday, 14 June 2013 02:02:26 UTC+1, QingFeng Du wrote: 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.
AWS (CDN) GWT file deployment and 'Blocked a frame with origin' issue
Hey All, I know there have been manyhttps://groups.google.com/forum/?fromgroups#!topic/Google-Web-Toolkit/PAaDf7a_5zI CDNhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/cdn/google-web-toolkit/kuyQU4y0RTo/vDLANu9os2kJ relatedhttps://groups.google.com/forum/?fromgroups#!searchin/google-web-toolkit/cdn/google-web-toolkit/IHf6BPFUWWw/MU5Yh0vdWSAJquestions here before, but I found no answers for this problem. So here are the constraints: - Serve all RPC calls and index.html from EC2 site (i.e. www.site.com) - Serve everything else from CloudFront CDN (i.e. static.site.com) - Use GWTP with code splitting (so no XS Linker) - Use SSL for thinks like login So, if you do this, you'll get the Blocked a frame with origin http://static.site.com; from accessing a frame with origin http://www.site.com http://localhost/. Protocols, domains, and ports must match To my knowledge CORS does not help with this. CORS is for XHR requests, not frames. Sadly I cannot just put index.html on the CDN and use passthrough for RPC's with CORS because CDN entries should be uniquely names, otherwise you must invalidate them and this will cause inconsistencies during deployment untli all 34 edge nodes eventually sync up (15min to 2 hours). Additionally, named SSL was just supported on Wednesdayhttp://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html at a cost of $600/mo, otherwise the site can only be served from a very ugly CF URL. That's is too pricey for most anyone. So, is there anyway to serve all the static files from a CDN with the index.html on another domain without using the XS linker (to retain code splitting)? Thanks for your wisdom. I've been scraping scripts together to get this whole deployment automated and will put it all into a GWT on AWS post when we're finally deployed. 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: AWS (CDN) GWT file deployment and 'Blocked a frame with origin' issue
Made progress, but the GWTP app is acting flaky after any
deferredjs/hash/number.cache.js file is loaded. The error implied the
functions being called are not in scope. The file is loaded and the request
had the expected payload.
So, curious if anyone has run GWTP or similar split apps with the XS linker
*Steps taken to get things jiving*
1. I kicked on the XS linker in hopes code splitting would work with it.
Needs more help, but this gets around frame security warnings.
2. RPC Asyncs kept pointing to the CDN, so I added the below to the RPC
Asyncs
public static final PublicServiceAsync getInstance() {
if (instance == null) {
instance = (PublicServiceAsync) GWT.create(PublicServiceAsync.class);
ServiceDefTarget serviceDefTarget = ((ServiceDefTarget) instance);
String address = BrowserUtil.getHostpageUrl();
String oldUrl = serviceDefTarget.getServiceEntryPoint();
// if we're not local (dev) redirect to index.html URL
if (oldUrl.startsWith(GWT.getModuleBaseURL())) {
address = address + GWT.getModuleName() + / +
oldUrl.substring(GWT.getModuleBaseURL().length());
serviceDefTarget.setServiceEntryPoint(address);
}
}
return instance;
}
3. The RPC Async interfaces kept throwing SOP issues, so I enabled CORS on
the server side
4. Now RemoteServiceServlet is using the moduleName from the CDN url.
However this does not match the server side layout, so it fails to fetch
the *.gwt.rpc files. So I overrode RemoteServiceServlet with:
public class CustomRemoteServiceServlet extends RemoteServiceServlet {
public final static String MODULE_ALIAS = app;
@Override
protected SerializationPolicy doGetSerializationPolicy(final
HttpServletRequest request,
final String moduleBaseURL, final String strongName) {
// true client side relative location is the app name
String newModuleBaseURL = moduleBaseURL;
try {
URL url = new URL(moduleBaseURL);
StringBuilder builder = new StringBuilder();
builder.append(url.getProtocol());
builder.append(://);
builder.append(url.getHost());
builder.append(/);
builder.append(MODULE_ALIAS);
builder.append(/);
newModuleBaseURL = builder.toString();
} catch (MalformedURLException ex) {
// we have no affect
}
return super.doGetSerializationPolicy(request, newModuleBaseURL,
strongName);
}
}
I hope that helps others attempting this, but I still need to solve that
code splitting bit, so let me know if anyone's skinned that cat before.
Thanks!
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.
[gwt-contrib] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Manuel Carrasco Moñino has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframe
..
Patch Set 5:
(1 comment)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 340:GWT.getModuleName().equals(childElement.getId())) {
- This code does not work with real browsers unless you change it to the
code below, Because Element.hasTagName() is case-sensitive and compares the
argument against getTagName() which always returns UPPERCASE (see:
http://www.w3schools.com/jsref/prop_element_tagname.asp).
childElement.hasTagName(IFrameElement.TAG.toUpperCase())
A simpler solution could be to get the iframe before the loop and compare it
moduleIframe = DOM.getElementById(GWT.getModuleName()) ;
if (!childElement.equals(moduleIframe)) {} ...
- NOTICE: I think we must preserve the 'script' with
the 'moduleName.nocache.js' as well. Some times the user adds it to the
body instead of to the head. I think that if we remove it, XS linker would
not load next fragments.
Out of subject: In these cases I miss css selectors in gwt, something like:
nodesToRemove = DOM.querySelectorAll(body :not(#moduleName));
--
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: 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
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]: FileUpload: extending FocusWidget instead of Widget so as it...
Hello Leeroy Jenkins, 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 (#6). 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: 6 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 -- 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
Manuel Carrasco Moñino has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframe
..
Patch Set 5:
(1 comment)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 340:GWT.getModuleName().equals(childElement.getId())) {
Forget the first part of my last comment, hasTagName was fixed in the patch
https://gwt-review.googlesource.com/#/c/2975
--
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: 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
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]: Add interfaces for widgets.
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3231 to look at the new patch set (#7). Change subject: Add interfaces for widgets. .. Add interfaces for widgets. Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9 --- M tools/api-checker/config/gwt25_26userApi.conf M user/src/com/google/gwt/dom/client/Element.java A user/src/com/google/gwt/dom/client/HasStyle.java A user/src/com/google/gwt/dom/client/IsElement.java A user/src/com/google/gwt/dom/client/IsStyle.java M user/src/com/google/gwt/dom/client/Style.java M user/src/com/google/gwt/user/client/Element.java M user/src/com/google/gwt/user/client/ui/AbsolutePanel.java M user/src/com/google/gwt/user/client/ui/Anchor.java M user/src/com/google/gwt/user/client/ui/Button.java M user/src/com/google/gwt/user/client/ui/ButtonBase.java M user/src/com/google/gwt/user/client/ui/CellPanel.java M user/src/com/google/gwt/user/client/ui/CheckBox.java M user/src/com/google/gwt/user/client/ui/ComplexPanel.java M user/src/com/google/gwt/user/client/ui/DateLabel.java M user/src/com/google/gwt/user/client/ui/DockLayoutPanel.java M user/src/com/google/gwt/user/client/ui/FileUpload.java M user/src/com/google/gwt/user/client/ui/FlowPanel.java M user/src/com/google/gwt/user/client/ui/FocusPanel.java M user/src/com/google/gwt/user/client/ui/FocusWidget.java M user/src/com/google/gwt/user/client/ui/FormPanel.java M user/src/com/google/gwt/user/client/ui/Frame.java M user/src/com/google/gwt/user/client/ui/HTML.java M user/src/com/google/gwt/user/client/ui/HTMLPanel.java M user/src/com/google/gwt/user/client/ui/HasOneWidget.java M user/src/com/google/gwt/user/client/ui/HasWidgets.java M user/src/com/google/gwt/user/client/ui/HorizontalPanel.java M user/src/com/google/gwt/user/client/ui/Hyperlink.java M user/src/com/google/gwt/user/client/ui/Image.java M user/src/com/google/gwt/user/client/ui/IndexedPanel.java M user/src/com/google/gwt/user/client/ui/InlineHTML.java M user/src/com/google/gwt/user/client/ui/InlineHyperlink.java M user/src/com/google/gwt/user/client/ui/InlineLabel.java A user/src/com/google/gwt/user/client/ui/IsAbsolutePanel.java A user/src/com/google/gwt/user/client/ui/IsAnchor.java A user/src/com/google/gwt/user/client/ui/IsButton.java A user/src/com/google/gwt/user/client/ui/IsButtonBase.java A user/src/com/google/gwt/user/client/ui/IsCellPanel.java A user/src/com/google/gwt/user/client/ui/IsCheckBox.java A user/src/com/google/gwt/user/client/ui/IsColumnsPanel.java A user/src/com/google/gwt/user/client/ui/IsComplexPanel.java A user/src/com/google/gwt/user/client/ui/IsDateLabel.java A user/src/com/google/gwt/user/client/ui/IsDialogBox.java A user/src/com/google/gwt/user/client/ui/IsDockLayoutPanel.java A user/src/com/google/gwt/user/client/ui/IsFileUpload.java A user/src/com/google/gwt/user/client/ui/IsFlowPanel.java A user/src/com/google/gwt/user/client/ui/IsFocusPanel.java A user/src/com/google/gwt/user/client/ui/IsFocusWidget.java A user/src/com/google/gwt/user/client/ui/IsFormPanel.java A user/src/com/google/gwt/user/client/ui/IsFrame.java A user/src/com/google/gwt/user/client/ui/IsHTML.java A user/src/com/google/gwt/user/client/ui/IsHTMLPanel.java A user/src/com/google/gwt/user/client/ui/IsHorizontalPanel.java A user/src/com/google/gwt/user/client/ui/IsHyperlink.java A user/src/com/google/gwt/user/client/ui/IsImage.java A user/src/com/google/gwt/user/client/ui/IsInlineHTML.java A user/src/com/google/gwt/user/client/ui/IsInlineHyperlink.java A user/src/com/google/gwt/user/client/ui/IsInlineLabel.java A user/src/com/google/gwt/user/client/ui/IsLabel.java A user/src/com/google/gwt/user/client/ui/IsLabelBase.java A user/src/com/google/gwt/user/client/ui/IsListBox.java A user/src/com/google/gwt/user/client/ui/IsNumberLabel.java A user/src/com/google/gwt/user/client/ui/IsPanel.java A user/src/com/google/gwt/user/client/ui/IsPasswordTextBox.java A user/src/com/google/gwt/user/client/ui/IsPopupPanel.java A user/src/com/google/gwt/user/client/ui/IsPushButton.java A user/src/com/google/gwt/user/client/ui/IsRadioButton.java A user/src/com/google/gwt/user/client/ui/IsResetButton.java A user/src/com/google/gwt/user/client/ui/IsResizeLayoutPanel.java A user/src/com/google/gwt/user/client/ui/IsScrollPanel.java A user/src/com/google/gwt/user/client/ui/IsSimpleCheckBox.java A user/src/com/google/gwt/user/client/ui/IsSimplePanel.java A user/src/com/google/gwt/user/client/ui/IsSimpleRadioButton.java A user/src/com/google/gwt/user/client/ui/IsSubmitButton.java A user/src/com/google/gwt/user/client/ui/IsSuggestBox.java A user/src/com/google/gwt/user/client/ui/IsTabLayoutPanel.java A user/src/com/google/gwt/user/client/ui/IsTextArea.java A user/src/com/google/gwt/user/client/ui/IsTextBox.java A user/src/com/google/gwt/user/client/ui/IsTextBoxBase.java A user/src/com/google/gwt/user/client/ui/IsUIObject.java A
[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.
Stephen Haberman has posted comments on this change.
Change subject: Add interfaces for widgets.
..
Patch Set 6:
(9 comments)
File user/src/com/google/gwt/dom/client/HasStyle.java
Line 29: void setStyleName(String styleName);
Done
File user/src/com/google/gwt/dom/client/IsElement.java
Line 61: void appendChild(IsElement element);
The reason only getChild/removeFromParent are included is simply that those
are the only methods I'd needed so far, and I've built all of these
interfaces lazily/as needed over the last few years.
I agree that if some of these methods are going to be here, then they all
should.
I won't do that just yet, but will after the patch is
in/very-close-to-being-2+'d.
File user/src/com/google/gwt/dom/client/Style.java
Line 31: public class Style extends JavaScriptObject implements IsStyle {
True, but that is fine--IsStyle is not a characteristic interface, which
would need to be implemented by many other classes.
That said, I did make a HasStyle, which is a characteristic interface that
both Element (a JSO) and Widget (a regular object/non-JSO) implement.
But that is also kosher, and I wouldn't anticipate other JSOs wanting to
implement it. (As Element should already be a base class of any element-ish
JSO that wanted to implement it.)
File user/src/com/google/gwt/user/client/ui/IndexedPanel.java
Line 34:* Extends this interface with convenience methods to handle
{@link IsWidget}.
Done
File user/src/com/google/gwt/user/client/ui/IsImage.java
Line 34: void setUrl(String url);
Personally, I think the point of these interfaces (and what makes them
handy) is that they expose the widget's API exactly as it is, so that your
code can do anything it would to a real widget, but via the faked interface.
So, in that regard, I don't think the interface itself is the place to
start enforcing SafeUri--instead, I think we would deprecate-then-remove
the non-SafeUris methods in both the interface widget at the same time.
File user/src/com/google/gwt/user/client/ui/IsUIObject.java
Line 27: IsElement getIsElement();
Done
Line 27: IsElement getIsElement();
Colin, I believe Thomas's suggestion is fine because, as he said, the API
of UIObject stays Element, no breaking changes.
But since Element implements IsElement, it still fulfills the IsElement
getElement contract of IsUIObject.
File user/src/com/google/gwt/user/client/ui/IsWidget2.java
Line 28: public interface IsWidget2 extends IsWidget, IsUIObject,
EventListener, HasHandlers,
Np--although feel free to follow up on the mailing list if the thread gets
too long...
RE IsWidget vs. IsWidget2, yes, the IsWidget2 is for mocking. Although,
AFAIK, this is the same purpose as the original IsWidget, or at least that
is what its javadoc insinuates.
The 2 was just an ugly name that means the same thing as the original,
but with more methods, except we can't really add them to the original,
because it would break backwards compatibility. E.g. it's just for
versioning the interface.
I've since renamed IsWidget2 to IsWidget.Extended, an inner-interface,
which is more like how the existing GWT interfaces, like IndexedPanel, were
extended for the original IsWidget.
File user/src/com/google/gwt/user/client/ui/Panel.java
Line 118: return new IsWidgetIteratorAdaptor(iterator());
Ah, yes, another great catch--I believe that I had to do this in Tessell
since I couldn't change Widget itself.
But now, you're right, the adaptor isn't needed, and the cast seems to work
just fine.
--
To view, visit https://gwt-review.googlesource.com/3231
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9
Gerrit-PatchSet: 6
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com
Gerrit-Reviewer: Colin Alworth niloc...@gmail.com
Gerrit-Reviewer: Daniel Kurka danku...@google.com
Gerrit-Reviewer: Goktug Gokdogan gok...@google.com
Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org
Gerrit-Reviewer: Stephen Haberman stephen.haber...@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,
[gwt-contrib] Change in gwt[master]: Add interfaces for widgets.
Stephen Haberman has posted comments on this change. Change subject: Add interfaces for widgets. .. Patch Set 7: Replying to Goktug... consistent naming convention throughout the SDKs Agreed, of course. I see what you mean with the asXXX methods. However, personally, I thought IsXXX just meant we really wanted to name this interface just 'XXX', but that name was already taken by the concrete class, which we can't rename, so we're adding the 'Is' prefix instead. I am open to suggestions, but personally think IsAbsolutePanel/etc. is a pretty good fit. Looking at the size of this change and thinking of its implications, we need a very good justification for it Well, it is big, yes, but I assert it's actually pretty simple. No semantics or logic are changing, it's just laying some interfaces over things. see a demonstration why mocking options out there [...] and see if we can fix the problem without this mess Well, I read the github page for gwt-mockito, and I believe we have different opinions on what constitutes a mess :-). Personally, I think just adding interfaces is a much more straight forward approach than hacking around with classloaders/etc. That said, I would be fine adopting a non-IsXXX variation of my approach if it was technically viable; however, AFAIK, it is not. As a distilled/simplified example, what I do is, roughly: IsElement e; // if in prod e = new Element() // otherwise in tests e = new StubElement(); // now presenter uses e for business logic e.setInnerHTML(asdf) // and the test asserts that it worked assertThat(e.getInnerHTML(), is(asdf)) This same pattern applies for all of the widgets, e.g. IsAbsolutePanel/etc. If I were to use gwt-mockito in the above snippet to replace IsElement with just Element, I would still need my class StubElement extends Element to be able to override and implement stub logic for all of Element's methods. Which, given it's a JSO and has final methods, would not be possible. So, basically, stubs cannot rely on as much classloader magic as mocks can. However, I do not believe this means stubs are an unacceptable way of testing--they just typically require interfaces. That said, I would assert that the whole notion of having JRE-only tests (that sometimes talk to real UI widgets and sometimes fake UI widgets) means that, really, widgets friends should have had interfaces from the beginning. Interfaces are the canonical way in Java to say program against this API, and there will be multiple implementations. I don't think this is very provocative. -- To view, visit https://gwt-review.googlesource.com/3231 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ibd17162d37e367720829bcdaf9a350e446c833b9 Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Stephen Haberman stephen.haber...@gmail.com Gerrit-Reviewer: Colin Alworth niloc...@gmail.com Gerrit-Reviewer: Daniel Kurka danku...@google.com Gerrit-Reviewer: Goktug Gokdogan gok...@google.com Gerrit-Reviewer: Leeroy Jenkins jenk...@gwtproject.org Gerrit-Reviewer: Stephen Haberman stephen.haber...@gmail.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.
