On Aug 27, 12:42 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> ...and those classes should generally be "DTOs" (a.k.a. "value
> objects") and thus shouldn't have any embedded logic (even less some
> logic that's only available on one side and not the other!)
> (otherwise, you would be doing someObject.save(callback), not
> myService.save(someObject, callback) !)
Well, no, actually. The example I really want to use was the "Command"
interface above. It would mainly allow me to keep the code interface
(to be used client-side) and the code itself would be in the same
class. Then I'd have a RemoteService where you can pass a "command"
and the server component simply calls commandfromclient.execute().
Something like this :
class SomeCommand {
private SomeType param1;
private SomeType param2;
private SomeType returnval;
public SomeCommand(some parameters) {
}
@ServerOnly
public void execute() {
// actually do what's requested, using all available server
resources
// database updates, whatever
returnval = someReturnVal;
}
// suggested at google I/O
@ServerOnly
public void undo() {
...
}
}
Note that implementing this, using 3 classes instead of 1 was actually
suggested as good practice in the google I/O session "Google App
Architecture Best Practices" (
http://code.google.com/events/io/sessions/GoogleWebToolkitBestPractices.html
). Why do I need to implement 3 classes in order to do this ? In
addition to needing 3 classes, they also have to be located in
radically different parts of the application, despite the obvious
relationship. Why do I need an interface PER command ? That makes no
sense in the design, why should it be forced on me at implementation ?
JDO's wouldn't be that easy to implement even with this facility since
you need to keep state (like database references, transactions, ...),
and obviously state and serialization don't go all that well together.
It'd be useful though, but would still require major surgery.
The problem I'd like to deal with in this interface is that any code
that the client calls and is executed on the server requires modifying
at the very least 3 classes (and an xml file and a static declaration
in your "main" class if you wish to give it a different path for
clarity), that have radically different functions and locations. I
understand all 3 classes, and I agree all three have to exist, it's a
good design. But they're all "plumbing" classes, having nothing to do
with the application logic. It'd be great to have a way to have client-
side logic and server-side logic in the same class, clearly separated
by using annotations.
The reverse of this feature actually exists in the gwt javascript
compiler : making sure that some methods get translated to javascript,
no matter what. This feature is embedded in the compiler and is a
class-level annotation called @ArtificialRescue where you're supposed
to pass comma-separated lists of items to "rescue" : variables,
methods and something else. It is used extensively (though it seems
not very well documented)
If I were to create a patch that followed the @ArtificialRescue
principle but with a "@ServerOnly" annotation name that was valid on a
method and submitted it, do you think it has a chance of getting
accepted ?
Kind regards,
Christophe
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
