james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manuel Carrasco Moñino <man...@apache.org>
Subject Re: cope with the RequestFactory's find*
Date Wed, 11 Jul 2012 16:28:47 GMT
Hi echo,
you were right when you said that client and server could not share the
same class, it is because a bug in gwt [1][2].
I have sent a patch to gwt which is pending on review [3], in the meanwhile
you can use the patched class.

I have modified the rf example I sent, and I have committed it to your
apache-extras project [4]. You can see that all code share the same class
(Subject in this example), and there is a SubjectLocator responsible of
instantiating the appropriate implementation.

[1] http://code.google.com/p/google-web-toolkit/issues/detail?id=7509
[2] http://code.google.com/p/google-web-toolkit/issues/detail?id=5762
[3] http://gwt-code-reviews.appspot.com/1764804/

- Manolo

On Wed, Jul 11, 2012 at 11:53 AM, Manuel Carrasco Moñino

> Hi all,
> I have committed to the apache-extras repository a very simple project
> with everything set to use value-proxies.
> It could work fine as the basis of how hupa can use them.
> just check it out and run:
> svn co http://svn.codespot.com/a/apache-extras.org/hupa-evo/experiments/rf
> cd rf
> mvn test
> mvn gwt:run
> - Manolo
> On Wed, Jul 11, 2012 at 10:02 AM, Manuel Carrasco Moñino <
> manolo@apache.org> wrote:
>> Hi echo,
>> Actually the mail server is our datasource, and we get from it very few
>> type of objects, just folders and messages.
>> Folders and messages are not entities in the traditional sense of the
>> concept because normally they do not change, so I would not use entities
>> but values.
>> It is pretty easier deal with valueproxies instead of entityproxies
>> because the first one have less constrains.
>> I would create an interface for each value, and I would use this
>> interface as the valueproxy in the client. In the server side I would
>> implement the valueproxy interface in the valueimplementation class. It
>> have to work because I have used this approach some time.
>> Said that, we need just one service class (or many depending of code
>> readability) to interact with the server side.
>> About caching, I think we have to do it in either client or server side
>> or even in both. If we use value proxies it make it  easier because we can
>> serialize/deserialize anywhere without worrying about versions etc.
>> - Manolo
>> On Tue, Jul 10, 2012 at 7:13 PM, echo <echowdx@gmail.com> wrote:
>>> For there,
>>>> Some examples I have studied, while there is not a good idea about how
>>>> to implement the find* method.
>>>> I'v got a little confuse about the how to define our system's
>>>> EntityManager.
>>>> I will look more into the RF and hope to get a good approach to solve
>>>> this issue.
>>>> We could treat the mail server as the datasource, I think, and the
>>> folders and messages can be seen as data like what you've referred earlier.
>>> However, do you think both of them need to be cached, otherwise it will
>>> very slow retrieve data from mail server over and over again.
>>> --
>>> *echo*

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