Re: Best practice to implement Command Pattern RPC on server?
I thought I posted this last night, but I don't see it. Apologies if this is a dupe. I've tried to implement the command pattern using generics, but have some hangups. You can see my code at http://code.google.com/p/gwt-command-pattern/ Hangups: 1) Too many parameters. It's just not pretty 2) I have to parameterize the RPCServiceAsync at the class level, whereas I would like to parameterize at the method level. This is a constraint of the compiler. 3) All my server-side code actually resides on the client side, because of the aggressive nature of the GWT compiler. I would add my voice again asking for a simple annotation or annotations like on a class: @GWTIgnoreReference(ServerSideClass.class) and/or a method: @GWTIgnoreMethod I think there are many justifiable use cases for this type of thing, and I can't think of any way it would decrease user experience. Does anyone know if this is a planned feature? Any comments/suggestions on how to remediate the problems above that I don't know of? Ray Ryan, are you listening? Thanks, On Jun 25, 4:07 pm, Eric erjab...@gmail.com wrote: On Jun 25, 5:12 pm, Herme Garcia hgar...@peoplecall.com wrote: Hi, After listening carefully Google IO's session from Ray Ryan about Best Practices For Architecting Your GWT App : http://code.google.com/intl/es-ES/events/io/sessions/GoogleWebToolkit... He suggests acommandpatternimplementation for RPC calling (see slides 21-25) they are using in Wave. Ray, If you're reading this, can you tell us if the full code for your contact manager is available anywhere? Also, the second of the Contact DIsplay UI slides has the line currentContactId = currentContactId; --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: GWT architecture MVP/EventBus (mentioned at Google I/O)
In my Display interface, I included a method like
Widget getWidgetView();
which (interestingly enough) returns a widget view of the display
object. this eliminates your casting problem, while still maintaining
a degree of anonymity for the Display interface.
On the command pattern thing, I created a project to work through what
I thought I was seeing. You can see it at
http://code.google.com/p/gwt-command-pattern/
Let me know if you have some suggestions on how to fix the issues I
describe there.
Thanks,
On Jun 29, 4:43 pm, Thomas Broyer t.bro...@gmail.com wrote:
On 29 juin, 23:13, Daniel Jue teamp...@gmail.com wrote:
Does anyone have a working MVP/Eventbus sample of something simple
like the PhoneEditor?
I don't think I'm doing it right. The code from the IO presentation
leaves out enough details so that I'm not sure what to do.
For instance, in my Presenter.class,
I have something like this:
public class Presenter {
...
private Display display;
interface Display {
HasClickHandlers getSaveButton();
HasClickHandlers getCancelButton();
HasClickHandlers getNumberField();
HasClickHandlers getLabelPicker();
}
Slide 59 shows getNumberField and getLabelPicker as HasValueString,
not HasClickHandler (and Ray says that ListBox doesn't actually
implement HasValueString but it's quite easy to make a
HasValueString for a ListBox).
void editPhone(Phone phone) {
this.phone = Phone.from(phone);
display.getNumberField().setValue(phone.getNumber());
display.getLabelPicker().setValue(phone.getLabel());
}
...}
Obviously, a HasClickHandlers object doesn't have a setValue method.
It doesn't feel like I should be casting to the widget here, since we
went through all the trouble of using the Display interface.
http://code.google.com/intl/fr-FR/events/io/sessions/GoogleWebToolkit...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: Is this a possible in GWT?
Yes, it's possible, and even documented :) http://code.google.com/webtoolkit/tutorials/1.6/JSON.html On Jun 24, 5:57 am, Portal Developer portal.devel...@gmail.com wrote: Apologies for posting this again, I posted this already but I don't see it appearing on the list, might be due to it being moderated. Hi, Is something like this possible in GWT? I have an existing portal written by myself in php which contains a huge amount of functionality that has been developed over the last few years. I would like to continue using this php functionality purely from the business logic and database point of view because I know that it works in php. The bit that I want to change is the user interface. I generate fragments of basic html in my php to display the relevant information but I would now like to view/create this information using GWT. My php also creates some session variables when the user logs in. I know you can make calls to php scripts from GWT but how complex can this get? Is it possible to call my php from GWT and instead of creating the visual element in php create the visual element in GWT instead. Does this make sense? I would like to move to the GWT environment but without the overhead of having to rewrite the main functionality in my php. Any thoughts or ideas on how this might be achieved greatly appreciated. Thanks, --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Class.newInstance and Class.cast
The reason this is a low priority for the GWT team is because
reflection goes against the spirit of GWT. It introduces a lot of
problems that are difficult to deal with in a fashion that would
result in speedy client-side code. My suggestion would be to work
around it, but if you would like help, you can post your code here and
I'll take a look at it.
On Apr 28, 4:03 am, andrej gab...@gmail.com wrote:
Wrote the following code, and then realized that I can't translate
this to javascript:
public T extends Entity T create(ClassT type, long id) {
T t = type.newInstance();
t.setId(id);
return type.cast(t);
}
Two problems:
(1) Class.newInstance not implemented
(2) Class.cast not implemented
Class.cast should be easy to implement, since it's pretty much just an
identity function. I.e.
type.cast(t) -- t
Class.newInstance() seems also relatively easy to implement. Just
another prototype function to
the class literal object?
This is regarding the following
issue:http://code.google.com/p/google-web-toolkit/issues/detail?id=487can=...
It's apparently low priority. But it seems it could be implemented
easily. Am I wrong? Can I add this
functionality myself? Any pointers? Unfortunately I'm just getting
started with GWT, so I don't have
a good understanding of how this works under the hood yet.
Thank you
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~--~~~~--~~--~--~---
Re: @DontCompileToJavaScript method annotation
+1 to the @JavaOnly annotation On Jun 22, 4:57 pm, Tom Sorgie tom.sor...@gmail.com wrote: I've been thinking the same thing, but taking it from a reverse perspective. In fact i just posted a question about being able to use the @GWTCompatible annotation to get reuse out of server code. I didn't really connect that to the other side - which is writing code in your client that you only want available from the server - till i just read your post. I guess in that circumstance you would be marking code (class, method, or var) written in the client package as @GWTIncompatible. That would automatically remove it from the source tree before gwt-compilation. Good to see that someone else is hitting the same issue. tom. On Jun 22, 4:46 pm, Dave Ford df...@smart-soft.com wrote: Are there any plans for gwt to provide a method annotation that instructs the GWT compiler to *not* include that particular method in the generated JavaScript. Here is my justification for this feature. One of the appeals of GWT (for me) is that I have been able to achieve a decent amount of client/server code reuse. Specifically, i have a number of classes that I can use on both the server (in a jvm) and in the browser (in my gwt app). This is a huge benefit of GWT over, say, Flex or native JavaScript frameworks. I can't be the only one who appreciates this benefit. Here is an entire product to address this same concern (only inverted):http://www.aptana.com/jaxer The problem is, creating java classes that run in the server and in client (gwt app) can lead to jumping thru lots of whoops and some major code refactoring. There are many times where it would be just so easy (if such a thing existed) to add an annotation to a method (or a class). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How to retrieve EntryPoint object?
Not really. The EntryPoint class is not really a class, but a script that is run to bootstrap your application. Any other use of the EntryPoint is a little bit of an abuse of the concept. It is possible to provide a global point of access to the EntryPoint using the Singleton pattern, but global visibility is almost always a bad idea. HTH Nathan On Jun 19, 10:56 am, hezjing hezj...@gmail.com wrote: Hi A quick question, is there a convenient method to retrieve EntryPoint object? -- Hez --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: Common GWT Modules In JAR File Problems.
Some things I'm not clear on from your post: 1) Did you inherit the commons module in each of your *.gwt.xml files? 2) When you did the jar packaging, did you include the java source for the client-side? 3) Are your public resources (i.e. CSS) located in a .../moduleName/ public/ folder? Were they included in the jar? 4) Was your commons.gwt.xml file included in the jar? On Jun 15, 3:29 pm, gazarcher garry.arc...@gmail.com wrote: Hello All, I had a largish Web app with several GWT modules in different packages. These modules shared common code which I put into a separate module, also in it's own package. As simple as I can describe it, it looked a bit like this: // Modules specific to the app: MyPackage.MyApp.GWTModuleA MyPackage.MyApp.GWTModuleB MyPackage.MyApp.GWTModuleC // A common module that could be used in other apps: MyPackage.common.GWTModuleD // Common module containing code and resources used by any GWT module: MyPackage.common.gwt.Common Each of these modules contained their own module XML file (of course), CSS file, HTML file and images. Each module, even the Common one, had it's own entry point. Each module defined at least one servlet -- which were all also configured in the app's web.xml file. The Common module included an entry for add-linker name=xs /. All of the modules, A through D, inherited the Common module. For example, GWTModuleA could use styles defined in Common's common.css file, as well as inheriting widget classes. When I complied everything (using IntelliJ IDEA), the output from compiling normal Java source into class files and compiling GWT Java source into JavaScript all were put into one folder where a WAR file was also built. The relevant folders in the output were: // Normal class files into the usual places: WEB-INF/classes/MyPackage.MyApp.SubPackageA/*.class WEB-INF/classes/MyPackage.MyApp.SubPackageB/*.class etc. // GWT JavaScript and resource files: MyPackage.MyApp.GWTModuleA/*.js MyPackage.MyApp.GWTModuleA/*.rpc MyPackage.MyApp.GWTModuleA/*.png MyPackage.MyApp.GWTModuleA/images/ -- From the Common module MyPackage.MyApp.GWTModuleA/common.css -- From the Common module MyPackage.MyApp.GWTModuleA/GWTModuleA.css MyPackage.MyApp.GWTModuleA/GWTModuleA.html (and similarly for modules B, C and D *and* Common) This all went together very nicely and worked and SO FAR SO GOOD! Then I proceeded to break it :-) I wanted to put my Common module into it's own JAR file so that my Web app and other Web apps we are developing could use it. Here's what I did (amongst several things that didn't work, and trying to cut the long story short...): 1) I created a new Common Intellij IDEA project and moved my common modules, MyPackage.common.GWTModuleD and MyPackage.common.gwt.Common, from my Web app project into it. 2) In the Common project, I compiled everything. The normal Java class files went into their respective folders, i.e.: // Regular Java classes: MyPackage/common/SubPackageA/*.class MyPackage/common/SubPackageB/*.class // GWT modules, their classes and resources, i.e., CSS, HTML, etc. and the module XML file: MyPackage.common.GWTModuleD/* MyPackage.common.gwt.Common/* and GWT's JavaScript output, all went into a separate folder (let's say I don't need this for now). NOTE: During the compilation of the GWT class files, I was *also* careful to copy their Java source files into the same folders (a requirement when building JAR files for shared GWT modules). 3) I created a JAR file from the classes, sources and resource files in step #2. 4) I imported this new JAR file into my original Web app project, now sans all the common code I moved into the new Common project. 5) I successfully compiled my Web app project and deployed the resulting WAR file as before. The Web app appeared to work, *except* in my GWT modules, that used common code before, were all missing the styling and images from my Common module. Also, the GWTModuleD common module was not there at all. So, what did I do wrong? What am I missing? Here are my assumptions, of which some are presumably totally incorrect: a) When I compiled my Web app project with my Common GWT JAR file, GWT found the class files in the JAR and so any widgets I built in the Web app were inheriting the functionality of the common widget code. This did appear to happen without problem. b) When GWT was compiling my Web app GWT modules, it was using the source files to create the JavaScript files under their MyPackage.MyApp.GWTModule[ABC] folders, copying any resource files from their original location in the project. This also appeared to occur without a problem. c) When GWT was compiling my Web app GWT modules in the project I thought it should have seen they were inheriting my MyPackage.common.gwt.Common module in the imported JAR file. I thought it should have taken the source files from the JAR to create the
