3 Replies Latest reply on Oct 29, 2006 3:29 PM by davidmedifit

    Cornered yet again by Flex - a tale of woe

    blahxxxx
      After being a huge believer in Flex at first, and commencing development at Beta 1 and committing serious resources to Flex development, I'm beginning to change my mind and wonder if we haven't made a mistake. It may be time to rebuild this system without Flex.

      Seemingly minor limitations have turned into massive roadblocks that threaten our entire application.

      We've been through a long development process with Flex and we've just been through a long serious of ducks and weaves to evade Flex's limitations. This one looks like the final duck - we've been blown out of the water.

      Here's the trail of problems and our desperate actions to solve them:

      Major issue #1:
      we MUST be able to display HTML pages cleanly integrated with out application. Investigated the iFrame kludge but refused to build major requirements around brittle tricky/kludgy fixes. Dead end.
      Solution 1: Give up on a single, monolithic Flex app. Break app into many small apps and integrate into lots of HTML pages. This was a MAJOR undertaking requiring a significant rebuild of the application. After many months of time and effort this succeeded and we had a completely rebuild app composed of many small Flex apps living in HTML pages.

      three months later, a new major issue arises:

      Major issue #2:
      we MUST allow the user to fill out a form of Flex fields, save the form, and then view the results in HTML.
      BIG PROBLEM - if the user wants to make further edits after seeing the HTML, they should be able to hit BACK and edit the field values - in HTML the field values would still be there. Because it is Flex, all field values are gone.
      NON-SOLUTION after the user fills out the Flex form fields, save the values to a shared object so if the user hits BACK then the field values can be reloaded. Sounds good. But how the heck to know if we arrived at this page because the user has come here using forward/back? This idea was discarded.
      NON-SOLUTION leave the Flex form and fields on screen and instead POP UP the HTML page over the flex app. These seemed to work fine until it became apparent that Firefox was randomly blocking the popup window opened by Flex. This idea must also be discarded because of this random behaviour.

      SHOWSTOPPER. So now after almost a year of development our project has been brought to its knees by the most (seemingly) minor technology issue - how to fill out forms and move forward and back after seeing the results in HTML. This is a basic requirement of many internet applications - anyone who has used this forum is familiar with the "preview message" button and the need to smoothly edit, then display in HTML - it cannot be done in Flex.

      Its heartbreaking and we now have to seriously consider ditching Flex entirely and just build a plain HTML application.

      We've solved many massive issues along the way and learned an awful lot about Flex and how it works with web services.

      We've built a high performance back end server and built our own customer authentication system.

      Many hundreds of thousands of dollars have been spent to get this built.

      And we've been beaten by Flex and its inability to cleanly integrate with the browser.

      You know you're in trouble when PHP/HTML starts to look like it would have been the right development decision instead of Flex.

      Hopefully come day flex will be able to cleanly display HTML, retain field values between forward/back and not interact randomly with firefoxes popup blocker.

      When we identified technology risks at the start of the project we looked at things like SOAP, performance, authentication, database XML handling etc. I would never have thought that the major risks were in fact "ability to display/integrate HTML", "forward/back behaviour" and popups.

      There's still hope that some new trick will be thought up to solve our problems but right now it is looking like we need to rebuild the UI without Flex.

      Flex certainly has its uses, but I can't say its right for applications that need to integrate with HTML.

      Andrew Blah
        • 1. Re: Cornered yet again by Flex - a tale of woe
          davidmedifit Level 1
          Andrew,
          I'll need some time to digest all of this, and bearing in mind my inability (at this moment) to mind read all of your requirements, etc, let me take my best stab at this:

          "we MUST allow the user to fill out a form of Flex fields, save the form, and then view the results in HTML."

          May I ask why in HTML? And why the need to accomodate the "Back" button? I'm thinking, right now, you don't need a Flex app at all. One of the issues that RIA's try to address is the "click-next-back" phenomenon. I don't know about you, but the "back" button has wreaked havoc in enterprise apps I've created up to now!

          "And we've been beaten by Flex and its inability to cleanly integrate with the browser."

          There are ways to integrate Flex with the browser, however, it seems to me that you want to treat the Flex app as "one in the same" as the browser. Flex apps are contained within a Flash player. That's NOT the browser. Generally, (believe it or not) that's considered a good thing! The Flash player has attributes and actions that perform the same in ANY browser, on ANY operating system. Flex apps are NOT the browser, thus integration with the browser is fairly rudementary (read URL parameters, etc).

          Again, I'm not a mind reader, but, it would seem to me, that you MAY have wanted a HTML system, jazzed up with a little AJAX. Have you looked at ColdFusion 7? It allows you to create Flash based forms, fairly easily (using CFML). It's something I've used successfully (I can give you public examples if you like).

          I'd like if you could respond, as I'd like to know more about what it is you are trying to accomplish, and the scope of your project. If we can't find an answer to your problems, maybe others can learn from them.

          "Flex certainly has its uses, but I can't say its right for applications that need to integrate with HTML."

          I would tend to agree. If you want a HTML app, use HTML technology (e.g., HTML, AJAX, Javascript). If you want a RIA app, use RIA technology (e.g., Flex)

          I'm hoping it's not too late to solve your problems, before you give up on Flex - then again, like I said, I'm not a mind reader. Hope I helped some.

          Cheers,

          David
          • 2. Re: Cornered yet again by Flex - a tale of woe
            blahxxxx Level 1
            Hi David

            Thanks for your response.

            I would suggest that many applications need to integrate well with HTML - even Flex apps.

            What it boils down to is that our entire project is now in danger because when Flex opens a new browser window or a popup, it randomly triggers the Firefox popup blocker. 12 months work down the drain because of this.

            It's a disappointing outcome for a major software development project.

            Thanks for your interest.

            Andrew
            • 3. Re: Cornered yet again by Flex - a tale of woe
              davidmedifit Level 1
              Andrew - I feel your pain, I've been in situations where seemingly insignificant details torpedo entire projects. To be fair, it seems (on the surface) that your issue is with FireFox, and not Flex (unless Flex opens new windows in a non-web-standard manner?).

              Was there a reason why this wasn't a problem during development? Is it anything to do with the test / production environments? As a matter of interest, what is the code you are using to create the popups? I'm no expert, but would lend a hand if I could.

              Cheers,

              David