Discussions

News: New Article: Introducing Java PureFaces: A New JSF Framework

  1. Java PureFaces provides a pure Java framework for building the web tier. Java developers can use good object oriented solutions, increase code reuse, speed up development, and simplify code maintenance without worrying about many web/http concepts. Matt Pickell and Ariel Raz describe the need for such a framework, their goals in creating it, and how it works. They are also seeking feedback on its usefulness as a published framework. Read the article

    Threaded Messages (17)

  2. I can't wait for someone to start up Java F%@#Faces.
  3. Wicket[ Go to top ]

    It's look like framework like Wicket but without it advantages
  4. What about GWT?[ Go to top ]

    GWT already works this way, in addition to being super efficient and Ajax-y. Either way, I prefer the fine-grained control over my markup, to be honest.
  5. It is so frustrating to see a new java web framework every other week. There may be 3-4 ways to build GUIs for the web - Browser driven (like GWT) - Server driven (like Echo) - Hybrid (JSP + Ajax magic) Can't we have all the framework owners come together and pool in their efforts? To build better tools/ide support (think EchoStudio, Instatiations or better MS Visual Studio) and extend frameworks to work on other devices apart from the browser (j2me, iphone, blackberry) and desktop. I am sure most of these framework project teams are doing it out of generosity and outside their official time. I respect what they are giving to the community. But it is not solving the problems of java world. For quite sometime Struts was the defacto java standard for building UIs, then comes Tapestry and others. Wicket, Echo follow and now GWT may be the flavor of the season. JavaFX is trying to get in somewhere there. Swing and SWT continue their own way. Mobile app development is not in the picture as we don't hear about mobile java frameworks at all. Hoping for a better world of java UI development .... Thanks Sunil
  6. Mobile app development is not in the picture as we don't hear about mobile java frameworks at all
    Really? Try ItsNat, mobile web is thought over very seriously.
  7. - Facility to develop composite controls - Easy to make template - Easy to generate code (pages + beans) for pages based on template. - Easy to incorporate chanages - Good IDE support. I think JSF Pure Faces does not have any of these above properties infact no jsf framework have all these features at the moment.
  8. Java purefaces summary[ Go to top ]

    Purefaces is a layer on top of JSF (currently using tomahawk) that supports any functionality that you get from JSF, but also allows you to use only Java with no JSP pages in a very simply and object oriented way. We are planning to start using Purefaces with RichFaces so we will also have AJAX support. In PureFaces you can test your web tier functionality with JUnit because all the code is in Java. To create a custom GUI component an object only needs to implement PureComponent, not extend any object like you need in other web frameworks. You can bind any of your object methods to buttons and links, and you can bind any attributes to input, output fields. I don’t think this is supported by GWT and it saves a lot of code writing. Purefaces is not a replacement framework, it is an extension for existing frameworks designed to add useful functionality (JUnit testing, any object binding, etc) and removing over burdensome functionality (maintenance of JSP/XML) in order to increase productivity and decrease long-term maintenance. --Ariel
  9. Re: Java purefaces summary[ Go to top ]

    Purefaces is a layer on top of JSF (currently using tomahawk) that supports any functionality that you get from JSF, but also allows you to use only Java with no JSP pages in a very simply and object oriented way. We are planning to start using Purefaces with RichFaces so we will also have AJAX support.
    So, with Purefaces, you'll write: InputTextComponent itc = new ...(); itc.setValue(someBean.getSomeProperty()); With JSP, you'll write: With a good IDE like Idea, the JSP way, IMO, is faster and not error-prone because Idea has code completitions/suggestions for jsp/html/xhtml and ELs.
    In PureFaces you can test your web tier functionality with JUnit because all the code is in Java.
    That's what JSFUnit is for.
    To create a custom GUI component an object only needs to implement PureComponent, not extend any object like you need in other web frameworks. You can bind any of your object methods to buttons and links, and you can bind any attributes to input, output fields. I don’t think this is supported by GWT and it saves a lot of code writing.
    I think JSF 2.0 will catch up with you guys in creating custom components.
  10. Re: Java purefaces summary[ Go to top ]

    This comparison is not quite right. Using your example, with PureFaces you would write something more like: new PureInput(anyObject, "someProperty")... where "anyObject" is literally any object. There is no limitation to backing beans only. In JSF you are required to use a backing bean, so there is no comparable JSF statement. As for testing, there is no need for a special Unit tester like JSFUnit, because you are able to test your entire application using only JUnit.
  11. Re: Java purefaces summary[ Go to top ]

    PureFaces does represent an interesting approach, but I'm skeptical about authoring my pages in pure java. Maybe I'm missing something? XHTML seems better suited to the task.
    As for testing, there is no need for a special Unit tester like JSFUnit, because you are able to test your entire application using only JUnit.
    You absolutely CAN NOT test your entire application using only JUnit. The problem with testing JSF using plain JUnit is that nothing you write for JSF runs in isolation. PureFaces doesn't change this fact. Beyond the most atomic tests, you will always have dependencies on the JSF environment. So without a JSF environment, you are extremely limited in the kinds of tests you can write. So there are two ways to add a JSF environment to your tests. You can create a mock JSF environment or you can run your components in a real JSF environment. JSFUnit takes the position that a mock environment is inherently cumbersome - not to mention, phony. So JSFUnit lets you do all your testing in the real JSF environment deployed inside your container of choice. You can write tests with the confidence that the behavior under test is the same as the behavior in production. Stan Silvert http://www.jsfunit.org
  12. It is quite an interesting approach to route the entire presentation and behavior of a servlet application through just a single JSF and a single backing bean. All html is programmatically generated. Nothing, I assume, prevents me from using adapters to any auxiliary templating frameworks for generating particular views. Did I get this right? What about the licence? Is there any source download and docs available?
  13. Next step for java Purefaces[ Go to top ]

    These are the possible future scenarios that we see for PureFaces: 1) A JSF provider (for example: MyFaces , ICEfaces , RichFaces , etc.) or Sun likes the framework and wants to support the purefaces capabilities, 2) Start an open source project, however, as a small company we would require significant additional support 3) Do nothing, we will continue using and developing it for our internal use on the custom application we develop for our customers. Your opinion is important to us, let us know what you think?
  14. Good Idea[ Go to top ]

    Last summer i was working on new cms based on jsf & richfaces , so, in the begining, i get some difficult to do it (inheritence...) but i get it working on finaly what i see in your purefaces is just what i was looking for so if it was opensource i could use it already. don't matter, you've to open your sources to community to start the job Good luck and hope see purefaces open soon
  15. purefaces source is now available at http://www.b6systems.com/javaPureFaces.html
  16. Java is not efficient in UI design[ Go to top ]

    A scripting language like XML, XHTML, JSP, ZUL, JavaFX script, does a better job in helping designing use interfaces. Besides, scripting languages are easier to be accommodated by IDE visual editors. The proposed framework seemly borrowed concepts from GWT and Wicket, however, those two technologies wouldn't fly without drag&drop or code-generation support from IDEs.
  17. I do not agree there. In a UI you have really differents part : 1) The UI management, automating UI behaviour, providing UI reuse and UI generated from configuration files, like menus created and updated depending on global UI state or user activity/context. 2) The design and editing of the real GUI content that is avalaible across many small file used and reused many time in your GUI. For 1), using an XML, JSP or anything alike will not help at all. The best way to do it, is just to code it in Java, and having a good object API support is invaluable for it. You may have to code somepart in javascript too. But in all cases, it's code you need, not XML/JSP/JSF. For 2), using a graphical editor and/or an XML based template is a very good solution as it allow fast coding, testing and prototyping. Most Web UI framework only offer the second part and make it very complicated to introduce really dynamic behaviour like adding or removing components dynamically. Theses framework make it very difficult to introduce a real MVC pattern, and make it difficult to deal with each part of you GUI as independant elements. For exemple, if you GUI allow to display several result set at a time in tabs, you must have a GUI model with all your results set listed, make it available in session, request or whatever you want scope and iterate over the list of result set to render the tabs. You can't simply just add a new result set in a tab, letting the UI framework deal with it. Next page rendering/update will not keep the full state easily. Classic GUI API like Swing, QT, .NET address both parts of UI making : you can do fast design of your GUI (using IDE), and manipulate complex object model using your programming skills for generic part of your UI. To be honest, web UI are really poor UI, even using most web 2.0 techniques. Simply because UI are not generic, making an MDI like UI very difficult to implement. So most web developper will not have the time and skill to make it by themselves. Some UI like Zk address both part of the problem, but there only a few there. And to be honest, it's easier one you have a full dynamic object model for you US to make a graphical editor for it, or just code design in an object programming language (do you really think gmail UI design is done in XML ?) than having just a templating/UI design technology and try to make a good generic and power UI with it.
  18. A scripting language like XML, XHTML, JSP, ZUL, JavaFX script, does a better job in helping designing use interfaces. Besides, scripting languages are easier to be accommodated by IDE visual editors. The proposed framework seemly borrowed concepts from GWT and Wicket, however, those two technologies wouldn't fly without drag&drop or code-generation support from IDEs.
    +1 So now we have yet another way for developers to "speed up development ... without worrying about many of the web/http concepts" (from the article). Learning HTML authoring, web standards, CSS, browser quirks, accessibility, usability, etc. are just some of the reasons many colleges and institutions provide web design courses. I don't think these UI design/development issues can just be abstracted away by adopting a Model 1 approach where there is no separation of concerns and business logic and presentation are in the same tier. I would much rather see an effort to teach the JSF developer community how to work directly with HTML rather than another technology that attempts to hide these 'worrisome web concepts' behind some kind of facade for programmatic UI generation. As developers it is easy to stay in the imperative language comfort zone and to look for ways to avoid writing HTML, but I think this is a mistake. With the right training anyone can become proficient in HTML. Also, web authoring tools like Dreamweaver can make the work a lot easier and more enjoyable. My two cents. -- Ian Hlavats JSFToolbox for Dreamweaver - Design JSF Pages Visually in Dreamweaver