[gwt-contrib] Re: Comment on LightweightCollections in google-web-toolkit
Comment by rj...@google.com: Given the goal of "Collections must be able to be eval()-ed into existence from JSON," I hope their JRE counterparts will be able to serialize to JSON. For more information: http://code.google.com/p/google-web-toolkit/wiki/LightweightCollections -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RequestFactory prototype: Initial code that uses org.json lib on the server side
(I created this rietveld issue for you, so the reviewer field is a bit
backwards — should be me.)
http://gwt-code-reviews.appspot.com/160809/diff/1/2
File bikeshed/.classpath (right):
http://gwt-code-reviews.appspot.com/160809/diff/1/2#newcode10
Line 10:
I thought you had added this to svn/tools? Shouldn't this be pointing
there?
http://gwt-code-reviews.appspot.com/160809/diff/1/3
File bikeshed/src/com/google/gwt/sample/expenses/client/Expenses.java
(right):
http://gwt-code-reviews.appspot.com/160809/diff/1/3#newcode64
Line 64: "/expenses/data?methodName=" +
MethodName.FIND_ALL_EMPLOYEES.name());
I was expecting to see this call moved to replace the TODO in
com.google.gwt.sample.expenses.shared.EmployeeRequests.findAllEmployees()
http://gwt-code-reviews.appspot.com/160809/diff/1/4
File bikeshed/src/com/google/gwt/sample/expenses/domain/Storage.java
(right):
http://gwt-code-reviews.appspot.com/160809/diff/1/4#newcode27
Line 27: public class Storage {
The Storage class is an implementation detail of our pretend persistence
system and shouldn't be public.
http://gwt-code-reviews.appspot.com/160809/diff/1/4#newcode66
Line 66: public synchronized List findAllEmployees() {
Don't make this public. Use the existing public static method
Employee#findEmployeeByUserName which wraps it.
http://gwt-code-reviews.appspot.com/160809/diff/1/5
File
bikeshed/src/com/google/gwt/sample/expenses/server/ExpensesDataServlet.java
(right):
http://gwt-code-reviews.appspot.com/160809/diff/1/5#newcode41
Line 41: private static final long serialVersionUID =
-3050190168369080249L;
Why?
http://gwt-code-reviews.appspot.com/160809/diff/1/7
File bikeshed/src/com/google/gwt/sample/expenses/shared/MethodName.java
(right):
http://gwt-code-reviews.appspot.com/160809/diff/1/7#newcode19
Line 19: * Represents the MethodName.
We can't assume a global namespace for service methods. They're expected
to be static methods (e.g. Employee#findAllEmployees), so we need to
include class name as well as method name. We'll need to include param
types as well, to allow overloading — these basically must be full
method signatures. Since the purpose of this effort is to make a hacked
interface of a correct public API, we should get this part right, or at
least make it a bit more realistic.
The service method list is embodied by the methods on
shared.EmployeeRequests. The service method signature (in this case
effectively "...domain.Employee.findAllEmployees()") should be part of
the state of the EntityListRequest instance being returned by
EmployeeRequests#findAllEmployees. That object should make the JSON
call, including the method signature, and it should interpret the
results.
When the results are received, eventually we'll:
• create new Employee instances
• put them in the ValueStore
• set up subscriptions on the ValueStore to the watcher
then the ValueStore will push the results to the watcher.
Since the ValueStore doesn't exist yet, that's too much for this CL.
Instead why not move the JSON call from the entry point to the fire
method in EmployeeRequests, and in the response push the results
directly to the watches. Then in the next iteration we can start to
flesh out the ValueStore itself.
http://gwt-code-reviews.appspot.com/160809/diff/1/8
File bikeshed/src/com/google/gwt/valuestore/shared/Path.java (right):
http://gwt-code-reviews.appspot.com/160809/diff/1/8#newcode24
Line 24: * @param
The type of the property owner at the head of the path
http://gwt-code-reviews.appspot.com/160809/diff/1/8#newcode25
Line 25: * @param
The value type of the last property in the path
http://gwt-code-reviews.appspot.com/160809/diff/1/8#newcode32
Line 32: Property getLastProperty() {
This should actually be Property
http://gwt-code-reviews.appspot.com/160809/diff/1/9
File bikeshed/src/com/google/gwt/valuestore/shared/Property.java
(right):
http://gwt-code-reviews.appspot.com/160809/diff/1/9#newcode21
Line 21: * @param Entity type
Type of the property holder
http://gwt-code-reviews.appspot.com/160809
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] RequestFactory prototype: Initial code that uses org.json lib on the server side
Reviewers: Ray Ryan, Description: Initial code that uses org.json lib on the server side, passes actual request parameters, plus integration with server side domain objects. patch by amitman...@google.com review by rj...@google.com Please review this at http://gwt-code-reviews.appspot.com/160809 Affected files: bikeshed/.classpath bikeshed/src/com/google/gwt/sample/expenses/client/Expenses.java bikeshed/src/com/google/gwt/sample/expenses/domain/Storage.java bikeshed/src/com/google/gwt/sample/expenses/server/ExpensesDataServlet.java bikeshed/src/com/google/gwt/sample/expenses/shared/EmployeeRequests.java bikeshed/src/com/google/gwt/sample/expenses/shared/MethodName.java bikeshed/src/com/google/gwt/valuestore/shared/Path.java bikeshed/src/com/google/gwt/valuestore/shared/Property.java -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: UIObject methods return type improvement.
Thanks for your Reply Joel. Im happy to see this will be at leaset
taken into consideration.
I underestand your point of view. I think since this methods return
nothing, maybe is not that problematic to implement a nice return.
Only signature problems will occur on subclasses, nothing a simple
refactor can't handle
On Mar 3, 11:58 am, Joel Webber wrote:
> We could argue the merits of method chaining (I'll let the compiler guys
> speak to whether or not this is better, worse, or indifferent for code
> generation) -- but the bigger problem is that we'd have to change the style
> of code throughout the system to make it useful, but any attempt to do so
> would break existing subclasses that override these methods.
>
>
>
> On Tue, Mar 2, 2010 at 7:19 PM, Qcho wrote:
> > Hi, I am currently working on a project using GWT.
>
> > Maybe is a good suggestion to change the return value of functions
> > such as addStyleDependentName or addStyleName from void to the UI
> > modified itself, so you can do things like this:
>
> > DockLayoutPanel appPanel = new DockLayoutPanel(Unit.EM);
> > appPanel.addNorth(new HTML("hh1").addStyleName("header"),
> > 4);
> > appPanel.addNorth(new HTML("hh2").addStyleName("subHeader"),
> > 10);
> > appPanel.addSouth(new HTML("foot").addStyleName("footer"),
> > 4);
> > appPanel.addWest(new HTML("nav").addStyleName("navigation"),
> > 10);
>
> > this code wont compile since the chaining of addStyleName returns void
> > and not the Widget element.
>
> > Simple example provided.
>
> > --
> >http://groups.google.com/group/Google-Web-Toolkit-Contributors
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
