|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 32
Messages: 32
Messages: 32
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
AJAX Renderer for JSF
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?
|
|
|
Message #188320
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: AJAX Renderer for JSF
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@virtua.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@jsfcentral.com, and you could get your story published and win a free copy of JavaServer Faces in Action!
|
|
|
Message #188363
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX Renderer for JSF
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?
|
|
|
Message #188370
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX Renderer for JSF
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
|
|
|
Message #188371
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax is Javascript => makes your app UNSAFE
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?
|
|
|
Message #188377
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Javascript a no
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.
|
|
|
Message #188383
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188390
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188398
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: AJAX Renderer for JSF
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.
|
|
|
Message #188408
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
ICEfaces
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
|
|
|
Message #188451
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX Renderer for JSF
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 ?
|
|
|
Message #188511
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX Renderer for JSF
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.
|
|
|
Message #188524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX Renderer for JSF
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 ;-)
|
|
|
Message #188525
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188540
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX: the good and the ugly
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.
|
|
|
Message #188572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
NoFluffJustStuff
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.
|
|
|
Message #188591
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188608
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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).
|
|
|
Message #188614
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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.
|
|
|
Message #188618
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Ajax is Javascript => makes your app UNSAFE
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
|
|
|
Message #188781
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Supporting with and w/o JS
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.
|
|
|
Message #188966
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Security and Ajax
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.
|
|
|
Message #189248
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Supporting with and w/o JS
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!
|
|
|
Message #189415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
To Javascript or not to javascript - is that a question?
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.
|
|
|
Message #192805
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
NoFluffJustStuff
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.
|
|
|
Message #193710
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Agree to disagree
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
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
Reza Rahman continues to explore the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(January 21, Article)
Ted Neward is an independent consultant specializing in high-scale enterprise systems, and an authority in Java and .NET technologies. He is the author and co-author of several books, including Effective Enterprise Java. At TheServerSide Java Symposium in March, he will be presenting sessions on pragmatic architecture, ECMAScript and Scala.
(January 15, Article)
Now that Oracle is absorbing Sun Microsystems, there mixed views on what should come of the Java Community Process (JCP). While some say Oracle should become the new steward of Java and keep the JCP much as it was, others argue that it may be time to open-source this widespread language.
(November 24, Article)
Reza Rahman explores the features of the proposed JSR 299, Contexts and Dependency Injection for Java EE (CDI). When approved, it promises to be a key feature of Java EE 6.
(November 2, Article)
SAML is an XML-based standard for exchanging authentication and authorization data between security domains. The single most important problem that SAML was created to solve is the Web browser Single Sign-On problem. Many organizations are debating whether to stay with version 1.1 or move to 2.0. This article makes observations about both options.
(September 28, Article)
Joe Ottinger takes a look at how people learn, and applies it to the practice of programming. He notes that understanding how people learn is an essential part of working in a programming team.
(September 22, Article)
Stephen Maryka gave us an article about the Asynchronous Web and posed a number of questions that get examined like an approach to delivering Asynchronous Web capabilities through extensions to existing Java EE technologies.
(July 14, Article)
JavaServer Faces Flex goal is to provide users capability in creating standard Flex components, part of flexSDK which is open sourced through MPL license, as normal JSF components. This article by Ji Hoon Kim will provide an overview of creating a simple multilingual JSF page consisting of JSF Flex tags.
(June 29, Article)
In this session Jeff explores the key characteristics of successful SOA projects. He covers some of the patterns, and anti-patterns, tool sets, and strategies that he himself learned the hard way. Last, he provides a strategy and blueprint for achieving a high likelihood of success in your SOA project.
(June 23, Tech Talk)
Ari Zilka, CTO of Terracotta, Inc., talks about the new features in Terracotta 3.1, announced during JavaOne and available now.
(June 15, Tech Talk)
In this Tech Talk, Josh Long explores an integration challenge using Spring Integration and walks through the implementation, employing and expanding on the basic patterns of Enterprise Application Integration to tie together components into a function integration solution, and then demonstrates how Spring Integration helps address the integration requirements.
(June 15, Tech Talk)
In this Tech Talk, David Geary teaches you: The basics of Google Web Toolkit; How to implement Ajax-enabled applications in Java; Internationalization; Hooking into the browser history mechanism; Remote procedure calls.
(June 4, Tech Talk)
Jon Kern discusses the best architecture/technical solutions and ensure that they are repeated by all developers. By tackling the architecture up-front in a serial manner, subsequent parallel development will be much more manageable and predictable.
(May 28, Tech Talk)
This keynote describes the frustrations of modern knowledge workers in their quest to actually get some work done, and solutions for how to guard yourself against all those distractions. Neal Ford talks about environments, coding, acceleration, automation, and avoiding repetition as ways to defeat the misguided attempts to sap your ability to produce good work.
(May 26, Tech Talk)
Gil demonstrates how new, aggressive uses of already abundant compute capacity by common applications offer competitive value for application designers.
(May 21, Tech Talk)
Chris Keene introduces WaveMaker as a new way to automate the ability to generate Hibernate classes in order to more quickly bring OR mapping into an application.
(May 19, Article)
Mastering EJB was one of the original and most influential EJB books in the industry. Mastering EJB III now returns with two new expert co-authors, updated for EJB 2.1 and 30% new chapters including security, integration, best practices, open source, and more.
(Book PDF Download)
The Application Server Matrix is a detailed listing of J2EE vendors and their application server products, with information on latest version numbers, J2EE spec support and licensing, pricing, platform support, and links to product downloads and reviews.
(Application Server Comparison Matrix)
|
|
