Discussions

News: The JSF Flex Project

  1. The JSF Flex Project (18 messages)

    The goal of JavaServer Faces Flex is to provide users the ability to create Adobe Flex components as JavaServer Faces components. In this way, developers who are unfamiliar with Flex can be abstracted away from it and focus on linking components to legacy information. Ji Hoon Kim describes the state of the project and how to get started. Read the article

    Threaded Messages (18)

  2. April fools?[ Go to top ]

    Is this from the guys behind SQL on Rails? I have written my take on this project JSF Flex Project - april fools comes late this year, I'm sorry you people spent time writing this software.
  3. Re: April fools?[ Go to top ]

    Is this from the guys behind SQL on Rails?
    I have written my take on this project JSF Flex Project - april fools comes late this year, I'm sorry you people spent time writing this software.
    Just read your blog post, basically you summarized my feelings as well. Ilya
  4. Re: April fools?[ Go to top ]

    Is this from the guys behind SQL on Rails?
    I have written my take on this project JSF Flex Project - april fools comes late this year, I'm sorry you people spent time writing this software.
    Since you removed my comment on your personal blog (I assume you are for freedom of expression and opinion), I will re-post it here. You are perfectly free to dislike a piece of software. You are even free to define JSF complicated and Flex very easy (although I believe they are both very easy). What you are NOT free to do is to say (citing straight from your blog)
    What is depressing is that the people behind the JSF Flex Project probably have spent time on this utterly stoopid project. I am sorry that you have wasted time on this and I am sorry that I have to tell you that you have wasted your time.
    If you are not able to see a use for it, it does not mean that one does not exist; I believe you have wasted much more time at showing how arrogant you are. What ingenious piece of software have you produced? Who are you to judge a product without even seeing it? For the sake of interest, I am in no way linked to this project.
  5. Re: April fools?[ Go to top ]

    @Alessandro Santini: your comment is on the blog. I just wasn't awake at 05:18 CET to approve it. History will be the judge of whether my comments where unjust and whether I am an incompetent and arrogant person.
  6. Amen![ Go to top ]

    JSF is horrible. I just came out of nightmarish project where team of junior programmers happily marched into JSF/faces hell without even knowing it. Just live Flex alone, if you have decent understanding of JSF - anything else is a piece of cake
  7. Re: The JSF Flex Project[ Go to top ]

    Sounds like a very interesting project...perhaps a good way of utilizing the power and maturity of Flex without abandoning Java and without having to wait for JavaFX. I think JSF is a good choice too given its market share despite fierce competition between Web frameworks. Congratulations on starting it and best of luck... Cheers, Reza
  8. Re: The JSF Flex Project[ Go to top ]

    Could work out nicely if existing html applications can run as flex
  9. Re: The JSF Flex Project[ Go to top ]

    Would be nice if the project actually offered some downloads... http://code.google.com/p/jsf-flex/downloads/list (empty at this point in time)
  10. Clarification regarding article + project[ Go to top ]

    I would like to clarify couple of matters regarding the article + project. The main reason JSF was chosen for bridging Flex to Java web framework was due to similarity in design and architecture. After reading articles and books regarding Flex, I was quite intrigued with the similarity in design. Now this is not to say that there exists a direct mirror in terms of design and architecture, but there did exist various similarities. Of course I later found out that Macromedia, Inc was one of the expert groups for JSR 127, which made sense of their similarity. So that is the main reason I decided to bridge the gap, since the bridging would be rather simple with the similarity in design. Another thing to add is that the main purpose of this project is to (1) allow easy creation of Flex applications within the JSF framework without purchasing of FlexBuilder (2) allow easy data mapping from Flex components to managed beans of JSF framework As for the comment regarding abstracting Flex technology, it was solely stated due to the fact that I consider rendering of component data to different technology to be one of the highlights of JSF technology. In no way did I mean it to say that Flex is difficult, but it is bothersome to (1) create the Flex application simply with the standard Flex SDK (2) map the fields of Flex components to Java One reason that there doesn't exist a download WAR is because the intention is to provide a download only when the members of the project deem the code to be matured to the state that others can view it. Otherwise, it would simply degrade the project's competency. Finally, I personally do not think that even if the project fails that I would have wasted my time. Since my initial intention of spanning this project was to play around with various technology and to acquire experience in areas that I might not have gained otherwise. So of course I would love to see the project succeed and have many use it, but I think I would still not regret starting this project and working with others, even if the project does not succeed to our expectation. Hopefully the above statements clear up some vagueness and since the main purpose of this article was to see the reaction of the group and to possibly acquire interested members to the project, I hope it has served its purpose. Also with the JSF community starting their stride in improving the performance, easing the capability of using the framework, and adding additional functionality with upcoming releases, we are looking to the future where JSF will be more pleasing to the web community. Thanks!
  11. A few days back Exadel announced a similar offering although a commercial one. Here it is: http://www.theserverside.com/news/thread.tss?thread_id=50568
    The main reason JSF was chosen for bridging Flex to Java web framework was due to similarity in design and architecture.
    I don't think this is true. JSF is a server side technology, Flex is a client side technology and does not depend on the server and the reason why the server can be in java, php, ruby or just about anything that can understand http/xml or amf. So I think the premise on which these 2 work are very different. One example building stateless servers (apps without any reliance on http sessions) is the norm in Flex whereas JSF is powered by a server. This is also true for any JS based ajax framework.
    Another thing to add is that the main purpose of this project is to
    (1) allow easy creation of Flex applications within the JSF framework without purchasing of FlexBuilder
    (2) allow easy data mapping from Flex components to managed beans of JSF framework
    These are valid reasons. A team which has existing investments in JSF can surely use this or Exadel's product to get up and running fast. In fact this is a better route than introducing Flex on its own as the 2 technologies will constantly pull in 2 different directions if Flex is used for what it is designed for - lesser server dependency.
    Finally, I personally do not think that even if the project fails that I would have wasted my time. Since my initial intention of spanning this project was to play around with various technology and to acquire experience in areas that I might not have gained otherwise.
    Absolutely, and the reason most of us contribute back to opensource. But please do understand the differences in application design using JSF vs Flex. Flex can definitely bring in some components to JSF for free but without the licensed version of Flex I am not sure rich components like charts, OLAP and Advanced datagrid are available.

    There are some sub-optimal efforts in Flex camp. There are frameworks trying to bring in MVC paradigm to Flex similar to Struts which again in my opinion is not really required. Thanks http://sunilabinash.vox.com
  12. A few days back Exadel announced a similar offering although a commercial one. Here it is: http://www.theserverside.com/news/thread.tss?thread_id=50568

    The main reason JSF was chosen for bridging Flex to Java web framework was due to similarity in design and architecture.
    I suggest this quoted statement is almost wrong. May be keeping the MVC is only the common part. The design patterns and development paradigms are very different. I think, this is a major problem why one guys do not understand others (in both directions). We had the mirrored situation a couple of years ago when we introduced the integration between GWT and JSF. That G4JSF project even used to be included into the Ajax4jsf. I know a couple of guys (may be three of them :) who like this integration, but, in general, the product is dead already. Why? Because, we met a lack of understanding from both sides. GWT guys asked why they needed something big on the server side if they had a RPC calls already. JSF guys looked at the very primitive set of GWT components also refuses the idea. Current situation is similar, but not equal. I suggest Flex guys still does not need such stuff. So, there is no reason to come to them and say "look, this is cool!!!". It is not (for them in particular). Do not create an illusions. JSF core is designed in 2002, far before all those Ajax and RIA boom. JSF really needs the richness of the Flex now. So, I am glad to see that at least two projects (one commercial and one open sourced) enables this integration.
  13. Re: Clarification regarding article + project[ Go to top ]

    Hello Ji, Thanks for doing this project. I help lead the team that develops JSF under the JCP and I've long felt that such a project was quite feasible and justified. Back in October of 2002, I presented JSF at Macromedia DevCon in Orlando. One of the sponsored lunchtime keynotes was from Adobe on Flex (or whatever Flex was called in 2002). While sitting in this keynote, it became very clear that JSF and Flex would work well, particulary, as you state: (1) allow easy creation of Flex applications within the JSF framework without purchasing of FlexBuilder This was the most apparent usecase. I would like to establish contact with you personally, please send me an email at ed dot burns at sun dot com. Thanks for creating this project! Sincerely, Ed
  14. Ed, your book on JSF is the best on the market, but besides your book, there is really nothing good about JSF at all. Saying that creating Flex applications (to save $500 dollars on a flex builder tool, which one doesn't really need to develop Flex apps) using JSF is a good project, is like saying that embedding assembly in a java program would be good. Why not? You might be able to more efficiently represent an algorithm. Ilya
  15. Re: Clarification regarding article + project[ Go to top ]

    (1) allow easy creation of Flex applications within the JSF framework without purchasing of FlexBuilder
    What? So you remedy it by providing overhead and making the process less efficient? Also, I can't understand today's developers working at current market rates whining about $500 dollars or so. If the technology you're using is not making you $500 more productive and you can't invest that much it it, you should really either consider using a different toolkit altogether or this profession is not for you.
  16. Question for author[ Go to top ]

    So why did you not try to implement a Render Kit but instead augment the JSF lifecycle? Was it impossible to integrate Flex using a custom Render Kit? Did you explore this approach? If you didn't, I think you should... All in all, i think the effort has to be applauded. JSF may not be the best web framework, but I think the Java community really needs a standardized web framework. Hopefully we get more render kits for JSF, anyone know if there's a Swing render kit out there?
  17. Additional Response to various posts[ Go to top ]

    First of all I would like to thank everyone for your inputs. Regarding the post of renderKit : The question regarding the renderKit is absolutely true and to be honest I initially thought to create it as a custom renderKit. However, in honesty, when I did began the coding for this project several months ago, the project itself wasn't broken into several maven projects as it is now. Recently I have been thinking of refactoring much of the code to make it more fitting as a JSF component library, like you proposed, and so I thank you for your input since it gives me additional motivation to make the change. Regarding the post of JSF and Flex being different : I guess my capability in wording my thoughts aren't that great, there's a surprise. Whew, been trying to improve it, but I guess it's more difficult than I imagined. Anyway, I do know that JSF and Flex do have a deal of difference between design and architecture and do realize that Flex is suited as a client side technology whereas JSF is server side technology. However in my previous post, I simply wished to show why I chose JSF as a web framework. My similarities that I was thinking of were such things as Flex being componetized with component, formatter, and validator and top ActionScript and top JSF component both having UIComponent as its name, which gave interest to me when I first learned of Flex and simply made me think of JSF while reading the book. So there were similarities here and there and because JSF brings flexibility in manipulating/creating the structure necessary I thought to choose it. Regarding the post of illusions : Haha, what is you say is true. I guess I failed to point out the target audience for this article. I did have JSF developers in mind when I began writing it and perhaps that's the reason that my wordings came out the way they are. Yes I do agree that individuals who are not interested in JSF will not jump into the project, since JSF is not appetizing to everyone. But things might change in the future and if they do, hopefully this project will be ready for various group of developers. Once again thanks and I will contact you Ed!
  18. Re: The JSF Flex Project[ Go to top ]

    JSF start was not good. But with JSF 1.2.9 + Facelets 1.1.14 + Seam 2.x + Jboss RichFaces 3.2.x + AJAX4JSF, JSF is now quite mature. We finished a project in JSF having many CRUD pages and some interactive Dashboards, We all are impressed with the outcome and productivity. Their were many open-source components created by community in OLAP area which we could easily reuse. JSF has a strong lifecyle and design concepts(Navigation Flow, Front Controller, Validators, Convertors, State management, Error messages etc.), with Facelets creating custom components is easy. RichFaces 3.2.x gives good looking GUIs With JSF 2 many more things are getting addressed (Custom Components, Skinning and AJAX are my favorite). I also have worked on Flex3, Animation is very easy in it. Also it works in Flash pugin and plays on proxies on client side. On the other hand Flex 3 is still not as fast as HTML even with AMF and its framework compression in flex 3. Integration work of Flex and JSF is important and respectable work. If we can have components created in Flash in combination with JSF, it will be a very powerful web offering for future. Also some work on JSF sandbox using JSON proxies needs to be initiated.
  19. Please refer to the project's website for the most up to date information as there existed much improvement to the project since the writing of this article. Couple of noticeable changes are : (1) Writing of MXML_BASIC renderKit that wraps around HTML_BASIC renderKit of Myfaces + Mojarra implementation. This will allow users to use HTML components alongside JSF Flex components. So the name of component14, component15 projects have been changed to renderKit14, renderKit15 projects, with renderers generating the preMxml, mxml, swc, swf, and etcetera contents. Of course the actual task of creating preMxml, mxml, swc, and etcetera are still handled by the other maven projects [commonTaskRunnerImpl, fileManipulatorTaskRunnerImpl, and flexTaskRunnerImpl]. Love modularization!!! (2) All the JSF Flex components should still be under , but this tag must belong beneath . (3) There now exists debugging enabled for FireFox:FireBug for ActionScript actions. (4) JsfFlexHttpServicePhaseListener will be added this weekend or the following weekend for service calls from ActionScript to back end for populating complex components [i.e. DataGrid components which allow dataBinding by having DataGridColumns component's columnData field]. (5) Usage of Dojo 1.2 with breakage in MyFaces tomahawk component [don't remember if this writing was prior to or after the breakage in dependency]. So there exists no longer any dependency other than impl to MyFaces project, which is implied in prior statement with current support for MyFaces + Mojarra 1.2 impl. (6) Usage of JSON jar for cleaner code and for future preparation when there might be more service requests from client side to server side. (7) Added components under mx.states package. (8) Added Jython Flex Runner impl which will be tested when Jython > 2.5 is publicly released for maven repo. Default is Ant Flex Runner impl and I simply created Jython to simply play around with it and for Python lovers out there. (9) Improvement in various parts of the code [i.e better packaging of javascript and actionscript files and etcetera] too many to name [still ongoing]. Thanks for the interest in the project and if interested please sign up to project's mailing list!