Thanks, however, the revolution has not yet succeeded, comrade still take great effort ;)
On Mon, Jul 16, 2012 at 11:06 PM, Eric Charles <[email protected]> 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<[email protected]> 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<[email protected] >>> >>>> 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<[email protected]> 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< >>>>> >>>> [email protected] >>> >>>> 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<[email protected]> > For additional commands, e-mail: > [email protected].**org<[email protected]> > > -- *echo*
