The way I am handling 'what gets mapped' is with a BeanFactory class
that uses Dozer to do basic mapping on a per CDO/Bean basis. BeanUtils
could do this but BeanUtils blows up a lot more easily. Dozer handles
serializable attributes automatically for us. Case by case I add logic
to my BeanFactory for a specific class or use a Dozer xml mapping file
as appropriate (same as you are doing in xml probably, just with
Dozer). I get to pick which method to use though so the tool scales
well from a developer point of view.
This gets me my basic POJO/CDO back and forth. The bean itself (pure
client side object) is not a one to one map with the CDO, its just a
client side representation of what data we want out of the CDO that is
required for the app display/logic.
In other words: The bean has fields that the CDO doesn't. We treat the
CDO as 'data tier' and the mapped Bean as 'display tier'. What is in
the bean is very much driven by our UI requirements.
So the CDO may have a many mapping that represents a list of 'client'
objects, the POJO has an integer that is 'clientCount' instead and
used for display purposes. To get an actual list of 'clients' is a
round-trip to the server to get a list of ClientBean based on some
attribute in the application. This seems to work nicely in the GWT
async construct. We keep this in mind as we design the interface so as
to minimize user wait states and we add Bean attributes as required to
support new UI requirements (CDO is not changed without a lot of
discussion however, it impacts a lot of other non-GWT interfaces).
This is where I want to use Velocity templates. Just as cayenne
generates the _CLASS and CLASS versions of the file I want a third
which is CLASSBEAN that is very boiler plate. Just a bunch of :
public ClientsettingsBean getClientsettingsBean(Clientsettings settings){
return mapper.map(settings,ClientsettingsBean.class);
}
public void setClientsettings(ClientsettingsBean bean, Clientsettings
settings){
mapper.map(bean,settings);
}
which can then be added to by the developer as required to achieve UI
goals that the Bean must support:
public ClientsettingsBean getClientsettingsBean(Clientsettings settings){
ClientsettingsBean theBean = mapper.map(settings,ClientsettingsBean.class);
// these could be dozer xml maps as well, developer choice
theBean.setCountOfSomeAspectOfMyGraph(settings.getCountofSomeObject());
theBean.setSomeOtherHugeAndExpensiveThingIfWeSentItAsARealObject(12);
return theBean;
}
On the UI framework front. This is somewhat of a big debate,
particularly on the GWT lists. We really find the widget support in
GXT invaluable. Our GWT apps are very 'dashboard' like in nature and
almost entirely Grid driven. Our opinion is that the GXT grids are the
best going right now so thats where we ended up.
John-
On Thu, Jan 28, 2010 at 1:49 AM, Andrey Razumovsky
<razumovsky.andre..mail.com> wrote:
> Cool, didn't know about BeanModel.. I'm never used GXT. We've wrote quite a
> lot of code in GWT-Ext (and it supports JSON).. This is raw and abandoned
> project, and I hate it more and more each day (and also I will never anymore
> use wrapper library, like SmartGWT). Still I've been unable to persuade my
> manager to spend several dollars for a licence :( Looks like now I have one
> more reason to do it.
> As about beans on client, I've been dreaming about something like ROP for
> GWT. For now we can do the task of converting the objects to POJOs, this
> must be quite easy. Still I'm not sure, how you're going to decide what part
> of Cayenne object graph is to be sent on client (this is what I use XML
> descriptions BTW)
>
> 2010/1/28 John Armstrong <siberia..mail.com>
>
>> I'm using GXT which has a pretty strong preference for its own
>> 'BeanModel' (thin wrapper around a javabean that understands GXT) for
>> grid population etc.
>>
>> That (in my mind) means I am either serializing Cayenne Models -> JSON
>> -> BeanModels or just going from Cayenne Model -> BeanModel so I
>> decided to skip the JSON step.
>>
>> Outside of easy GXT integration the only other thing I get are
>> enumerations (supposedly) which I use in a few important places in my
>> models.
>>
>> Does that make sense? I haven't done much straight GWT which is much
>> different then GXT so the interactions may be different.
>>
>> I am very interested in what you are doing, finding someone using GWT
>> and Cayenne is not so common!
>>
>> John-
>>
>> On Thu, Jan 28, 2010 at 12:43 AM, Andrey Razumovsky
>> <razumovsky.andre..mail.com> wrote:
>> > I'm currently using Cayenne and GWT. I think the question should be if it
>> is
>> > worth it to convert server beans to client beans. Do you really need data
>> > objects on client side? With a lack of reflection they cannot be easily
>> used
>> > in UI. I think this only produces unneeded convertion.
>> > What I do is convert CDOs to JSON on server side, this is done with
>> > XML-based descriptions (which look much like json-taglib, but are
>> > standalone) and use only JSON-based data on client side.
>> > What do you think?
>> >
>> > 2010/1/28 John Armstrong <siberia..iberian.org>
>> >
>> >> I'm finding myself generating a lot of Beans that mirror my cayenne
>> >> entities (plus Dozer mappings) as I delve into GWT.
>> >>
>> >> This is crying out for automation and I'm sure a few others would
>> >> enjoy it. It may even make Cayenne very GWT Friendly.
>> >>
>> >> To move this ball forward (for me minimally) can anyone point me to
>> >> either some sort of sample implementation of Cayenne velocity template
>> >> based code generation (or whatever is being used in 3.0) or a pointer
>> >> to where in the source code a sample template/generator lives that I
>> >> can explore?
>> >>
>> >> Tx. My fingers are getting sore-
>> >> John-
>> >>
>> >
>> >
>> >
>> > --
>> > Andrey
>> >
>>
>
>
>
> --
> Andrey
>
This archive was generated by hypermail 2.0.0 : Thu Jan 28 2010 - 08:31:57 EST