Re: Best practice to implement Command Pattern RPC on server?

2009-07-03 Thread ClusterCougar

Thanks David. That looks like a much better solution. The only reason
I did all those generics was because I was still trying to wrap my
head around the problem. Based on this, I've come up with some ideas
I'm going to try to implement. How do you register your
ActionHandlers?


On Jul 3, 8:55 am, David Peterson  wrote:
> Hey ClusterCougar,
>
> I think your implementation is over-complicated. On the client side,
> just stick to two basic interfaces (and concrete implementations there-
> of) - Action and Result (I'm using 'Result' rather than 'Response'
> because that is often used in HTTP-related APIs), or in your API,
> IProcedure and IReturn. The IAttributes, IRemoteProcedure and other
> interfaces are unnecessary.
>
> Then, on the server side, I've got 'ActionHandler' classes, which look
> something like this:
>
> public interface ActionHandler, R extends Result>
> {
>    public Class getActionType();
>
>    public R execute( A action ) throws Exception;
>
> }
>
> You then register your various ActionHandler instances with your
> 'RPCService' and it just matches up the action passed in with the
> appropriate action handler, calls execute and you're off to the races.
>
> Sorry about the incomplete example - the code itself is tied up in the
> app I'm using this in at the moment. I hope to make it a bit more
> general down the track.
>
> David
>
> On Jun 30, 8:05 pm, ClusterCougar  wrote:
>
>
>
> > I thought I posted this last night, but I don't see it. Apologies if
> > this is a dupe.
>
> > I've tried to implement thecommandpatternusing 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  wrote:
>
> > > On Jun 25, 5:12 pm, Herme Garcia  wrote:
>
> > > > Hi,
>
> > > > After listening carefully Google IO's session from Ray Ryan about
> > > > "Best PracticesFor 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)

2009-06-30 Thread ClusterCougar

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  wrote:
> On 29 juin, 23:13, Daniel Jue  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 HasValue,
> not HasClickHandler (and Ray says that ListBox doesn't actually
> implement HasValue but it's quite easy to make a
> HasValue 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: Best practice to implement Command Pattern RPC on server?

2009-06-30 Thread ClusterCougar

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  wrote:
> On Jun 25, 5:12 pm, Herme Garcia  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: Is this a possible in GWT?

2009-06-25 Thread ClusterCougar

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 
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: @DontCompileToJavaScript method annotation

2009-06-24 Thread ClusterCougar

+1 to the "@JavaOnly" annotation

On Jun 22, 4:57 pm, Tom Sorgie  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  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: Class.newInstance and Class.cast

2009-06-24 Thread ClusterCougar

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  wrote:
> Wrote the following code, and then realized that I can't translate
> this to javascript:
>
>   public  T create(Class 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=487&can=...
>
> 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: How to retrieve EntryPoint object?

2009-06-20 Thread ClusterCougar

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  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.

2009-06-16 Thread ClusterCougar

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  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 .
>
> 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 JA

Re: Introducing GWTUML, a GWT UML Drawer.

2009-06-16 Thread ClusterCougar

Very cool. might want to make an expandable panel as a "toolbox". That
seems to be a pretty standard analogy in diagramming tools. Do you
have a roadmap/design for server-side? are you thinking you'll do a
persistence framework or filesystem storage (i.e. xml)?

On Jun 15, 3:43 am, walterc  wrote:
> very nice!
>
> On Jun 15, 4:54 pm, "mounier.flor...@gmail.com"
>
>
>
>  wrote:
> > Hello everyone !
>
> > I would like to introduce to you the open source project I've been
> > working on these past 6 months : GWTUML.
>
> > This is an UML drawer that uses of course gwt and aims to be a light
> > and fast one. For now all the code is client side but nothing but time
> > prevents it to become client-server.
>
> > To use it : right-click opens a contextual menu with all sorts of
> > commands here, [h] brings hotkeys list and double click edits items.
>
> > Any comments, suggestions and critics would be really appreciated.
> > (Sequence diagram is in a very early statge !)
>
> > Demo on Google app engine 
> > :http://1.latest.gwtuml.appspot.com/GWTUMLDrawer.html
>
> > Google code site :http://code.google.com/p/gwtuml/
>
> > Greetings.
> > Florian

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---