Discussions

News: AJAX Renderer for JSF

  1. AJAX Renderer for JSF (32 messages)

    I am looking for comments on the usefulness of an AJAX rendering kit for JSF. I have used JSF and XMLHttpRequest in a couple of applications using both customized code and tools such as DWR and AJAXAnywhere. Has anyone thought of porting AJAX technology into JSF? I am current thinking about following the guidance offered by this article on how to create a custom JSF render so that JSF renders code directly in the web browser. Browser compatibility issues aside, what problems do you foresee? What custom components do you think people would use?

    Threaded Messages (32)

  2. Re: AJAX Renderer for JSF[ Go to top ]

    Daniel,

    I think you're missing a lot of stuff that's already out there. There's ICEFaces (http://www.icesoft.com/products/icefaces.html), which is pretty much exactly what you're describing. Then there are several JSF component that have Ajax functionality (Otrix, WebGalielo, MyFaces, Oracle ADF Faces, and even the components included with Java Studio Creator 2.0 EA). And there are a few frameworks for Ajax that work with JSF as well.

    JSF components are perfect for encapsulating Ajax functionality. You can find a full directory of JSF products here: http://www.jsfcentral.com/products/.

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    Kito D. Mann (kmann at virtua dot com)
    Principal Consultant, Virtua, Inc. (http://www.virtua.com)
    Author, JavaServer Faces in Action
    http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

    Are you using JSF in a project? Send your story to trenches at jsfcentral dot com, and you could get your story published and win a free copy of JavaServer Faces in Action!
  3. Javascript a no[ Go to top ]

    This depends on the environment you work in, in a high security area the usage of javascript might be banned, but this is definitely not the normality out there on the Web, it really depends on the project requirements whether you can use javascript or not, but without javascript you wont have an easy run with JSF anyway (although it is possible)
    the classical case is the requirement of commandlinks renderer to have javascript enabled once it is placed inside a form.
  4. Re: AJAX Renderer for JSF[ Go to top ]

    Thanks Kito for your comments. I am aware of many of the tools/components that you describe, especially ICEFaces. However I am looking at a more open source approach, thus ICEFaces does not fit the bill.
    Also many of them only enhance UI's with some Ajaxian functionality, see Three forms of AJAX: solid, liquid and gas. where as I am looking at more of a "solid" approach (like ICEFaces), with the JSF renderer coded in such a way that it handles browser degradation elegantly.
    The renderer would also mean that a developer would not need to handle any extra code, they would just use the Ajax JSF tags rather than the standard jsp, xml or svg tags.
    In terms of application security and JavaScript being unsafe, I guess DHTML/Ajax/javascript are things that have gone in and out of fashion over the past 10 years of the web browser-able internet. This will probably continue as internet based application development continues to evolve, however unless application providers are happy to have all the processing happening on the server, or unless they use Java applets, activeX or in future Microsoft XAML (and a windows based back end) the only other option left is Javascript. this is also built into the browser and is cross browser compatible, where as some of the other options are not.
  5. AJAX: the good and the ugly[ Go to top ]

    AJAX obviously has certain promise. AJAX is currently riding a wave of interest because of a single, amazing example of its power: Google Maps (I quote this over GMail, but GMail is a very good example as well for a more traditional enterprise data application that requires dynamic server-side validation and data population with AJAX).

    But the thread author's concerns for Javascript injection attack vulnerabilities is dead-on. XML requests will all have to be carefully validated and authenticated, and a state flow restriction model may be required on the server side (as in a turing machine type graph representation of where someone is in an app and a list of paths/requests the user is allowed to execute from there).

    Enterprise AJAX apps will require a first-class security analysis of the architecture, especially since AJAX apps are only useful in database-related activities, apps that are most vulnerable to injection attacks.
  6. Security and Ajax[ Go to top ]

    If you need it on the server side, it is rather easy to integrate some filtering concepts to prevent javascript hijacking etc....

    You have various filtering mechanisms in place already if you use java, on one hand the servlet filtering mechanism, on the other hand, you can use some generic phase listeners on the jsf side, also some kind of component based approach could be feasable via the validator interfaces so that security validation could be added via additional validators, even in ajax code, if the backend interfaces are done correctly.

    All those approaches do not prevent browser hijacking on the client, but it definitely prevents hijacked javascripts trying to intrude your system with malformed xml data, if applied properly.
  7. The CyberXP.NET AjaxFaces offers an easy, general and complete integration solution for JavaServer Faces and Ajax. This solution makes any JavaServer Faces UI component Ajaxable: either trigger Ajax process or change user interface using the output from Ajax process.

    Also Following the link for a topic "Where is AJAX?!" in AjaxFaces Users Forum, you will find a brief introduction about creating Google-Suggest with AjaxFaces.
  8. AJAX Renderer for JSF[ Go to top ]

    I am looking for something similar currently.
    Doing a simple Google search for "AJAX" and "JSF" turned up this link:
    http://smirnov.org.ru/en/ajax-jsf.html

    Anyone familiar with it?
    Are there any plans within Apache to create AJAX JSF renderkits under the MyFaces/Tomahawk umbrella or something similar?
  9. AJAX Renderer for JSF[ Go to top ]

    one observation with modern browsers is that they already do this dom comparison to some degree-- less the scrollbar issue. So if you flip between pages that are primarily the same, often times, it will look like what AJAX would offer.

    on the otherhand, that's a lot of overhead serverside and client side to handle the unique ajax usecase
  10. AJAX Renderer for JSF[ Go to top ]

    on the otherhand, that's a lot of overhead serverside and client side to handle the unique ajax usecase
    that's the whole point, you should know, you measured it yourself ;-)
  11. If you read documents on webapp-safety one of the first recommendations is to completely ban Javascript from your app. As a supplier of a Javascript-requiring app it might even be possible to get sued for provoking collateral damage by a customer who becomes victim of a cross-scripting attack.

    As another argument against the AJAX/JS-craze, I would say that the dynamic stuff just covers up suboptimal user-interface design. A well designed UI has no need for that "Rich" feeling. But maybe I am a bit radical?
  12. Radical? Sounds more like traditionalism to me...
    (Actually I used to advocate the idea of very restrained use of Javascript in webapps a couple of years ago. But that was then.)
    Now I can clearly see the promise in AJAX. Of course you shouldn't use an AJAX UI if you don't need to. (You shouldn't use anything that isn't needed.) But there are UI:s that are better implemented using AJAX-techniques.
    A strict HTML web is far from optimal when designing most UI:s. The web originally wasn't ment to be an application context. It was ment to be a navigational information space. Far from all applications fit perfectly into that description.
    Things change and now most of us can see great use in web applications. I believe AJAX will evolve into something most of us will have a hard time rejecting.
  13. The big problem with AJAX for me is that you effectively have to write your application twice. You cannot rely on javascript being available for the correct functioning of a publicly-visible web application. If turning off javascript breaks your app, then your app is shoddy in my view. Aside from all the people that browse at high security, there are accessibility concerns. Try using an AJAX-ian interface with a speech browser...

    The only approach that works for me is technologies like AJAXAnywhere, where you can add AJAX behaviour to an existing application with minimal extra cost - that way you can degrade your behaviour nicely to an interface that works fine without javascript. Its very short-sighted to simply code an AJAX interface and leave it at that. Of course, this does depend on the app. If its an internal application with a minimal, homogeneous audience then knock yourself out.
  14. If turning off javascript breaks your app...

    didn't that go away last century? when javascript itself would cause the browser to crash. it still can cause that to occur, but it is fairly uncommon. people don't really go around turning off javascript on thier browser do they? i'd gather their numbers are less than the number of mac users out there.
  15. What about use of AJAX / JSF for web applications in GOVT that have implmented laws like American Accessibility Act or Ontario Disability Act, which requires no javascripting in web applications, it's not just a security issue.
  16. Well not only an American issue (the accessibility constraints). This is true for other countries as well.

    About the security aspect: have you seen this TSS-info: http://www.theserverside.com/news/thread.tss?thread_id=37201
    (Sort of came at the right moment...)
  17. If turning off javascript breaks your app...
    didn't that go away last century? when javascript itself would cause the browser to crash. it still can cause that to occur, but it is fairly uncommon. people don't really go around turning off javascript on thier browser do they? i'd gather their numbers are less than the number of mac users out there.

    Then you would be completely wrong, and making shortsighted assumptions based on your own behaviour. Now more than ever users are aware of security risks and vulnerabilities in browsers and I regularily encounter a diverse range of people who disable javascript. I myself only enable it for trusted sites.

    You are also missing my point about accessibility of public websites. Conforming to the legal guidelines for specific levels of accessibility pretty much ensures that your public facing application cannot rely on the availability of javascript.
  18. My original premise for this idea is for web-based applications, specifically business focused intranet (but not ruling out other) applications, not web sites. However as I did not detail this out, so I can understand your confusion for legal guidelines on accessible websites.
    However this does not mean that an AJAX based weblication cannot be written to any less accessible than a standard desktop based application, we just don't have the standards in place for them yet (and generally speaking different application vendors follow different UI & accessibility standards IMHO).
  19. My original premise for this idea is for web-based applications, specifically business focused intranet (but not ruling out other) applications, not web sites. However as I did not detail this out, so I can understand your confusion for legal guidelines on accessible websites.However this does not mean that an AJAX based weblication cannot be written to any less accessible than a standard desktop based application, we just don't have the standards in place for them yet (and generally speaking different application vendors follow different UI & accessibility standards IMHO).

    I understand that there is a difference between a public facing website and internal web-applications, and made that very distinction with my first post in this thread. I work on both and only deal with accessibility concerns where absolutely necessary. The simple fact is that if you have a web-application that is a candidate for AJAX behaviour, with a diverse, numerous and potentially disabled audience, public-facing or not, you have to take into account graceful degradation of your application's behaviour.

    I also did not say an AJAX application cannot be accessible - my criticism was that it takes more effort to do so. You run the risk of doubling your workload, depending on the approach you take and the libraries you use.
  20. Yes, absolutely, but then this comes down to how the Ajax/JSF components are written and tested to make sure that they degrade in an acceptable manor. This is another reason why I think a AJAX renderer for JSF is a good idea, as the application can then be written to degrade gracefully to suit any needs rather than developed to include some of the current collection of general purpose Ajax utils that generally take the approach of functionality first, everything else second (this does not include commercial products as I can’t comment on not having properly used all of them!).
    All the comments everyone has given me some food for thought on this subject, especially the accessibility comments.

    Thanks everyone,
    Daniel
  21. The big problem with AJAX for me is that you effectively have to write your application twice. You cannot rely on javascript being available for the correct functioning of a publicly-visible web application.

    For jsf, or any other component based FW, that is not true. You either render your component or the whole thing. This is not theory, i have got it working like this. if (!ajax for any reason){ application.render} else {component.render}. This condition occurs only once in my codebase, not on every action.
  22. Supporting with and w/o JS[ Go to top ]

    I don't think its realistic to blanketly require a web application to need to support both JavaScript and non-JavsScript. It depends on your audience.

    We have a very limited audience of 10'000s of users. We are requiring them to use JavaScritp. We are not using JavaScript to enforce security or anything like that. We're using sound web security principles. However, the using JavaScript (either plain DHTML or AJAX) enhances the user experience. And requiring it means we DON'T have to support two different mechanism, so we don't extend the project timeline.

    Does anyone know if Google Maps works without JavaScript? I don't, because I leave JavaScript on 100% of the time because the sites I visit use it to help me, not harm me. And, barring bugs, the browsers are built to protect me from malicious JavaScript coders. Sure, there could be a bubg, and I could be infected, but I haven't been yet. I could also die in a car crash, but it doesn't stop me from driving. Frankly, if you don't want to risk being infected, unplug your network, diconnect your USB flashdrive, CD-ROMs and floppy-drives... heck, even unplug your computer.
  23. Supporting with and w/o JS[ Go to top ]

    I really think it depends very much on your usecase.
    If you have e.g. a fancy product presentation of the latest Ferrari it's perfectly Ok to rely on Javscript, DHTML, Ajax, Flash etc.
    But if you have an E-Commerce application and really make your money with the website and only because of compatibility issues or switched off javascript you loose like 5% of your customers you did a terrible bad job as system architect.

    But I guess if you use JEE technologies it's more likely that you build an E-Commerce application than a presentation.

    One other thing is really the compatibility, I didn't test AJAX for all browsers, but when doing client side JS validation, I really ran in the case that for some browsers (e.g. Opera) the validation did not work at all, so no submits could be done.
    Even if you test if with every browser and make your site working without JS, you still run into the problem that you have to do regularly update your site for new browsers.
    So when you use firefox now, all the sites, which are not working correctly use JS!

    So my experience, at least for E-Commernce applications:
    NO Javascript!
  24. My original question was not "should JEE applications use JavaScript" as we can see there are both pros and cons to this argument (and this argument has been going on over web applications for as long as JavaScript has been around). It was however more along the lines of "should JEE application developers have a AJAX/JSF component toolkit available to them?" As Kito pointed out in the first post, there are already a couple of commercial kits available, which means that they can see a market for this type of product.
    As I would like to create an open source project to create an AJAX/JSF rendering toolkit & components for the whole community to use, comments relating to security, supporting browsers that do not have JavaScript enabled and other potential issues and questions relating to “is this is such a good idea outside of a controlled environment” have been very constructive. Therefore could we please stop the yes/no argument about the relevance of JavaScript in web applications, after all no one is forcing you to use it, its just another tool in the toolset of application building, its not always necessary to have to use it, as is AJAX or anything else, it all comes down to the problem trying to be solved and the business requirement behind it.
  25. BindowsFaces[ Go to top ]

    Please take a look at BindowsFaces it supports accessibility!!!!
  26. Agree to disagree[ Go to top ]

    Javascript is here to stay. It's true about cross-scripting but(!) that's a web server issue and most of the companies that are building webservers keep a close eye on security advisories.

    RIA is a concept that you'll hear it often in 2006 and is nothing wrong to have AJAX help improve the user experience on your site, on top of that you save more on response time/bandwidth.

    Have a look to http://ajaxanywhere.sourceforge.org, it has a fail-over mechanism if properly use so if one turns JS off site is still working - "old style"...

    Regards,
    C
  27. ICEfaces[ Go to top ]

    Thanks to Kito for mentioning our product. I'll try refrain from too much marketing. ;-)

    We are currently developing ICEfaces because we believe that rich-client/web applications are here to stay and will only become a more popular choice in the new few years. Unless you are going to rely on proprietary solutions or wait for Microsoft's future offerings, judicious use of AJAX seems to be a no-brainer.

    For us Java types, JSF may or may not be the best solution for a UI technology but it will be included in J2EE 5 and is being supported by several tool vendors. It's likely to see a fair amount of use just for those reasons.

    In trying to combine JSF with AJAX, we saw minimizing JavaScript development as a good thing - both for ourselves and for the developers using our framework. We've tried to design AJAX into the framework (rather than the components) as much as possible.

    As for an open-source strategy, that is currently under discussion within our company. We want to find a balance that makes sense for customers that still allows us to have a viable business. The current release (Alpha) is available free for use and deployment if it meets your current needs. Source code is only available for a few select components. Of course we'd like to hear what kind of open-source strategy you'd like to see (other than completely free).

    Deryk Sinotte
    Senior Developer
    ICEsoft Technologies
  28. AJAX Renderer for JSF[ Go to top ]

    At the last NoFluffJustStuff symposium Ted Neward hosted session on “The Fallacies of Enterprise Computing”. There are those 10 fallacies:
    1) The network is reliable
    2) Latency is zero
    3) Bandwidth is infinite
    4) The network is secure
    5) Topology doesn't change
    6) There is one administrator
    7) Transport cost is zero
    8) The network is homogeneous
    9) The system is monolithic
    10) The system is finished

    Lets look at the Ajax with the fallacies in mind and lets consider items #1,2,3,4,and 7. Hmmm
    Any comments ?
  29. NoFluffJustStuff[ Go to top ]

    Ted Neward is right to point these out; as a failure in any of them can cause a systems outage if the application is not built to handle them (as much as a networked application can if the network fails). However this does not change how people are looking at networked software development, you only have to look at web services to realize this.
    Any application that runs over a network, AJAX, SOA & web services (insert your favorite acronym here) needs to handle failures in an acceptable way otherwise the system is perceived to be broken rightly or wrongly so.
  30. NoFluffJustStuff[ Go to top ]

    Aren't these Peter Deutsch's Fallacies?
  31. NoFluffJustStuff[ Go to top ]

    I believe that 8 are Peter's and Ted added 2 more.

    That does not make them less relevant:)

    And thanks for the proper attribution, lets give credit when due.
  32. AJAX Renderer for JSF[ Go to top ]

    I am looking for comments on the usefulness of an AJAX rendering kit for JSF. I have used JSF and XMLHttpRequest in a couple of applications using both customized code and tools such as DWR and AJAXAnywhere. Has anyone thought of porting AJAX technology into JSF? I am current thinking about following the guidance offered by this article on how to create a custom JSF render so that JSF renders code directly in the web browser. Browser compatibility issues aside, what problems do you foresee? What custom components do you think people would use?

    This is a great thread. I have a client who is interested in Ajax/JSF combination. Thanks again.

    Kito: good comments! Thnx.
  33. The AJAX hypo is far reached[ Go to top ]

    Please read,

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ie_leak_patterns.asp
    http://codeproject.com/useritems/LeakPatterns.asp

    JavaScript implementations have serious memory leaks.