Flex on Grails – Rich Internet Applications With Rapid Application Development [5th IndicThreads Conference On Java, 2010, Pune, India]
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Flex on Grails – Rich Internet Applications With Rapid Application Development [5th IndicThreads Conference On Java, 2010, Pune, India]

on

  • 1,619 views

Session Presented at 5th IndicThreads.com Conference On Java held on 10-11 December 2010 in Pune, India ...

Session Presented at 5th IndicThreads.com Conference On Java held on 10-11 December 2010 in Pune, India
WEB: http://J10.IndicThreads.com

------------

Session Abstract
Grails provides an application developer the productivity and programming paradigm of Rails while continuing to use the power of Java and J2EE where appropriate.

On the browser side, most clients use HTML and CSS, trying to provide a desktop feel: even using modern Javascript libraries it is a difficult task. Flash enables one to build rich UI, however the steep learning curves of Flex, problems with integrating flash components on traditional web page and the need for specialist designers to produce flash content is a strong deterrent.

Enter the Flex Grails plug-in. Flex on Grails lets you combine the processes and technologies of rapid application development to the creation of Rich Internet Applications (RIAs).

This session provides an introduction to Flex on Grails and benefits of Flex over an Ajax based web application. You will learn how to build / debug and run an application using Flex on Grails. The session is based on the experience gained while building an internal CRM application which took us days instead of weeks to develop!

Statistics

Views

Total Views
1,619
Views on SlideShare
1,603
Embed Views
16

Actions

Likes
0
Downloads
32
Comments
0

1 Embed 16

http://j10.indicthreads.com 16

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Why Rich internet applications? Better User experience - As developers we use Eclipse IDE to develop code, prefer to use Outlook/thick client over web based email clients. Thick client have richer experience over web based applications. Prefer Excel over Google spreadsheet. The demise of client-server architecture was triggered by the pains of managing multiple desktop installations. But at the cost of ease of use for the end user. No Browser Compatibility Issues – Long hrs trying to make sure the app works on multiple browsers. Testing effort. Client-server architecture with clear separation of concerns - No long jsps with logic, etc. Better UI architecture. Yes, desktop applications are rich and robust; you can do anything the OS permits. But their deployment model is a borderline nightmare. The logistical complications of trying to get thousands, if not hundreds of thousands, of clients to run the precise version of your software at the exact same time are immense. Often, you need to provide support to handle multiple versions of desktop clients connecting to your back-end infrastructure. To cope, the only feasible option is to group large collections of enhancements and fixes into massive releases. And that’s not taking into consideration how exponentially more complicated it becomes if you’re supporting multiple platforms. Of course, with the web, you can release enhancements and fixes as fast as you can code them. Your releases are usually as simple as pushing out the new database changes and copying over the latest set of files. Bingo! Now all your users can take advantage of the latest and greatest updates transparently. RIAs solve this problem by incorporating the best of both worlds. RIAs are a technology that gives businesses-feature velocity and rapid deployment through the centralized internet deployment model, while providing users a desktop-like experience. RIAs bring back usability by enabling developers to give their users a compelling and fluid experience with that feeling of a live application (versus completely reloading a page every time you click something). That’s the core ingredient to providing users a sense of engagement. At the same time, the deployment and accessibility model remains the same—users can load these applications from any machine and all be running the same version. The best part is true platform neutrality; the same application yields the same look and feel regardless of environment. Use AJAX: • To make incremental usability enhancements to an existing Web site. • For building “widgets” that require the work of a small team of developers. • When you have existing, internal JavaScript and HTML expertise. Some examples of AJAX-appropriate uses could be navigational elements, simple calculators and client-side validated forms. Use Flex: • When you need to develop applications that require a robust, scalable rich Internet application. • Where you require sophisticated and interactive data visualization. • When video and audio playback or Web camera and/or a microphone capture is a requirement. • Where you require complex animation or bitmap manipulation. • When the graphic design is core critical to your business needs. Flex would be the right choice for product configurations, workflow/process/inventory management applications, video conferencing, playback and editing, immersive or entertaining experiences, data visualizations and management dashboards. Use Both: • When SEO and an immersive experience are equally important. • When neither framework meets all of your needs — for example, when video playback and HTML rendering are both required. Using Flex and AJAX together would work well for WYSIWYG HTML editors and user-generated content portals. Additionally, in real-wold use, Flex typically requires less coding to build the same or better functionality. The learning curve is somewhat steeper, but the development times are significantly lower. Why Flex? Better Penetration - The Flash Player 9 runtime is currently installed on 94% of the world's computers. Mature – Flex has been there for 5-6 yrs now.
  • Grails provides an application developer the productivity and programming paradigm of Rails while continuing to use the power of Java and J2EE where appropriate DRY - The question is: if there are tasks which are repetitive in the development process, why they are executed by humans and not by the framework? At RoR we can see the return of something that we had simply ignored: scaffolding. The framework generates automatically for the developer several artifacts which are usually related to repetitive tasks, like for example views and controllers. So, all the repetitive tasks are gone, and your work will be to only customize these artifacts. Neat! Convention over configuration - configuration files are unnecessary because the application is already well organized. The configuration, in this case, is the application itself! Why Grails Actually, it doesn’t matter. Your productivity boost will be basically the same. However, for the Java developer, already used to it’s syntax, Grails will be way more familiar, because it’s based on Groovy, which, by the way, have basically the same Java syntax (with some syntatic sugar). Your learning curve will be reduced on this case. Another important point is the fact that you’ll be able to reuse all your legacy code on a Grails project without changing anything on it (which is not a Grails advantage, because this same code reuse can be achieved using JRuby too). But, at the end of the day, this can be solved with a single question: which language do you prefer? Grovy (Java) or Ruby? Java? Go Grails! Ruby? Go RoR!
  • MVC framework options Cairngorm PureMVC Mate Swiz RobotLegs Parsley Communications / Messaging infrastructure options BlazeDS GraniteDS REST-based Web Services SOAP-based Web Services
  • In the next 5 mins, we will create a sample application Prerequisites [Grails-1.1] [Adobe Flex 3.0.0 or major] FLEX_HOME and GRAIL_HOME must be defined as environment variable!!
  • I have included the security plug-in to demonstrate how the plug-in help us in rapid development. Audit plug-in is another one which is impressive.
  • Maybe a resource to maintain the scaffolding plug-in

Flex on Grails – Rich Internet Applications With Rapid Application Development [5th IndicThreads Conference On Java, 2010, Pune, India] Presentation Transcript

  • 1. Flex on Grails Aniket Shaligram Talentica Software
  • 2. Flex for RIA
    • Why RIA?
      • Better User experience
      • No Browser Compatibility Issues
      • Client-server architecture with clear separation of concerns
    • Why Flex?
      • Mature
      • Better penetration
  • 3. Grails as RAD
    • Why RAD?
      • Scaffolding
      • Convention over Configuration
    • Why Grails?
      • Java based
  • 4. Architecture – TODO improve
  • 5. Sample App - teps
    • Grails Project Creation
    • Plugin installation
    • Generating domain class model
    • Edit generated domain classes
    • Modify config files to enable security
    • Generate Flex code
    • Start server and navigate
  • 6. Scaffolding
    • Grails Project Creation
      • grails create-app gsf-test
    • Plugin installation
      • cd gfs-test
      • grails install-plugin flex-scaffold
      • grails stark-security-install-full
  • 7. Sample app – domain model
  • 8.
    • Generating domain class model
      • grails create-domain-class customer
      • grails create-domain-class company
      • grails create-domain-class phone
      • grails create-domain-class address
  • 9.
    • Edit generated domain classes
      • Company
      • Customer
      • Address
      • Phone
  • 10.
    • Add to Config.groovy
      • gfs.security = true
    • Edit StarkSecurityConfig.groovy
      •   '/': Role.ALL_ROLES, to  '/**': Role.ALL_ROLES,
    • Edit BootStrap.groovy
  • 11.
    • CRUD Generation
      • grails generate-all-flex company
      • grails generate-all-flex customer
    • Flex compilation
      • grails flex-tasks
    • Start app-server
      • grails run-app
    • go to http://localhost:8080/gfs-test
  • 12. Does it really work?
    • Learning curve for Flex, Grails (Groovy, GORM), Generated code – Flex
    • Understand, Maintain Scaffolding plug-in
    • Separate frontend, backend teams
    • Costs – Flash Builder license
  • 13. Front end Design
    • Design of Generated frontend code
  • 14. Connectivity Options
      • BlazeDS – Flex Plugin
      • GraniteDS - GraniteDS Plugin
      • Webservices (REST, SOAP) - CXF Plugin
  • 15. Security options
    • Spring Security
    • Apache Shiro
  • 16. Deployment Options
    • Desktop : Adobe Air
    • Gaelyk app on Google App Engine
    • Grails app on Google App Engine
    • Grails War on standalone container
  • 17. IDE
    • Flash Builder
    • Springsource plugin for Grails