Icefaces means1/28/2024 Now Sergey, regarding your suggestion that we just drop it, this must be a thought straight out of your dreams. We integrate across all popular IDEs, and fit seamlessly into your existing Java development best practices. We don't cram yet another tool down your throat in order to use ICEfaces. Furthermore, we know Enterprise developers want to work with the tools and development processes that they are used to. It basically dismantles the separation of roles between developers and designers, and can be extremely debilitating to both. With A4J you will need to wire all the Ajax interactions together manually, which is an extremely limiting deficiency in the A4J framework. This means that the Java enterprise developer can develop pure JSF applications and get all the benefits of Ajax without additional development consideration. With ICEfaces, our primary goal is to incorporate Ajax features into JSF in a completely transparent fashion. For those of you out there that are evaluating JSF/Ajax frameworks, I suggest there are other consideration besides component libraries that are important. ![]() We have also integrated our Ajax bridge with the OpenAjax hub, so are well-positioned to coexist with other JavaScript libraries that conform to the hub. The highest priority components for our community are the Tomahawk components, and in our 1.6 release we have made large strides toward dealing with MyFaces JavaScript idiosyncrasies. With the basic responseWriter mechanism in place, our attention has turned to ferreting out JavaScript incompatibilities. While I second that advice, ICEsoft remains committed to improving 3rd party component compatibility within the ICEfaces framework. With the current state of technology, mixing and matching will expose you to risk, regardless of which framework you pick. Some sound advice I heard given at a recent Ajax conference was to select a framework and component suite that delivers most of what you want, and stick with it. Until the JSF community can decide on a common set basic mechanisms for Ajax interactions within the framework, the utopia of trillions of interoperable rich JSF components cannot be achieved, and the development community should be aware of the underlying risks. This is an issue that transcends the framework, and you are misleading pmohanan to suggest that under A4J he will not be exposed to this potential risk. The reality is, that the mechanisms used to achieve this in different libraries may be incompatible. As Ted suggested, most component incompatibilities occur as a result of ajaxifying a component renderer with JavaScript and integrating those Ajax transactions back into the JSF lifecycle. As of several releases ago, the ICEfaces framework is fully compliant with the JSF responseWriter mechanism, which means that any well-formed HTML component renderer will function within the framework, and will automatically inherit the features and benefits of D2D rendering. You are doing pmohanan and other forum members a disservice by misrepresenting the ICEfaces technology, and by suggesting that trillions of other JSF component libraries will happily coexist under A4J, because your words and innuendos in both cases are filled with untruths. You would do well to abridge the gibbberish that you write to the topics and technologies that you understand. ![]() Sergey, You will be less glad to hear from me in person than Ted, as he is far more polite than I. Together we can find more reliable way how to accomplish it Using modern browser as a mirror for the server-side object is not only one way how to simplify the development. Just drop it and look forward to the future. Requirement to replace the original renderers with "Direct-to-DOM" ones is a showstopper for you. Closed technology is when you advise that developer "must use **only** standard JSF tags (f:) and ICEfaces tags (ice:)", when you have to decide do you need "to support a trillion component libraries" instead of just leave them working as they are, without any modification. ![]() Closed technology remains closed even the code is open sourced. BWT, the same will happen with Adobe going to open source Flex under MPL. (I am not going to argue about the marketing point of view, of course). If you are fighting against the whole world, open sourcing your weapons does not makes too much sense from the technical perspective. However, " closed architecture" and " open source" are not the same things.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |