james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From echo <echo...@gmail.com>
Subject Re: Succeed change the FetchFolders to RequestFactory MODE
Date Mon, 09 Jul 2012 17:19:37 GMT
Attempted to change the IMAPFolder to an interface(because this is the
easiest way to change the front end, I think), but failed.
The reason was that I ignored the RF's name convention of both the server
and client side. So the front side must be modified step by step rather
than only to change the IMAPFolder to interface like what I commit(r33).
And there,
On Mon, Jul 9, 2012 at 3:23 PM, Manuel Carrasco MoƱino <manolo@apache.org>wrote:

> Hi echo,
> I've been reviewing the code, and it demonstrates you are getting a good
> knowledge of RF.
> A couple of things:
> - I would extend ValueProxy instead of EntityProxy in certain classes like
> UserProxy, because they are not real entities and  we don't need attributes
> like id, version etc.
>
Yes, I agree with you. I will give my quickly feedback as soon as any code
was changed for I have no v clear idea about the value and entity.

- In certain cases you could share the proxy interface between the server
> and client, so as both sides code looks very similar because use the same
> interface, in the server side you could have an implementation of the
> object or even you could use innerclasses if the code is simple.
>
> example:
> --- Client
> @ProxyForValue(User.class)
> interface User()  extends ValueProxy{
> }
>
> --- Server
> class UserImpl implements User {
> }
>
> class MyService {
>   User validateUser(String name, String password) {
>     return new User() {
>      ...
>     }
>   }
> }
>
> - When you change Rf services or objects, it is enough if you run 'mvn
> compile' instead of 'package' which takes much more time. Even though you
> could configure eclipse to do that automatically
>
> http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation
> .

Thanks, those are very helpful.


> - It is necessary that you start introducing tests, one of the RF goals is
> that you can test services in the jvm, so as it is very fast to code client
> and servers sides without starting the devel mode to check your code. In
> hupa when I started introducing RF dependencies I left some example code
> and a SubjectTest class.

All right, I have noticed the test sample and referred it many times, which
you can find an echo() method aiming to test in my commit code.
Actually, I really want to write tests first and then the function codes.
While I am the newbie facing to TDD, a little imitating what have been done
will certainly give me more inspiration.
The goals and advantages RF have got take place in almost all of the
article about it, so I also know more or less a little how to make good use
of the good points of RF, like what you've told me that, test in jvm,
transmit less stuff on the wire, and many others.


>


> Continue working in this way, reporting and committing frequently, you are
> doing a good job.
>
> - Manolo

-- 
*echo*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message