Hi Vincent -- I like design discussions :) In this case, I really don't think it warrants an extra layer. That, to me, seems like more maintenance. If my entity objects are fairly simple -- and they are, why do I need an extra layer of transformation when Gas3 gets me *almost* all the way there.
In any event, I've been exchanging with Franck on the graniteds list, and he's just released a fix for the URL issue, and he is going to add annotation support to allow control for generation. Currently, if you specify a field as transient: private transient Object someObject; Gas3 will ignore it in the generation. However, this is no good, b/c it conflicts with JPA. If it is marked as transient in JPA it will also ignore it for the database, which is not what I want. If he adds a custom annotation, I can control it via that, and all is well. Regards, Davis On Mon, Apr 6, 2009 at 10:08 AM, Vincent Vandenschrick <[email protected]> wrote: > > I completely agree with Tim's comment. It is a "bad" idea to exactly > mimic your java business objects on the client side especially if you > use a rich domain model where you apply OO principles (e.g. objects are > responsible of their integrity). There is nothing available today to > seamlessly translate your objects' behaviour thus resulting in a double > maintenance. This is the main challenge of using a rich client. GAS3 > only translates your object's state to a certain extent (the pb you had > with java.net.*) and not their behaviour. > But the good news is : the problem can be solved by introducing an > extra (yet generic) layer that takes care of synchronizing the client > GUI state with your server domain model by exchanging hierachical DTOs > that can be used by the flex front-end. This DTO structure becomes the > Flex model and you can use the GAS3 generator on these ones. Once you > have this generic DTO layer, you can re-use it across your projects. and > do not care anymore of client-server synchronization. > >> I usually separate out at least two different models in a project, >> depending on size. One I think of as the business model, concerned >> with modeling the problem domain and business logic in pure Java. The >> other I think of as the 'M' in 'MVC', which functions as transfer >> objects across the Flex API and as the client model on the Flex side. >> It's nice since there is usually some "flattening" that can be done in >> mapping between the two to make things much easier on the Flex side, >> especially since having different models and mapping between them is >> something Java is very good at. >> >> That said, I run generator-mojo on the Java transfer objects and >> generally want everything in those objects to show up on the Flex >> side. I don't know if there is a way or how to exclude methods or >> attributes from the generator-mojo. >> >> -- Tim >> > -- > > Vincent Vandenschrick > Jspresso Framework > http://www.jspresso.org > > > > > -- Zeno Consulting, Inc. home: http://www.zenoconsulting.biz blog: http://zenoconsulting.wikidot.com p: 248.894.4922 f: 313.884.2977 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Flex Mojos" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/flex-mojos?hl=en?hl=en http://blog.flex-mojos.info/ -~----------~----~----~----~------~----~------~--~---
