What are some of the advantages in adding Spring into a Flex / AIR application? And When would you recommend using Spring?
If you're writing a Flex app with a Java backend, you'll want to use BlazeDS to handle remoting and/or messaging between the client and server. Spring has support for integrating with BlazeDS and making Blaze a little easier to setup and configure. It's also pretty easy to set up BlazeDS on its own, so if you don't want to learn Spring then you should not be afraid to use BlazeDS by itself.
The bulk of what Spring provides is specific to the Java layer but it will help you write better Java applications. In particular it provides a clean way for wiring up application components, simplifies data access using Hibernate and/or JDBC, makes it easy to do aspect-oriented programming and also has a pretty nice security framework (Spring Security). There's a ton that Spring can do and I recommend using Spring for pretty much any Java backend.
Flex is addressing what happens in the UI. You are likely to need some server-side logic to provide the data for the UI. Writing robust, performant, secure server-side logic from scratch is not trivial. Frameworks such as Spring, EJB 3, etc. really do help with that. The learning curve for modern frameworks is not too steep, getting started is barely more that a few extra "annotations" to the code you knew you wanted to write.
Well worth investigating.
The sum total of learning Flex + Spring + also some DB admin is still quite a lot. You may need to keep your ambitions under control, don't try to fly before you are walking comfortably.
Good luck.
Related
I'm looking at enterprise JavaFX, and how to integrate JavaFX with server-side code. In the last few weeks I've done a certain amount of research in DataFX and Open Dolphin, and downloaded some videos, as well as looking at a couple of other frameworks. For example I've looked at the video on DataFX at:
https://www.youtube.com/watch?v=EN4fo6x0DcQ
However, although this video and others I've looked at explain how to set up a client application that connects with a server, I've found very little information on how to put together some server-side code that the client can connect to. Sure, one could use JAX-RS, but why re-invent the wheel? In the first instance I would like to put together some really simple server-side code that some test client-side code can connect to using DataFX or one of the other frameworks. The aim eventually is to get a client using JavaFX to communicate with a server.
My second question is that of the various frameworks available, is DataFX the best to use for a simple application?
I have experience with a Glassfish server hosting a JSF application, and it may be useful to have such a server hosting a JSF application communicating with a browser as well as communicating with a client JavaFX, as that way I can test out that the communication with the JavaFX application.
The latter is a bit of an aside, and my main questions are where can I get information on server-side programming for this, and the best frameworks to use?
Many thanks in advance.
If you are able to manage yourself the client-server communication you can pick any JavaFX Application Framework listed there:
https://github.com/mhrimaz/AwesomeJavaFX
Any of them allows to separate UI code from communication code.
As I'm author of JRebirth, I can advice you to create some RemoteService (extends Service and providing JAX-RS facilities or whatever) to perform this job.
If you search an all-in-one library managing client AND server side, DataFX + OpenDolphin is probably the most advanced one.
I'm the author of DataFX & Dolphin Platform (https://github.com/canoo/dolphin-platform). Both are valid frameworks that fill fit to your needs. Maybe a combination of both - Dolphin Platform as remoting layer between client and server and DataFX to define the routing and mvc based views on the client.
Some days ago I copied all the DataFX sources to GitHub (https://github.com/guigarage/DataFX) and currently trying to create a new version based on the modules that are maintained by me. Maybe I will extract the MVC related stuff and create a new framework based in it, we will see. What I currently can say is that I plan to work on it the next month next to the Dolphin Platform since I think a combination of both will be a good fit.
I would use this combination today to create applications but yeah, I'm the main developer of both frameworks so the choice is quite easy for me ;)
As you mentioned JSF I think that Dolphin Platform is a perfect match for you since one idea of the framework is to have a modern successor for JSF that can be used to create desktop & web based applications but provide managed controllers on the server. We provide a cool maven based jumpstart (Maven archetype) that will give you a quick introduction and a runnable client / server application with a desktop and web client in 2 minutes: https://canoo.github.io/dolphin-platform/#_dolphin_platform_jumpstart
We are interested in deploy functionality inside Alfresco.
I have noticed that the newest versions of Alfresco Share are based on Spring Surf.
So we have ruled out WebScripts as an option. Are them old fashioned?
Before start with Spring Surf and in order to be practical: what about extend Alfresco with our own controllers and JSP views?
I’m not familiar with WebScripts or Spring Surf. It could be so interesting to debate the advantages/disadvantages of using these technologies.
I’ll start with some points related to our team which is used to Java programming.
CLASSIC SPRING MVC / JSP VIEW
Advantages
- We are familiar with these techlonogies
- Template hot deployment is possible with JSP. Ok. It’s true that JSP aren’t templates, but they will be our view.
SPRING SURF
Advantages
- Lack of the necessity to know Java programming. Ok but we can program in Java
Disadvantages
- We have to learn a new technology.
- Springsource has it in incubation status. Perhaps we’re going to learn a new technology that won’t achieve success.
- Is there any project adopting this technology apart from Alfresco?
Thanks in advance. Best regards
ATV
Tackling one of the sub-questions: Alfresco WebScripts are built on top of Spring Surf! A Webscript is an implementation of org.springframework.extensions.webscripts.WebScript
With WebScripts, you also have the choice of writing your controller in either Java or JavaScript, which I don't believe SpringMVC offers.
Hopefully someone else can advise you on the rest.
A big disadvantege of SpringSurf is that you need a webscript, usually with a javascript acting as a controller and the javascript API is much less powerfull than Foundation Services API. Of course, you can write a Java backed webscript to gain access to the foundation API, but this is extra work.
An advantage of SpringSurf is that the look & feel usually appeals more to end users due to the old fashioned look of JSF based UI's comparing to the javascript libraries like http://script.aculo.us/ .
We are in the phase of evaluating some of the frameworks for portlet development. As of now I know of below 3 options. I would like to know your experiences with them and others
Struts 2
Spring Portlet MVC
Liferay 6.x MVC Framework
Please try to share Pros/Cons in following areas along with what you think is important
Speed of development
Maintenance
Ease of development with Geo Distributed teams
Please suggest any other frameworks which can be used as alternative with some pros/cons
From my point of view, using MVCPortlet and JSPs without Spring-mvc or Struts is suitable enough only for a simple portlet. I would definitely try at least a sample portlet to see how it works if developers haven't done portlets.
The only advantage of using Struts is that the Portal itself is heavily using it because spring-portlet-mvc is relatively new. So that you can learn a lot from variety of examples. Otherwise the technology afaik is dying (regarding portlet development) and if you haven't been working with Struts, the better option for you would be go for spring-portlet. I've been using spring-portlet for more than a year, and I must say that I was amazed how well integrated it is into portlet container and what features are implemented there. You can do practically everything as with spring-mvc (servlet spec), except for some minor support that I found redundant anyway.
Speed of development
an experience developer that knows spring-mvc can create a robust application with only a few spring controllers.
Maintenance
The amount of source code is significantly lesser with spring then struts. Spring-portlet has implemented 268 JSR, so that it saves couple of workarounds.
Ease of development with Geo Distributed teams
I sense you are going for something bigger, so that ask developers about their experience with Spring and Struts and make your choice. Anyway, Liferay is a pretty robust portal solution and to "learn" it and find a way to use it properly is more important issue than how to develop portlets.
Also be interested in developers knowledge of Javascript. If they don't know JS much or you don't have front-end developers, I would probably give a shot to Vaadin or GWT portlets. However Liferay has a very good client-side support and you'll see that a lot of things can be done on client-side in Liferay. JSP tag libraries provides a significant amount of dynamic behavior and Alloy JS framework that is built on top of YUI provides you with a nice environment and it is not hard to use.
EDIT: The comparison of Struts vs. Spring is regarding portlet specification, where (my opinion) struts support is an old Volkswagen and spring is Bentley continental gt :-)
ALSO: The key tool for Liferay portlet development is so called ServiceBuilder, which is a code generator, that generates a significant part of your persistence layer, remote service layer based on domain model and metadata. If you choose to use it, your portlet is automatically Spring based. And I'd recommend to use it, because once you try it, you won't let it go. For instance, to create Ajax calls from client-side to remote services is a question of 2 minutes to set it up and be able to call them and even get the return value. Hibernate setup is fully optimized and ready to use after you run servicebuilder. And much, much more.
It's Really depend on your requirements, since liferay MVCPortlet are just simple sub-classes of the javax.portlet.GenericPortlet, i dont think it's a fair comparison between web framework such as Strut 2 or Spring MVC.
I suggest using Spring MVC or Struts 2 for 168 & 268 JSR portlet if you want cross portlet-container portability or if you have more complex presentation requirements, you should find a list of the pro and cons of the two framework everywhere .
If you requirement are very simple then go with liferay MVCPortlet or even the JSPPortlet.
I have used 2) and 3) but not 1) - I'm not a fan of Struts.
Spring MVC gives you the power of Spring and plugs seamlessly into a Spring back-end as well as allowing the ability to wire to the Liferay Spring services. Provided you use MVC correctly and separate Controller concerns into separate Action classes then this is an extremely scalable and flexible choice and works well when coupled with Liferay.
Liferay's MVCPortlet provides much less in terms of flexibility but when used properly it is still highly scalable and a very useful choice. It also ties in to the Liferay IDE/Liferay Development Studio which provides benefits during development. If you have access to the Liferay Developer training then there is extensive coverage on Day 2.
Overall Spring has the greater benefits but also comes with the larger learning curve and greater risk of doing things incorrectly and hits you harder when done badly. Liferay's MVCPortlets done badly end up looking like vanilla portlets and as such is the lesser evil. Personally I use MVCPortlets for small tasks and Spring MVC for the larger ones.
In both cases 'doing it well' involves correct use of the framwork and annotations.
Liferay also supports Vaardin and have released the new Mail Portlet using it. I haven't used Vaardin but certainly plan on it and have heard good things so far.
From the ease-of-development point, I think the Vaadin is one of the best. The new Liferay IDE 1.2 already includes the Vaadin support making it very easy to start with it.
The same goes for application maintenance and APIs. With Vaadin the application code is simply Java code and that makes it easy to divide the work, and maintain the existing code (OOP benefits).
Already a good number of "add-ons" for Vaadin that demonstrate how the Java code can be "componentized" and development split across the organization(s).
Only downside comes from the fact that the Vaadin libraries are shared with all the Vaadin- portlets in a portal, which means they should use the same Vaadin version to keep the deployment easier.
Anyway, I'd say quite good match for your needs.
Right now a lot of my applications use GWT-RPC for retrieving POJO's from a GWT RemoteService which in turn calls a Web Service (SOAP) to get the data. I am evaluating Flex and didn't really see anything truly analogous to this simple architecture. Anything I may have missed?
AMF is Adobe's compact binary message format for use in Flash / Flex applications. BlazeDS is the open source reference implementation for Java, using essentially nothing more than a simple "message broker" servlet to handle requests. This is similar to how services are exposed in GWT, although Blaze uses a single servlet, not multiple as in GWT.
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS/
http://download.macromedia.com/pub/labs/amf/amf3_spec_121207.pdf
BlazeDS, particularly with Spring Integration.
Does this help you? I'm not too familiar with GWT-RPC, but is the AMF protocol what you're looking for?
As others have mentioned, the main choice here is BlazeDS, which is Adobe's open-sores server product for exposing flex-native server RPC and messaging. BlazeDS on its own is a bit clunky, and if you use Spring on the server, there is a slick integration available between Spring and Blaze.
Another, 3rd-party alternative is GraniteDS, which does much the same thing as Blaze, but is Spring-friendly out of the box, and does quite a lot more than Blaze (e.g. runtime compilation and generation of SWF files from the webapp). I haven't tried Granite, but it looks pretty good.
I'm wondering if anyone has tried to use Flex to power the front end of an enterprise level application at all, and if so, what advantages/disadvantages did you find when doing so. I'm currently looking into a possible project that would have global users requiring enterprise level access and performance, and wondering if it would be prudent to call upon some of my contractors flex experience with this project.
Flex and Flash is a great tool for enterprise level applications.
Our general rule of thumb is to use Flex or Flash when the type of rich interface required cannot be achieved using html/javascript/ajax. In this event the rich UI in flash/flex should be built keeping in mind that its the "Presentation Layer" and apart from basic front-end validation all the work (server side validation and logic) should be done by the underlying application. I would say that flex/flash should be used ot build component parts of an interface, not the whole interface.
The advantages are mainly in achieving a much richer and more stable interface than html/javascript/ajax type interfaces. In my experience the development time may not neccessarily be quicker, but the end result can be much greater!
The disadvantages I have experienced come in the form of finding the right kind of developers and finding developers to take over projects if contractors are used.
I have been using it for exactly that and, like anything, it has it ups and its down. One thing I have found impressive is its support for SOAP based web services. Your requirements here are very vague - but I would say that using Flex has been a positive experience for me.
There are thousands of production Flex enterprise apps out there. If you are looking for help check out these companies:
Gorilla Logic
Cynergy Systems
Universal Mind