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, 16 Jul 2012 15:28:56 GMT
Thanks, however, the revolution has not yet succeeded, comrade still take
great effort ;)

On Mon, Jul 16, 2012 at 11:06 PM, Eric Charles <eric@apache.org> wrote:

> +1 on Manolo comments and echo's job :)
> Eric
>
>
> On 07/09/2012 09:23 AM, Manuel Carrasco Moñino 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.
>> - 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/**
>> RequestFactoryInterfaceValidat**ion<http://code.google.com/p/google-web-toolkit/wiki/RequestFactoryInterfaceValidation>
>> .
>>
>> - 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.
>>
>>
>> Continue working in this way, reporting and committing frequently, you are
>> doing a good job.
>>
>> - Manolo
>>
>> On Mon, Jul 9, 2012 at 2:45 AM, echo<echowdx@gmail.com>  wrote:
>>
>>  Hi manolo,
>>>
>>> Very happy to inform you that my first experiment code succeed at last. I
>>> have commit the code.
>>>
>>> For test convenience, I have not been able to cope with the front
>>> code(WestActivity and WestView) in time.
>>> However, there have been some outputs in console that persuade me of its
>>> correctness.
>>>
>>> BTW, I have to reRun maven command "Hupa clean package" every time I
>>> update
>>> a server's RequestFactory code.
>>>
>>> Thanks for your detail reply.
>>>
>>> On Sun, Jul 8, 2012 at 8:13 PM, Manuel Carrasco Moñino<manolo@apache.org
>>>
>>>> wrote:
>>>>
>>>
>>>  Yep, although RF is well documented it is difficult to understand what
>>>>
>>> are
>>>
>>>> the real goals on using it, basically what you have to understand about
>>>>
>>> RF
>>>
>>>> is:
>>>> 1.- it facilitates to use server services (much better than rpc or
>>>> dispatcher)
>>>> 2.- proxy objects and entities is trivial.
>>>> 3.- a lot more of features, like serialize proxy objects in strings to
>>>> cache them in, chain operations and so just one request to the server,
>>>>
>>> etc.
>>>
>>>> 4.- an cool thing is that with RF we are able to use it in JVM so
>>>> testing
>>>> is very easy. Even we could use a pure java client to request a RF
>>>> server
>>>> (it is used in android)
>>>>
>>>> Hupa data is not a good example for traditional entities: jpa, ddbb, etc
>>>> So in Hupa we have objects in the server side which we are able to
>>>>
>>> persist
>>>
>>>> or read in some way.
>>>>
>>>> The user object actually is an object wich we persist in session, imap
>>>>
>>> and
>>>
>>>> smtp needs this object to start new sessions over the server. When we
>>>> had
>>>> oauth instead of a user object we would store just a authentication
>>>> token
>>>> anywhere.
>>>>
>>>> The rest of objects  are representations of a message, a folder, or
>>>> whatever. Which we persist or read using imap/smpt
>>>>
>>>> The worst thing in RF is the maven setup, and validation, when you debug
>>>> in eclipse you have to run the apt task and reload after changing any RF
>>>> service.
>>>>
>>>> I did take a look to your commits so I was informed that you were
>>>> playing
>>>> with RF. Just send a daily email with your tasks although thew were
>>>> incomplete.
>>>>
>>>> - Manolo
>>>>
>>>>
>>>> On Sun, Jul 8, 2012 at 9:29 AM, echo<echowdx@gmail.com>  wrote:
>>>>
>>>>  Sorry, I am figuring out the RequestFactory of FetchFolders.
>>>>> I want to submit the report after one whole RequestFactory
>>>>> procedure(The
>>>>> fetch folder one) succeeding, that will be updated later today, I
>>>>> think.
>>>>>
>>>>> The reason why I have not submit the report these two days is that:
>>>>> I wanted to cope with the RequestFactory procedure of Login or
>>>>> CheckSession, but it was found that both of them are very close to the
>>>>> HttpSession and MailUser which are not good with RequestFactory.
>>>>> You may find that I have something commit to the Hupa Evo repository
>>>>> about the User RequestFactory yesterday, but the running Hupa was
>>>>> broken
>>>>> after clicking the Login submit.
>>>>> So I change my first RequestFactory experiment to the FetchFolder's
>>>>> one.
>>>>> And I think the code and report will be completed later today.
>>>>>
>>>>>
>>>>> On Sun, Jul 8, 2012 at 2:34 PM, Manuel Carrasco Moñino<
>>>>>
>>>> manolo@apache.org
>>>
>>>> wrote:
>>>>>>
>>>>>
>>>>>  Hi echo, no status updates for a couple of days, let me know what is
>>>>>> happening.
>>>>>>
>>>>>> - Manolo
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *echo*
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> *echo*
>>>
>>>
>>
> --
> eric | http://about.echarles.net | @echarles
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.**apache.org<server-dev-unsubscribe@james.apache.org>
> For additional commands, e-mail: server-dev-help@james.apache.**org<server-dev-help@james.apache.org>
>
>


-- 
*echo*

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