Why?

[jettro]

Hi I am just curious what the proposition for this project is going to be. I like the idea that flex is coming to spring, however the integration with BlazeDS is very easy. So there have to be additional things than just configuration. A few things I can come up with:

- Tight integration with spring-security, I have written multiple posts about it and it could be nice to come up with some standard classes and configurations
- Influence the mapping between objects and amf (not sure if that is possible, but using your domain objects can be annoying)
- Dependency injection for spring?? (though I like with Mate is doing already and it is not real integration with BlazeDS). After writing this down I see there is already an extension project doing this.
- Doing something with the exceptions and remoting?

I am having a hard time thinking about other items. Hope others will jump in and come with ideas as well.

[jeremyg484]

From my interactions with the community and from discussions with Adobe's developers about feedback from their community, our feel is that the current approach (i.e., the SpringFactory dependency lookup approach) is not as simple as it should be and is at odds with the programming model to which a Spring developer (i.e., someone who uses Spring but is completely new to BlazeDS and Flex) is accustomed.

But with that said, the larger point is definitely that the foundation in place with M1 opens up the door for many more integration opportunities and makes them simpler to implement. Spring Security integration is the top priority for M2. I think I am familiar with your posts on the matter, but could you re-post the links here for the benefit of the rest of the community?

Are there particular pain points you have encountered with handling exceptions in conjunction with remoting?

Thanks for the feedback.

[jettro]

Most easy access to the blog items is:
http://www.gridshore.nl/tag/blazeds/
or
http://www.gridshore.nl/tag/flex3/

As for the question about exception handling. This is a harder part. I did go two different ways.

1. I created a RemoteService object that wrapped the actual RemoteObject. That way I can create a Default onRemoteException method that I register as a FaultEvent listener. I like the idea about some generic exception handling. But this concept is noet really available in ActionScript. You can use events, but I am not sure if that is the way to go.
Sour is available here:
http://code.google.com/p/gridshore/s...moteService.as

2. In the other situation I used Mate for the remoting. Nice appraoch, but I did not really implement Fault handling in that application.

[ideasculptor]

Given BlazeDS's lack of support for lazy initialization of domain object properties via an ORM layer, it would be nice if spring could solve this problem in an ORM independent manner, eventually. That's one use I can think of for the effort. For that matter, coming up with a clean mechanism for wrapping a normal service in a service that interacts only with DTO versions of objects that don't contain relations would also be handy. There is at least one hibernate-specific solution for lazy loading via blazeds (as opposed to graniteDS), but it struck me as being fairly immature and lacking in community when I last looked at it.

For that matter, I found the lack of discussion, out on the internets, of lazy loading of ORM loaded domain objects to be somewhat surprising. It's as though no one is using flex to do enterprise-like applications. Instead, the model for flex apps seems to be an app that runs almost entirely on the client with only small bits of communication back to the server, rather than maintaining a sophisticated object model that must be kept in constant sync with the server.

[bh5k]

The samples are all xml based. With the recent "everything annotation" approach that Spring seems to be headed, I was expecting all the samples to be done with annotations. Can they or is it just not there yet?

[jettro]

I totally agree with you. I do have an application in this area, but I use my own mapping to DTO using Dozer.

Given BlazeDS's lack of support for lazy initialization of domain object properties via an ORM layer, it would be nice if spring could solve this problem in an ORM independent manner, eventually. That's one use I can think of for the effort. For that matter, coming up with a clean mechanism for wrapping a normal service in a service that interacts only with DTO versions of objects that don't contain relations would also be handy. There is at least one hibernate-specific solution for lazy loading via blazeds (as opposed to graniteDS), but it struck me as being fairly immature and lacking in community when I last looked at it.

For that matter, I found the lack of discussion, out on the internets, of lazy loading of ORM loaded domain objects to be somewhat surprising. It's as though no one is using flex to do enterprise-like applications. Instead, the model for flex apps seems to be an app that runs almost entirely on the client with only small bits of communication back to the server, rather than maintaining a sophisticated object model that must be kept in constant sync with the server.

[aledbf]

Why don't use Graniteds (www.graniteds.org)?. They provide action script generators for entities (based on Jpa annotations) and value objects (configuration or anotations) and lazy loading (hibernate, toplink, eclipselink). Also works with spring-security.

[jeremyg484]

Given BlazeDS's lack of support for lazy initialization of domain object properties via an ORM layer, it would be nice if spring could solve this problem in an ORM independent manner, eventually.

This is certainly a common issue when re-using your domain objects as the view model (same problems exist in JSF and GWT for example). It could be debated that the DTO approach is actually better if you have a truly rich domain model where the objects are more than just data carriers. There are decent solutions out there (such as Dozer) for making the use of DTO's a bit less painful, but there is no getting around it being an extra layer that needs to be managed.

That said, I can see benefit to providing some support for the lazy initialization problem if a generic approach can be settled upon. The question then becomes, what would be the "ideal" approach? Perhaps an aspect that prevents the lazy associations from being touched by the serializer? How should those associations then be represented in the AMF message? Should there be a facility to then automatically re-attach entities when they are passed back and deserialized, or should that be left up to the user's DAO/Repository code?

[jeremyg484]

The samples are all xml based. With the recent "everything annotation" approach that Spring seems to be headed, I was expecting all the samples to be done with annotations. Can they or is it just not there yet?

It's not there yet, but it's something we've already given some thought. I generally prefer to offer both options, but the basic foundation has to be in place first. Once we have more of the core features in place and nailed down, then we'll start adding things like namespace based configuration and annotation based configuration.

[wdrai]

I completely agree with you and I am still surprised on the lack of discussion about this. We have in fact started the GraniteDS project specifically to address this issue with Flex clients, as we wanted a clean object model on both the client and the server without having to rely on a useless DTO layer.

I really think that with the advent of other complex client frameworks (like GWT), the need of a proper support for detached entities on clients will be critical for 'real' enterprise applications.

Of course, after the announcement of the partnership between SpringSource and Adobe, there seems to be little room for projects like GraniteDS for Flex/Spring integration, but I would just want to precise that we have been providing a strong integration with Spring for more than one year and that we already support or plan to support JPA providers other than Hibernate: TopLink / EclipseLink. We are now working on OpenJPA and DataNucleus.

Given BlazeDS's lack of support for lazy initialization of domain object properties via an ORM layer, it would be nice if spring could solve this problem in an ORM independent manner, eventually. That's one use I can think of for the effort. For that matter, coming up with a clean mechanism for wrapping a normal service in a service that interacts only with DTO versions of objects that don't contain relations would also be handy. There is at least one hibernate-specific solution for lazy loading via blazeds (as opposed to graniteDS), but it struck me as being fairly immature and lacking in community when I last looked at it.

For that matter, I found the lack of discussion, out on the internets, of lazy loading of ORM loaded domain objects to be somewhat surprising. It's as though no one is using flex to do enterprise-like applications. Instead, the model for flex apps seems to be an app that runs almost entirely on the client with only small bits of communication back to the server, rather than maintaining a sophisticated object model that must be kept in constant sync with the server.