You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by echo <ec...@gmail.com> on 2012/07/09 02:45:14 UTC
Succeed change the FetchFolders to RequestFactory MODE
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 <ma...@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 <ec...@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*
Re: Succeed change the FetchFolders to RequestFactory MODE
Posted by echo <ec...@gmail.com>.
Thanks, however, the revolution has not yet succeeded, comrade still take
great effort ;)
On Mon, Jul 16, 2012 at 11:06 PM, Eric Charles <er...@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<ec...@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<ec...@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<se...@james.apache.org>
> For additional commands, e-mail: server-dev-help@james.apache.**org<se...@james.apache.org>
>
>
--
*echo*
Re: Succeed change the FetchFolders to RequestFactory MODE
Posted by Eric Charles <er...@apache.org>.
+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/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<ec...@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<ec...@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
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Succeed change the FetchFolders to RequestFactory MODE
Posted by echo <ec...@gmail.com>.
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 <ma...@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*
Re: Succeed change the FetchFolders to RequestFactory MODE
Posted by Manuel Carrasco Moñino <ma...@apache.org>.
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/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 <ec...@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 <ec...@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*
>