2 Replies Latest reply on Nov 20, 2009 5:37 PM by Arbi Sookazian

    Flexible Weld

    Arbi Sookazian Master

      from wikipedia:

      Application Development Process

          Define an application interface using a set of pre-defined components (forms, buttons, and so on)
      Arrange components into a user interface design
          Use styles and themes to define the visual design
      Add dynamic behavior (one part of the application interacting with another, for example)
          Define and connect to data services as needed
      Build the source code into an SWF file that runs in the Flash Player

      I'm wondering how/where CDI or Seam3 would fit in here.  Using Flex would obviate the usage of javascript (due to the Flash aspect) and makes your app cross-platform capable (i.e. no browser parsing/markup considerations/problems, typically with IE browser)?

      Is there a Seam/Flex integration example or Weld/Flex example?

      According to Mark, Flex is a way to avoid the browser compatibility issues, especially with regards to CSS and JavaScript. It's a reliable, predictable runtime that works the same way on all browsers.


      then there's graniteDS, BlazeDS, flamingo, fiji, the stack is overflowing...

        • 1. Re: Flexible Weld
          Nicklas Karlsson Master

          GraniteDS has examples for Seam (and will integrate with CDI). Weld doesn't care who integrates with it and pulls data/access the contexts etc.

          • 2. Re: Flexible Weld
            Arbi Sookazian Master

            ...even though JBoss Seam provides a lot more features, they do not necessarily make sense with a RIA front-end.


            I am a newbie in Flex but am interested in integrating Flex eventually with Seam and/or CDI implementation.

            I was reading the first chapter of Flex 3 in Action last night (I love Manning books).  I observed a couple of possible advantages of using Flex (or possibly RIA in general) over JSF:

            1) solves cross-browser support (e.g. no more of this bug in IE but not in FF for same test case, etc.)

            2) AMF3 protocol (binary ActionScript) to quickly transfer large sets of data from business tier to presentation tier.  With AJAX (XML in particular), there is lots of XML data being shuttled across the wire (message payload) which is not good in terms of performance.  There was something about RMTP, and publish/subscribe model rather than using AJAX polling to dynamically update your web pages.

            AMF encodes remote procedure calls into a compact binary representation that can be transferred over HTTP/HTTPS or the RTMP/RTMPS protocol used by Flash Media Server. Objects and data values are serialized into this binary format, which is generally more compact than other representations, such as XML.


            this does not include the aesthetic aspects (flashier front-ends) and charting support among many other things...

            but the proprietary nature of the product (e.g. no JSR?) makes a disadvantage although I believe the SDK was open-sourced.

            Not sure how reusable the Flex components are in comparison with JSF/RichFaces.  And not a fan of writing too much (or any?) javascript or actionscript, etc.  How reusable are those functions??

            Also, what are the differences b/n Seam remoting and AMF3 protocol (wondering if Seam remoting is binary-based as well)?

            Anyway, are there any general recommendations on using EE6/CDI and JSF2/RF4 vs. EE6/CDI with Flex3/4?

            I am also interested in knowing how I can use Hibernate manual flush (yes, now I know it's a CDI PE feature in Seam3) with Flex or perhaps manual flush is independent of what presentation tier technology you're using...

            I have a feeling that the official Redhat/JBoss supported recommendation is JSF2/RF4 with CDI or Seam3.  RIAs are not supported more likely...

            I heard that Silverlight uses C# classes, not something like ActionScript, which is better potentially in terms of debugging, reusability and portability...