|
Sponsored Links
Resources
Enterprise Java
Research Library
Get Java white papers, product information, case studies and webcasts
|
News
News
News
|
Messages: 104
Messages: 104
Messages: 104
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
James Strachan: Is Ajax gonna kill the web frameworks?
In "Is Ajax gonna kill the web frameworks?," James Strachan asks "...if the world really does go Ajax or some kinda client technology very Ajax like - will that cause these traditional HTML/HTTP web frameworks to become legacy?"
So is the web application of the future going to be static HTML & JavaScript, served up by Apache with Ajax interacting with a bunch of XML based web services (maybe using SOAP, maybe just REST etc)? If so, do we really need a web framework thats focussed on HTTP and HTML, or are we just gonna end up developing a bunch of XML based web services and letting Ajax do all the templating, editing and viewing?
Is this the end of web frameworks as we know it?
|
|
|
Message #191403
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Is Ajax gonna kill the web frameworks?
I don't know how it will be in future but now Component based web frameworks (JSF, Tapestry, Wicket)and AjaxApps can really benefit of integration between them.
While model2 frameworks is surely a history.
|
|
|
Message #191404
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Sure!
...And also it will be the beginning of next generation, AJAX-centric web frameworks.
I'm pretty sure that almost everyone now trying to develop such a framework.
|
|
|
Message #191405
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
While everyone is so distracted trying to make their AJAX blog editors behave more like MS Word, some of us have realized that and HTTP/HTML-based UI just won't cut it. So go ahead, kill the current web frameworks, a little bit of AJAX would a nice addition. But when someone is looking for a client application that can recieve and respond to remote events (re: not poll the server for changes) I'll be using Swing or SWT.
Good asynchronous messaging technology won't be available in AJAX for some time to come. Keep in mind AJAX is asyn only 1 way.
|
|
|
Message #191407
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
I agree that real windowing GUI (not a layer over HTML/DHTML/JS) is the only way to build real rich and responsive GUI.
But I think that there will be also place for HTML/DHTML/JS in web apps such as on-line shopping, forums, bloggers, etc..).
But for internal business apps, HTML/DHTML/JS days are over.
|
|
|
Message #191411
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Client in the hands of the enemy"
I am sure developers do not want to put business state on the client, since that opens the floodgates with lack of security and possibilities of unauthorized use.
So the server is still necessary, and with it the flow control mechanisms that web frameworks provide.
|
|
|
Message #191412
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interim solution...
I'm really intested in AJAX. Doing AJAX by hand is a pain, but when there is framework support life is much better (using AJAX in rails is just SO easy).
I think we'll see AJAX injected into most web frameworks, and looking around you can see that's already happening.
While I think AJAX is great, I do believe that it isn't ideal - it's just an interim solution, a half-way house before we have a better, richer client framework.
(I develop Web Swing Apps for a living :-D)
|
|
|
Message #191413
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares? [Stop the madness!]
While everyone is so distracted trying to make their AJAX blog editors behave more like MS Word, some of us have realized that and HTTP/HTML-based UI just won't cut it. ...
Amen.
For whatever reason, the current fashion seems to be to move everything to "web-app". Sadly, this almost always means using ugly heavyweight frameworks combined with insanely tedious web technologies (ajax is going to be king of that pile).
The reality is that most projects are in-house CRUD apps in small to medium sized organizations. A full web-app is typically NOT necessary when you have total control of the client computers. In these situations, it is cheaper, easier, faster, and more future proof to use a regular application technology-- it really is.
All of this web-app mania is creating a brain drain on regular applications. Project managers now want to go web-app even when that technology is not needed (eg. in-house apps) and everyone feels the need to get experience with the latest web-app cruft whether they need it or not.
The end-result is customers end up paying more because the applications cost more to develop, programmers get bored, sick and tired of dealing with browser compatibility issues (because the w3c has the power of wet-noodle). And, we get a never-ending mind-numbing stream of fat overcomplicated frameworks because no one is happy with existing frameworks.
|
|
|
Message #191415
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan: Is Ajax gonna kill the web frameworks?
It was our (my team's) first reaction to Ajax to say 'wow, we no longer have to use web frameworks like Struts, WebWorks, JSF...'. We have services and a very simple home-grown web framework that handles simple stuff and works as a proxy to the services. That way most of our time goes to service development as oppose to web development. We have a generic way to handle ajax requests on the server. We are not done with our own framework, which is very thin and simple, but aim is to kill the need for web development; just write your services and views; anything in between should be 90% generic, if not 100%.
We went through many ajax frameworks so far. There are many different and some really cool ideas out there. It looks like everyone is very confused about where exactly Ajax should fit. Should it change more your server-side and/or your client side? some people are trying tag stuff while other doing complete client development with JS. There seems to be a lot of confusion and creation happening at the same time, which is very exciting.
To me success of Ajax will be to kill web development pain and the ones cause the pain. I hate developing web apps, I want to develop my services and expose them to the web. Life should be that simple.
Ajax cannot replace web frameworks. We are trying to kill old way of developing web applications with old web frameworks. We will still have web frameworks that are Ajax-aware or Ajax-friendly or completely Ajax-based.
-talip
|
|
|
Message #191418
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
"Client in the hands of the enemy"
I am sure developers do not want to put business state on the client, since that opens the floodgates with lack of security and possibilities of unauthorized use. So the server is still necessary, and with it the flow control mechanisms that web frameworks provide.
Of course something is required on the server side; but it doesn't have to be a web application framework like Struts or JSF - it can be any web service stack you choose.
i.e. the web service framework doesn't need to deal with templating/view technologies like JSP/JSTL, deal with adding statefulness on top of a stateless HTTP protocol and implementing a server side UI model like JSF - it can just be a bunch of simple business level web services that the Ajax library invokes directly.
James
LogicBlaze
|
|
|
Message #191420
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
interim solution...
I'm really intested in AJAX. Doing AJAX by hand is a pain, but when there is framework support life is much better
You can use Ajax components. You have a very rich choice in Java right now.
Marina
http://www.servletsuite.com
|
|
|
Message #191421
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan: Is Ajax gonna kill the web frameworks?
... Ajax ... services ... framework ... services ... service ... ajax ... framework ... services ... ajax frameworks ... Ajax ... Ajax ... services ... Ajax ... frameworks ... frameworks ... frameworks ... Ajax-aware ... Ajax-friendly ... Ajax-based
Oh, my!
|
|
|
Message #191423
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JS is not good development environment
I don't see it happening--Javascript just isn't good for large scale development. Java is way ahead in development tools. Debugging JS running in a browser is terrible.
|
|
|
Message #191425
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
James Strachan: Is Ajax gonna kill the web frameworks?
... Ajax ... services ... framework ... services ... service ... ajax ... framework ... services ... ajax frameworks ... Ajax ... Ajax ... services ... Ajax ... frameworks ... frameworks ... frameworks ... Ajax-aware ... Ajax-friendly ... Ajax-based Oh, my!
Mileta, yeah it is obvious that I cannot be a good writer :) I should at least read before I post but -hoping- to be a good developer.
|
|
|
Message #191426
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
re: Who Cares?
But for internal business apps, HTML/DHTML/JS days are over.
No they aren't! We have an integrated system that has a Swing GUI at HQ and Canadian regional locations, but has a web interface that is deployed globally.
For various reasons, it would take about 18 months to get the Swing client certified to be installed on the desktops of the users at the global locations. By using a web interface with no desktop footprint, no certification is required.
As a result, we're now integrating AJAX functionality to gradually provide a more rich interface that's still based on HTML/DHTML/JS.
Using HTML/AJAX just makes simple business sense in our case, and I'm sure it does in many others.
Dave Rooney
Mayford Technologies
http://www.mayford.ca
|
|
|
Message #191427
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JS is not good development environment
I don't see it happening--Javascript just isn't good for large scale development.Java is way ahead in development tools.
Agreed - but thats not to say that Ajax isn't good for developing a web UI and leaving the large scale development on the server side. Ajax does web pages very nicely and they scale to however many pages you have pretty easily.
Debugging JS running in a browser is terrible.
As Dion mentioned recently at least Ajax based sites are very RAD - just hit reload in the browser to test a change - no need to rebuild the WAR & restart tomcat/jetty each time you want to make a minor change. You can still debug the server side easily if you need to.
James
LogicBlaze
|
|
|
Message #191432
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JS is not good development environment
I don't see it happening--Javascript just isn't good for large scale development.
Agreed. I don't prefer having my developers to write JS code but I am OK with writing a client-side JS library (nothing specific to an application) once and have my developers use it in every app. I see some people suggesting full JS development but I think it is more problem than a solution because of not having a decent development/debugging environment.
Now the question is would I use it if there were a nice IDE for JS. Yes I would to some degree. We are using a JS plug-in for Eclipse (I think it is called JSEclipse) but it is not good enough.
|
|
|
Message #191433
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JS is not good development environment
I don't see it happening--Javascript just isn't good for large scale development.Java is way ahead in development tools. Agreed - but thats not to say that Ajax isn't good for developing a web UI and leaving the large scale development on the server side. Ajax does web pages very nicely and they scale to however many pages you have pretty easily.Debugging JS running in a browser is terrible. As Dion mentioned recently at least Ajax based sites are very RAD - just hit reload in the browser to test a change - no need to rebuild the WAR & restart tomcat/jetty each time you want to make a minor change. You can still debug the server side easily if you need to.JamesLogicBlaze
I would say that this depends on the nature of the change. If I change just JSP pages, I just reload the page. If I need to make changes to the business logic, then sure, I may have to restart the web server. Again, it depends on the change because the Hotswap, while not perfect, does eliminate an entire class of restarts.
|
|
|
Message #191434
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
For me AJAX is irrelevant
Well, for my own cases AJAX is irrelevant because we have very high requirements for web accessibility (WAI), and AJAX pretty much kills all such things. So, no go, no matter what I think about it on a technical level.
I'm also curious how AJAX would fit in with WSRP services. Has anyone tried making a WSRP accessible component that uses AJAX? If that doesn't work, then again, it's irrelevant.
But that's just my own perspective. If you don't care about accessibility, and you don't care about making it work in a bigger picture, then sure, AJAX sounds like lots of fun (apart from the general nightmare that comes with JavaScript+DHTML incompatibilities).
|
|
|
Message #191435
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
While everyone is so distracted trying to make their AJAX blog editors behave more like MS Word, some of us have realized that and HTTP/HTML-based UI just won't cut it.
<snip>when someone is looking for a client application that can recieve and respond to remote events (re: not poll the server for changes) I'll be using Swing or SWT.
+1
There is an upcoming article on TSS on RiA, such as pointcast.com (aka Roomity.com)
.V
|
|
|
Message #191436
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
still no other 'standard' emerging
Personally, I don't like having to code javascript because of the poor tool support when compared to developing in Java. However, I don't think we are going to see anything compete with Ajax in the short to medium term because there is no rich-client standard across java-.net world.
Soon the .net camp with have XAML, and on the java-side we have applets/webstart, but they are both limited by their owners, or more accurately, limited by which camp developers choose.
It makes me wonder, Ajax because popular because of Gmail, period. What if Sun and Google had tied up earlier and Google had chosen applets for the client-side technology? Would people still rubbish applets if the biggest, technologically independent web company had chosen it?
|
|
|
Message #191441
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wha twe really need is ...
What we really need is a browser that always keeps itself synched with the latest version of java.
Then we need the browser to have a java API that gives you access to the dom of the web page (NOT A JAVASCRIPT API...a real JAVA api).
Finally we need a swing PLAF and layour manager that works with HTML.
Then we could write actual java applications on the client, and they wouldn't look like crap.
Why the hell hasn't anyone done this yet??
-geoff
|
|
|
Message #191442
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
still no other 'standard' emerging
It makes me wonder, Ajax became popular because of Gmail, period.
I think most users would prefer good quality desktop client for gmail (which would of course still keep our e-mails on the server), instead of web one (HTML/DHTML/JS/AJAX).
Although web gmail would be usefull when one wants to accees his/her mail from other machine, which is not that often.
The main benefit of Gmail is not that it is AJAX based (sure that helped attract the users), but that you e-mails are accessible from everywhere.
|
|
|
Message #191443
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Thanks, no more JavaScript hell...
I used to use JavaScript few years ago to build 'rich' web applications. Since then I hate JS as nothing else on this World (Ok, I hate CSS even more, but have to use it:)). Browser incompatibilities (even between version of the same browser), no testability, no reliability, different DOM models etc. etc. - to make long story short: NO THANK YOU. No matter how nice AJAX is. If AJAX uses JS I will never use it, unless someone pay me twice for the project :)).
Artur
|
|
|
Message #191445
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
RE: Is Ajax gonna kill the web frameworks?
I don't know how it will be in future but now Component based web frameworks (JSF, Tapestry, Wicket)and AjaxApps can really benefit of integration between them.While model2 frameworks is surely a history.
Uh huh... And when you need to make an AJAX call to the server to update the data in one component, it's going to go through the whole lifecycle of a JSF request?
I tend to think that AJAX makes component based web frameworks less relevant, whereas action-based frameworks are a good fit with AJAX enabled webapps.
|
|
|
Message #191447
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
still no other 'standard' emerging
no doubt, i prefer using desktop apps to web apps, my point is that google really kicked started ajax as an alternative. it would have been great if they had chosen java as their platform,it would add the vendor-independent weight to the technology.
ajax has existed for a while, but google had the power to make it viable.
|
|
|
Message #191449
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
First of all, JSF lifecycle is not such a big overhead, but it provide richness to the component model.
Secondly There is too approached to remove/minimize "such overhead"
1. JSF conponents can export their ajax capabilities as separate of jsf lifecycle services
2. There is work going on implementing "Avatar" approach which provide processing of jsf subtrees. (Currently actively discussed in jsf Facelets community). Experiments shows up to 10X less time is spent in jsf lifecycle in some cases
|
|
|
Message #191459
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Echo a great AJAX Framework
Echo is the best AJAX framework for building "web applications". It is built from the ground up to use AJAX and makes the communication between the browser and webserver has lightweight and efficient as possible.
The framework takes on a lot of burdensome state management for you while allowing you to keep the application as memory lightweight as possible. From a programming perspective it is component based (Components, events, listeners...etc) and makes you almost forget you are programming a web application.
It is open source. You can find it here:
http://nextapp.com/platform/echo2/echo/
-Sam
|
|
|
Message #191464
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
First of all, JSF lifecycle is not such a big overhead, but it provide richness to the component model.Secondly There is too approached to remove/minimize "such overhead"1. JSF conponents can export their ajax capabilities as separate of jsf lifecycle services2. There is work going on implementing "Avatar" approach which provide processing of jsf subtrees. (Currently actively discussed in jsf Facelets community). Experiments shows up to 10X less time is spent in jsf lifecycle in some cases
If the JSF lifecycle is not such a big overhead, how could you get a 10X reduction in processing time by just processing a sub-tree?
In general, JSF's component management is much less relevant when each component can make its own calls back to the server, rather than all of them going through the same JSF page.
|
|
|
Message #191466
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web app frameworks die 500th death!
By my count this marks the 500th time that web frameworks have been killed by a new technology! Congradulations!
Seeing as there are 2000 other web frameworks, each of which is the "Struts-killer", that would make it 2500 for Struts!
Seriously, though... Do you need every CRUD screen to be rendered by Javascript? Does every simple page need web services exposed so your browser can make 3 requests and use XSLT to style them into a web page? I think AJAX is cool technology, and can make that subset of pages in every application that need complicated interaction with the server to update pieces of themselves work much better than full-page refreshes, but it's just an addition to regular web applications, not a replacement. Thinking otherwise is just silly.
Back to building AJAX enabled UI components...
|
|
|
Message #191468
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Using AJAX as a component?
I've seen a lot of components for JSF and .NET for use with AJAX. No doubt, this can save a lot of time, but you are coupling the server-side with the client-side. What happens when your boss decides to shell out tens of thousands of dollars for something like Macromedia Flex and it is your job to implement it?
I've found AJAX to be most useful when you get generic XML back from the server and do stuff with it, instead of tightly coupling it with the server. Then when management decides they need to have the next greatest thing, you only rewrite one layer instead of the whole thing.
If you think this is a far-out scenario - it actually happened on a project I worked on. We started out doing a bunch of stuff in Ajax and ended up moving most of it to Flex. Because the server-side code returned generic XML instead of being tightly coupled with an AJAX component, very little code on the server-side had to be rewritten.
|
|
|
Message #191471
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax not a tool
Bill
For the record, AJAX is an "architecture/technology", not a tool. AJAX has been misstated as a tool several times and that sends a wrong message to developers.
|
|
|
Message #191475
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Asynchronous AJAX
Good asynchronous messaging technology won't be available in AJAX for some time to come. Keep in mind AJAX is asyn only 1 way.
ICEfaces provides asynchronous page updates. The HTTP protocol makes does make asynchrony difficult, but it can be done without polling.
An interesting possibility would be to allow the browser to reverse the client and server roles on an established HTTP connection (but this is certainly not part of the HTTP standard today).
|
|
|
Message #191477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
In general, JSF's component management is much less relevant when each component can make its own calls back to the server, rather than all of them going through the same JSF page.
But does this lead to a set of components on a page that can only update themselves independently? It's important to allow any component on the page to change in response to user input (or asynchronous events).
|
|
|
Message #191479
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Web app frameworks die 500th death!
I think AJAX is cool technology, and can make that subset of pages in every application that need complicated interaction with the server to update pieces of themselves work much better than full-page refreshes, but it's just an addition to regular web applications, not a replacement. Thinking otherwise is just silly. Back to building AJAX enabled UI components...
I agree. I'm still getting the junior members of my team going on Struts and we will have to support our existing Struts applications for years to come. I could not get away with throwing the baby out with the bath water just to be on the next tech wave.
I'm excited about adding AJAX to our team's toolbox and using it where it makes sense. Just like I don't use EJBs in every project, I won't use AJAX for every page of every project--only where it adds value. As staff competency in AJAX grows it may be used more, but I see limited application at first.
Changing technology is not without cost. Not only do I expend hard dollars for training, but there is a drop in overall productivity. In a corporate environment you can’t just switch out staff as technology changes. Some legacy employees don’t adapt to change well. All this has to be taken into consideration no matter how “cool” the new technology is.
Steve Mitchell
ByteworksInc
|
|
|
Message #191481
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
In general, JSF's component management is much less relevant when each component can make its own calls back to the server, rather than all of them going through the same JSF page. But does this lead to a set of components on a page that can only update themselves independently? It's important to allow any component on the page to change in response to user input (or asynchronous events).
In the WebWork AJAX components we've been building (on top of the excellent Dojo framework) we loosely couple these UI components using Dojo's publish and subscribe topics. This lets one component publish a message on a topic and several other components receive the message and can choose what to do, whether it's to refresh themselves from the server, use the contents of the message to do some processing, etc.
|
|
|
Message #191482
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
In the WebWork AJAX components we've been building (on top of the excellent Dojo framework) we loosely couple these UI components using Dojo's publish and subscribe topics. This lets one component publish a message on a topic and several other components receive the message and can choose what to do, whether it's to refresh themselves from the server, use the contents of the message to do some processing, etc.
So the components communicate with each other within the browser and refresh themselves as necessary (the logic for this being in JavaScript)?
The ICEfaces strategy is to maintain the complete page on the server. When any component is updated, it's as a result of a JSF render pass of the page. During that render pass, all components get a chance to update the server-side page and just the updates are sent to the browser.
|
|
|
Message #191483
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
So the components communicate with each other within the browser and refresh themselves as necessary (the logic for this being in JavaScript)?The ICEfaces strategy is to maintain the complete page on the server. When any component is updated, it's as a result of a JSF render pass of the page. During that render pass, all components get a chance to update the server-side page and just the updates are sent to the browser.
Yes, you've got it.
Re-rendering the whole page on the server sounds slow, even if you only send back the updates.
We don't perscribe how the client and server communicate. The server could return the HTML fragment to be put into the page, or it could just be sending back a yes/no message. We do make it easy to have pieces of the page which just hit a URL to get their refreshed content, though.
|
|
|
Message #191485
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Asynchronous AJAX
ICEfaces provides asynchronous page updates.
But is ICEfaces only compatible with the default JSP ViewHandler for JavaServer Faces?
|
|
|
Message #191486
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
But when someone is looking for a client application that can recieve and respond to remote events (re: not poll the server for changes) I'll be using Swing or SWT.
I agree with some people on the list that say AJAX is just the beginning of rich client development for the web. I'm still trying to figure out why people are saying things like "I'll be using Swing and SWT"... Web applications (i.e. browser/client/server model) and Swing/SWT apps, are designed for different things. Yes, I'd hate to see a developer use a browser based Eclipse equivalent, as you need better response time, state can be kept locally, the application does not need to use a common executable base, etc... Many benefits, but when someone starts questioning the decisions of many companies to web enable their apps, I'm at a loss of words. I'm sure a lot of folks here worked for large corporations and know the headaches of desktop management, from pushing patches, software releases, to setting up environments (i.e. registry changes), incompatibilities, etc... It's almost impossible to manage in a company of a few thousand employees and up. Of course that's not the case for a 20 people shop. We will always have it's place and many desktop apps are prime candidate for web enablement, but there are many apps that will stay as a desktop application (until a rich client interface technology, way better than AJAX is developed and becomes mainstream).
Ilya
|
|
|
Message #191489
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Asynchronous AJAX
ICEfaces provides asynchronous page updates.But is ICEfaces only compatible with the default JSP ViewHandler for JavaServer Faces?
ICEfaces uses a custom ViewHandler that allows it to optimize the render pass by rendering only dynamic components (bypassing static text, for instance). If the JSF view turns out to not be an ICEfaces view, though, the ViewHandler will delegate.
Could you describe a scenario where a different ViewHandler should be supported?
|
|
|
Message #191490
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Yes, you've got it.Re-rendering the whole page on the server sounds slow, even if you only send back the updates. We don't perscribe how the client and server communicate. The server could return the HTML fragment to be put into the page, or it could just be sending back a yes/no message. We do make it easy to have pieces of the page which just hit a URL to get their refreshed content, though.
There is a cost to rendering the complete page on the server, but there's also a very strong ease-of-use and correctness aspect to it as well. For instance, the developer shouldn't have to be concerned with which components are affected by a change in the data model, the framework should simply update the view as expected. Otherwise, writing an AJAX application becomes more difficult than writing a conventional web application.
Two approaches that seem interesting for optimizing JSF rendering are as follows:
1. Provide an API that allows the application to render a specific subtree of components
2. Use an event-based model on the server to track which components are affected by change and render just those
Ultimately we probably need both approaches for different applications, but does one stand out as being more appealing in general?
|
|
|
Message #191493
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Experiments shows up to 10X less time is spent in jsf lifecycle in some cases
I'd be interested to know how long this lifecycle takes; is it something that takes so long it is worth optimising?
|
|
|
Message #191494
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Horses for courses
AJAX won't kill the current crop of web frameworks- hopefully, a few good AJAX ones will crop up and add to the variety. Client side Javascript is not the be all and end all to all applications.
There are issues such as security, performance, and transaction management that are important for a lot of business apps that fit very well into the J2EE / server side model. And others that are simpler for which all that is just useless noise that the business case does not value.
Like always, horses for courses. No one solution will fit all problems. No matter how hard "architects" try. Know all the technical options before deciding on a solution, and lets keep as many options as we can around.
|
|
|
Message #191495
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
wha twe really need is ...
What we really need is a browser that always keeps itself synched with the latest version of java.Then we need the browser to have a java API that gives you access to the dom of the web page (NOT A JAVASCRIPT API...a real JAVA api).Finally we need a swing PLAF and layour manager that works with HTML. Then we could write actual java applications on the client, and they wouldn't look like crap.Why the hell hasn't anyone done this yet??-geoff
They have. Its called Java Webstart. Included with every JSE as standard. And you can even write some HTML to automatically download it for your client through the browser, if they don;t have a compatable JVM.
Webstart works really well for downloadable rich clients where HTML/javascript is just not good enough.
|
|
|
Message #191496
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Jason, Ted's right on this one. The 'overhead/capabilities' of JSF's component model becomes much more appealing when deployed with the specific purpose of AJAX. The agnostic lifecycle of true component trees in JSF and state management facilities makes the visual studio for the web a common place.
It's my opinion that while JSF greatly eases development via components, it's not applicable for everyone (as in a case I'm working on now where I'm using WebWork), but if you are able to commit to AJAX-like deployments, then JSF's ability to manage state with plugable components is quite cool and practical.
|
|
|
Message #191503
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Degradability. Accessibility.
I don't think that we will often have a pure Web services architecture on the server, and having the client handle the M, V, and C themselves.
For one, we may to worry about degradability. If we truly make the browser into a full force client tool, then we have lost this. There are a suite of apps that this can be ok (corporate IT intranet where you can mandate things).
Also, we need to be really careful wrt Accessibility, and making sure that we don't leave people behind. The art of having Ajax rich apps for the masses, but usable sites for the rest can be key.
Part of the decision is choosing between a dynamic web page, and a web application.
Cheers,
Dion Almaer
Founder, Ajaxian.com
http://ajaxian.com
Cleaning up the web with Ajax
|
|
|
Message #191504
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Applets will make a comeback
Personally I think applets will have a comeback or a birth at any rate. Ajax is a an interim solution and a messy one at that. Google are not going to take over the world using AJAX. If they are going to make the desktop irrelevant, they're going to need a hell of a lot more than javascript to do it and I think they're smart enough to realise this.
The biggest problem behind the proliferation of the applet is getting an up to date JRE on the local machine. With the momentum that google has at the moment when they choose to release an applet enabled web application the hordes will follow and so will the developers.
|
|
|
Message #191505
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
"in some cases" means that there are really large tree of jsf components in the view so proccessing subtees takes much less time, but in average jsf lifecycle is not even noticeble (for example nor [Tapestry or Wicket] performance is really significantly differs from jsf implementations).
|
|
|
Message #191507
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Jason, Ted's right on this one. The 'overhead/capabilities' of JSF's component model becomes much more appealing when deployed with the specific purpose of AJAX. The agnostic lifecycle of true component trees in JSF and state management facilities makes the visual studio for the web a common place.It's my opinion that while JSF greatly eases development via components, it's not applicable for everyone (as in a case I'm working on now where I'm using WebWork), but if you are able to commit to AJAX-like deployments, then JSF's ability to manage state with plugable components is quite cool and practical.
We'll have to agree to disagree. I like to keep my session state at a higher level of granularity, closer to the business usecase being implemented than to the UI widget level. Plus, the time to render the whole component model out and do all the work that JSF perscribes is just going to make your async JS on the client side seem sluggish instead of transparent, which is what we're shooting for.
WebWork lets us customize the execution of an action such that we can make the set of interceptors and functionality which is executed as minimal as possible for async operations, keeping the request turn around time as fast as possible.
|
|
|
Message #191508
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Plus, the time to render the whole component model out and do all the work that JSF perscribes is just going to make your async JS on the client side seem sluggish instead of transparent, which is what we're shooting for.
Is there really any evidence that 'all the work that JSF prescribes' is going to give a sluggish impression? I suspect that compared to the performance of interpreted JavaScript client side, and the business logic required by any framework, which includes data retrieval, it is going to be of no significance at all. However, I am prepared to be proved wrong by evidence.
|
|
|
Message #191509
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
Plus, the time to render the whole component model out and do all the work that JSF perscribes is just going to make your async JS on the client side seem sluggish instead of transparent, which is what we're shooting for. Is there really any evidence that 'all the work that JSF prescribes' is going to give a sluggish impression? I suspect that compared to the performance of interpreted JavaScript client side, and the business logic required by any framework, which includes data retrieval, it is going to be of no significance at all. However, I am prepared to be proved wrong by evidence.
I don't have the resources to do any performance testing, but look at the workflow diagram for the steps that a JSF implementation has to go through to render a page. Common sense says all of that (and saving all of that session state for the component trees) can't help but have an impact, especially as your userbase scales up.
|
|
|
Message #191516
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
I don't have the resources to do any performance testing, but look at the workflow diagram for the steps that a JSF implementation has to go through to render a page. Common sense says all of that (and saving all of that session state for the component trees) can't help but have an impact, especially as your userbase scales up.
There was an presentation at J1 last year that talked about MVC bottlenecks, you can probably find it online, but between Struts and MyFaces/JSF, there was about a 4-5% throughput difference. Nothing overly dramatic. They concluded that a majority of the processing time was done by accessing resources/db-calls outside of java code and the differences between MVC frameworks were a lot less than they had hoped. This was with JSF 1.1, we've made some improvements since, but in the scope of network executions, db calls, etc, how the request is interpreted is a small fraction of the total processing time.
|
|
|
Message #191517
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
JavaWebStart - available for many years already: http://java.sun.com/products/javawebstart/
True, but for some reason never went mainstream. I don't know much about it (details), though understand the concept. It's great, but again there were many great things that either came to the market too early or too late, and though never capitalized on opportunity. I think web start came too early, since back then, Swing apps weren't as prevelant as they are now and no popular desktop application was written in Java. Now of course that is quickly changing, thanks to many Swing advances and SWT, but I don't know if web start would get another chance, since by now people view it as some years old technology that never made it. It's crazy how the market works at time.
Ilya
|
|
|
Message #191519
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re. Is Ajax gonna kill the web frameworks?
I think so, all the current web framework has a distance between really object world, and it looks that AJAX will solve the problem.
recently, i have planned a opensource project named easyajax(http://easyajax.sourceforge.net) based on my experience. easyajax has something like the JST(javascript template) but provide something more such as Component based framework, Data Binding, RPC etc. and I hope the framewok will looks like a sharp tool to speed the WEB development, seperate the presentation and logic more clearly, mostly, make WEB code more readable and maintaincable.
|
|
|
Message #191524
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
In general, JSF's component management is much less relevant when each component can make its own calls back to the server, rather than all of them going through the same JSF page.
yes, exactly! It should be up to developer how to use that component – through some framework (e.g. JSF) or ask server-side stuff directly. So framework (management) is less relevant than the components (in my opinion of course).
Marina
http://www.servletsuite.com
|
|
|
Message #191526
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares? [Stop the madness!]
For whatever reason, the current fashion seems to be to move everything to "web-app". Sadly, this almost always means using ugly heavyweight frameworks combined with insanely tedious web technologies (ajax is going to be king of that pile).The reality is that most projects are in-house CRUD apps in small to medium sized organizations. A full web-app is typically NOT necessary when you have total control of the client computers. In these situations, it is cheaper, easier, faster, and more future proof to use a regular application technology-- it really is.
I do not agree with you. A home grown application is no more future proof than a webapplication is, I even dare to say that a webapplication is better prepared for the future than a regular one.
Furthermore, with the coming of lightwieght frameworks like ruby on rails is very easy to build a crud like application, way faster than in delphi for example.
Cheaper?? do you know what a delphi enterprise edition costs... infinitly more than ruby on rails, eclipse, hibernate etc.. since they are free.
Furthermore. maintainability is way better for webbased apps than regular ones.
Only when you really, REALLY need rich client stuff, then consider the "regular" approach. But it will cost you atleast the same amount of money effort etc.. but mostly more.
|
|
|
Message #191529
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Degradability. Accessibility.
Yep. I'm just about to start a major project that goes back and re-implements to whole damned site to make it accessible to disabled users.
There are a lot of disabled people out there whose main window on the world is the web. Ajax/Javascript gives pretty, nice to use interfaces for those of us with eyesight and the ability to control a mouse, but it nearly always shuts these others out.
|
|
|
Message #191530
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: JS is not good development environment
Debugging JS running in a browser is terrible.
Its a strange thing, but with nearly every company I go into to do web work, one of the first things I have to do is point out that you don't have to debug javascript by putting in an alert box and hitting reload. There are real debuggers out there guys. You know, ones that let you set breakpoints, look at variables, that sort of thing.
The free MS one is a bit of a pain because it make you go through a few pops up on every startup. The Mozilla one can be a bit sluggish. But I wouldn't say either was terrible.
|
|
|
Message #191531
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The framework will never be the same
The consequences might go two directions, IMO. One, as some suggested, is to bring a strong client that acts as a conductor to orchestrate available Web/RSS services.
The other is a bit ironic: bring back the event-driven model we used for years in desktop applications. In this model, application developers know nothing about Ajax or JavaScript. They just represent Web applications in ready-to-use components and manipulate them when user triggers some events. All are done at the server. Synchronization and communication between browsers and servers shall be done by the server; totally transparent to developers. Remember why VB/Delphi is so popular?
That is the reason we found the ZK project. ZK is an event-driven, XUL-based, AJAX-embedded, all Java framework to enable rich user interfaces for Web applications. If you are interested, you might take a look at SourceForge and Live Demo.
|
|
|
Message #191532
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
For me AJAX is irrelevant
we have very high requirements for web accessibility (WAI), and AJAX pretty much kills all such things.
I have thought & thought about this and I still can't see why this would necessarily be the case. I'm not trying to rubbish your argument or anything, and it's probably just my (mis)understanding, but if you restrict your use of AJAX to accessing backend content and manipulating the content (not the presentation) in the UI (and your users are able to generate UI events easily of course) then I don't see why AJAX can't be just as useful in a WAI-oriented site as any other.
Feel free to correct me.
Kit
|
|
|
Message #191537
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
I don't have the resources to do any performance testing, but look at the workflow diagram for the steps that a JSF implementation has to go through to render a page. Common sense says all of that (and saving all of that session state for the component trees) can't help but have an impact, especially as your userbase scales up.
I don't agree. If Java were still a slow interpreted language I think you would have a point, but we are dealing with code running at C++ speed. Considering all the other layers of code and operation that a request has to go through to process information (especially if this involves network access to another server and database access), I think the time is going to be negligible.
I don't think it is worth putting effort into optimising systems like JSF, no matter how complex they look, unless there is evidence that performance is an issue. Common sense is often not a good guide as to where the real performance problems are in complex code.
|
|
|
Message #191539
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
I don't see why AJAX can't be just as useful in a WAI-oriented site as any other.
It is true that accessibility and javascript do not have to be mutually exclusive. There are probably things you can do with javascript that add to the usability of the page for some people, while not hindering others. I know there are visual things you can do that have no effect on blind users. However, I am finding hard to get a handle on what else can safely be done.
If you insert content into a page using Ajax, how do you make a blind reader aware of the change without repeating the whole page to them? What happens if you modify the contents of a drop down? How would a disabled user who cannot use a mouse, use a javascript menu?
One government site suggests using Lynx as it is used by some Braille systems. Lynx doesn't support javascript at all. Do others?
The only thing that I am sure of is that using simple HTML/XHTML will work.
I am happy to take any pointers?
|
|
|
Message #191542
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
If you insert content into a page using Ajax, how do you make a blind reader aware of the change without repeating the whole page to them? What happens if you modify the contents of a drop down? How would a disabled user who cannot use a mouse, use a javascript menu?
Thanks Reg. This makes sense. Presumably, these problems apply equally to standard UIs as well?
I think we need to differentiate between diferent uses of javascript.
- js-based UI features (JS menus, editors, etc)
- js-based server communication (XmlHttpRequest, xml processing etc).
To me, AJAX is only the 2nd and shouldn't interfere with how the content is presented, which I well understand can cause problems.
Regards
Kit
|
|
|
Message #191543
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
Thanks for this information. I really enjoy reading this and IMO, James could be right.
The real problem of web frameworks today (JSF included) is that you always have *half baked solutions*. You have half of your activity on the server side (events handling, etc.) and half of your activity in the client side (HTML development, a bit Java script, etc.). This does not happen in a *real* presentation layer framework like Swing and SWT. You have your presentation logic always on the client side (at Swing and SWT side). So, the sepration between the presentation and business layer is very clear. Just take the word "server-side and client-side presentation layer" in the J2EE term... hmmm... the presentation layer should be always on *one* side and not both sides! Such a solution smells like a "workaround"... This is actually a simple use of separation of concerns and web frameworks *are* a workaround since we have the problem with those web browsers...
AJAX brings us this capability back to the web browser! Write all the presentation logic in our presentation layer => with AJAX framework, only on the client side within the web browser. Remove those server-side presentation layer burdens!
So for me there are only 2 types of presentation layers which will be the best thing:
1. Pure client-side presentation layers: Swing, SWT, pure AJAX, Konfabulator/Widgets, Flash, ...
2. Pure server-side presentation layers: VNC, XWindow, MTSC, ...
and *no* both side presentation layers like JSF, etc.
Cheers,
Lofi.
|
|
|
Message #191544
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
Other possibilities are coming out. For example, Xforms from the W3C. It offers the AJAX functionality in a markup language. Using Xforms retains all the advantages of server-side development, it avoids using scripting and can be complemented by HTML/CSS, SVG or XUL for presentation. It really may be a starting point for a new generation of SMART CLIENTS, not thin clients anymore. There are not many implementations yet but I wonder why the community is not paying more attention to this technology
Rafael Benito
SATEC-DataMovil
|
|
|
Message #191545
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
So for me there are only 2 types of presentation layers which will be the best thing:1. Pure client-side presentation layers: Swing, SWT, pure AJAX, Konfabulator/Widgets, Flash, ...2. Pure server-side presentation layers: VNC, XWindow, MTSC, ...and *no* both side presentation layers like JSF, etc.Cheers,Lofi.
Agreed. Moving all of the presentation layer to the client would massively simplify our lives; it'd be easy to support both pure Ajax and Swing/SWT UIs as well.
As Dion mentioned; the main thing holding this back from trully innovating the Ajax layer (and doing away with server side presentation frameworks) is support for degredation (i.e. supporting browsers with no JavaScript).
Though I wonder how long we have to be hampered by supporting pure HTML with no JavaScript? Its certainly not an issue for intranets where its not hard to dictate a reasonably new FireFox browser for the system.
Is there really a need to support users who insist on disabling JavaScript, given how widespread JavaScript is right now? Or rather how long do we think we'll be hampered by old non-JavaScript enabled web browsers? Forever?
James
LogicBlaze
|
|
|
Message #191547
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
<james>
Is there really a need to support users who insist on disabling JavaScript, given how widespread JavaScript is right now? Or rather how long do we think we'll be hampered by old non-JavaScript enabled web browsers? Forever?
</james>
nowaday is already difficult to find an internet website in which you can turn off your Java script... IMO, no, Java script support is a must for all browsers and they must be compatible.
Very important is indeed support for accessibility. But I don't see this as a problem, since you also have support for accessibility in your "normal", interactive Windows applications since a long long time ago...
What makes me a bit unsure is whether AJAX (incl. JS) will make Portlet and Portal obsolete? Why should one use them anymore?
Cheers,
Lofi.
|
|
|
Message #191548
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
<quote>
What makes me a bit unsure is whether AJAX (incl. JS) will make Portlet and Portal obsolete? Why should one use them anymore?
</quote>
to make my point clearer... Surely it will be always necessary to save your data/profile about what apps you have and you use on the server side (just like operating system user profile). But who cares about those portlets? It is just enough to have "icons" instead of "portlets". You click on it, and you start your application just like your desktop today... very simple and easy! This would be the end of portlets history... ;-)
Cheers,
Lofi.
|
|
|
Message #191550
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Same old, Same old...
We've gone through all this before, circa 1998, when there were a plethora of books and articles claiming that cross-browser JavaScript could bring the browser to the level of the rich client in functionality. I even got caught and created a web app which mirrors in nearly every respect what AJAX does today, minus the XML part.
The main issue with AJAX right now is that it once again pushes the boundaries of what the browser was intended to do. Fine. But we'll soon find out that most companies don't have the cash or the talent to produce GMails and GoogleMaps. Both these apps took a HUGE number of man-hours to create (and debug).
AJAX is likely to become just another iteration of standard web apps, adding richer components to standard web pages, rather than radically changing the paradigm of near-stateless web apps we have today. That's its strength, and that's where it's going to stabilize. We'll see more GoogleMaps in the mean time, but businesses will come to the conclusion that the results are not worth the difficulties involved.
So what I see is a gradual enrichment of web components, supported by traditional and component-based frameworks, reaching stability in some sort of hybrid. We can already see that in frameworks such as Rails and Echo2 (as well as many others). The request/response nature of HTTP is simply not that easy to escape, whatever client technology is used.
|
|
|
Message #191552
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Who Cares?
Good 2 way asynchronous messaging for Ajax has been available for quite some timehttp://activemq.org/AjaxIts recently got much better thanks to Jetty 6.x and ActiveMQ 4.x
But James, this still requires the client to poll the server. AJAX, in it's current form, cannot enable a clienmt application recieve events that are pushed onto it. This is a limitation of the HTTP protocol itself. An AJAX application can't listen directly to a queue or topic on some messaging system directly. It must poll that messaging system via an HTTP sever which can connect to the messaging system. With technologies like Swing or .NET, you can listen directly to the queue. Additionally, I have implement a stateful 2 way connection an have the server push data to the client as needed. ANd the client DOES NOT need to be polling the server. That was my point: no need to poll.
Ryan-
|
|
|
Message #191553
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
I will miss the controller.
One of the selling points of the MVC frameworks was the C -> the central point of control of page flow through a navigation map. I don't see this in any AJAX frameworks - and I get very lost in all the components on the page making their asynchronous calls. Isnt there a framework that can control all of these connections?
|
|
|
Message #191554
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Same old, Same old... Nope.
<quote>
The request/response nature of HTTP is simply not that easy to escape, whatever client technology is used.
</quote>
Therefore you will just use HTTP for calling your business logic (service layer). HTTP was never meant to be used for your presentation layer. A presentation logic needs those statefull things. Therefore put all your presentation logics back to your client (web browser: AJAX/JS, Swing/SWT). Today web frameworks (JSF, etc.) try to solve this stateless problem with complexity (server-side and client-side presentation layer as I said above).
So, throw away those web frameworks and make the development of presentation layer easier by putting the presentation logic in the correct place.
Cheers,
Lofi.
|
|
|
Message #191557
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
MVC frameworks are here to stay
I don't think MVC frameworks will go away any time soon... The fact is that HTTP is a stateless, one-way protocol, no matter how you try to circumvent this.
Component frameworks try to imitate the desktop application programming model, but IMHO this doesn't work well on the web. The browser already renders all my components, so duplicating component state on the server side doesn't have much value. Look at GMail, for example. If you refresh the page while you are composing a message, you get back to the inbox. People learn quickly not to refresh the page.
What I see in practice is a RESTful API exposed to the AJAX Javascript libraries that poll for information. Implementing RESTful services doesn't lend itself to component based frameworks. On the other hand, MVC frameworks, like WebWork, are a more natural fit.
Look at Flickr.com, for example. Their ajaxified inline editor actually uses the Flickr API to update content.
|
|
|
Message #191560
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Who Cares?
Good 2 way asynchronous messaging for Ajax has been available for quite some timehttp://activemq.org/AjaxIts recently got much better thanks to Jetty 6.x and ActiveMQ 4.x But James, this still requires the client to poll the server. AJAX, in it's current form, cannot enable a clienmt application recieve events that are pushed onto it. This is a limitation of the HTTP protocol itself. An AJAX application can't listen directly to a queue or topic on some messaging system directly. It must poll that messaging system via an HTTP sever which can connect to the messaging system. With technologies like Swing or .NET, you can listen directly to the queue. Additionally, I have implement a stateful 2 way connection an have the server push data to the client as needed. ANd the client DOES NOT need to be polling the server. That was my point: no need to poll.Ryan-
The Ajax client can have a blocking request which can timeout eventually if there are no messages available - or return a message as soon as it becomes available.
So the client side is effectively blocked reading from a socket - which is exactly how JMS clients work too.
i.e. the effect is exactly the same; the Ajax client behaves pretty much like a JMS client, reading messages asynchronously as they arrive from a socket.
The server side (Jetty + ActiveMQ) does a good job of sleeping the servlet until a message becomes available to maximise the use of resources (sockets, buffers, threads etc).
So while in principle on paper Ajax requires polling; in practice with HTTP keep alive and HTTP pipelining, the effect is pretty much exactly the same as using a JMS client.
James
LogicBlaze
|
|
|
Message #191561
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
<quote>What makes me a bit unsure is whether AJAX (incl. JS) will make Portlet and Portal obsolete? Why should one use them anymore?</quote>to make my point clearer... Surely it will be always necessary to save your data/profile about what apps you have and you use on the server side (just like operating system user profile). But who cares about those portlets? It is just enough to have "icons" instead of "portlets". You click on it, and you start your application just like your desktop today... very simple and easy! This would be the end of portlets history... ;-)Cheers,Lofi.
I wonder if anyone's gonna build a pure Ajax based portal capable of aggregating any web content (HTML/XML)?
James
LogicBlaze
|
|
|
Message #191586
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is Ajax gonna kill the web frameworks?
So while in principle on paper Ajax requires polling; in practice with HTTP keep alive and HTTP pipelining, the effect is pretty much exactly the same as using a JMS client.
So back to the original question, how are these factors contributing to the demise of web frameworks? ICEfaces is based on JSF and it uses exactly the blocking technique you describe; but that's only 10k of JavaScript. The framework is still very useful for the developer because sending messages to the browser is probably not the level that they want to work at -- instead they are interested in the business logic and user interface of their application; exactly what the JSF API deals with.
|
|
|
Message #191589
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is Ajax gonna kill the web frameworks?
So while in principle on paper Ajax requires polling; in practice with HTTP keep alive and HTTP pipelining, the effect is pretty much exactly the same as using a JMS client. So back to the original question, how are these factors contributing to the demise of web frameworks? ICEfaces is based on JSF and it uses exactly the blocking technique you describe; but that's only 10k of JavaScript. The framework is still very useful for the developer because sending messages to the browser is probably not the level that they want to work at -- instead they are interested in the business logic and user interface of their application; exactly what the JSF API deals with.
The factors are being able to do all the MVC of a web UI very easily in a small amount of JavaScript on the client. e.g.
http://www.formfaces.com
If the Ajax client can fairly easily implement a powerful UI with little code in a highly asynchronous manner; is there a need for a server side based MVC framework?
Maybe the original blog post might help explain the original point which started this thread.
James
LogicBlaze
|
|
|
Message #191590
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
So for me there are only 2 types of presentation layers which will be the best thing:1. Pure client-side presentation layers: Swing, SWT, pure AJAX, Konfabulator/Widgets, Flash, ...2. Pure server-side presentation layers: VNC, XWindow, MTSC,..
I cannot agree more on your opinions. However, IMHO, the pure client side presentaion layer cannot solve all problems. There are still data accessing and biz logic issues. To make Web application responsive and interactive, developers are usually forced to replicate biz logic in client side(So it is no longer a PURE client-side presentation). And the AJAX's "asynchronization" nature always brings in "synchronization" issue. When an end user click "submit" button, there is no guarantee that an AJAX request of an important text input has already got its response(So developers has to set locks to serialize that; meaning more javascript...and biz logic)
Therefore, I think the best solution should be a pure server-side presentation layer(Frameworks) that would automatically handle all the rich web client issues. There is no need for a web application developer to know anything about Ajax or JavaScript or DOM. All she or he has to do is simply design the page with widgets and components; write codes to manipulate those components and access data and control the biz logic -- all in server side. Just like writing a windows desktop application, a developer has no meaning to have to write a display driver simultaneously. All widgets should be rendered on the screen automatically and correctly.
Based on such ideas, we have founded an open source project ZK. The web application developers design there pages with XUL-like tags(components). Manipulate those components in pure java code. As simple as develop a desktop application. If interested, here is a Live Demo.
Henri
|
|
|
Message #191596
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
JSF can fit too
the time to render the whole component model out and do all the work that JSF perscribes is just going to make your async JS on the client side seem sluggish instead of transparent, which is what we're shooting for. WebWork lets us customize the execution of an action such that we can make the set of interceptors and functionality which is executed as minimal as possible for async operations, keeping the request turn around time as fast as possible.
Why must rendering a JSF component tree be inherently sluggish? The ICEfaces demosare more responsive than typical web applications because less data is transferred over the network. Network latency is certainly a factor, but it will always be a factor when the server has the data. (Of course JSF rendering should be optimized to lower scalability costs, but it doesn't seem to be fundamentally limiting.)
|
|
|
Message #191598
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why AJAX?
Guys, you're stuck in the past. There is always open laszlo if you want a rich client + asynchronous messaging and its as easy as sin (and free). If you want something even more fun and flexible, then go with Macromedia Flex (not free). I've cut dynamic UIs in Flex in a matter of hours that would have taken me many days to implement with JSP.
Why are the RIA frameworks not being talked about anymore anyway? They have all that Ajax has, and more.
|
|
|
Message #191600
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Why AJAX?
Guys, you're stuck in the past. There is always open laszlo if you want a rich client + asynchronous messaging and its as easy as sin (and free). If you want something even more fun and flexible, then go with Macromedia Flex (not free). I've cut dynamic UIs in Flex in a matter of hours that would have taken me many days to implement with JSP.Why are the RIA frameworks not being talked about anymore anyway? They have all that Ajax has, and more.
Macromedia Flex is very good. It looks great, is very powerful, is very quick to develop in, and it has very few cross-browser issues. The only problem is that the price tag puts it out of reach for a lot of projects.
I felt like Laszlo was good too, but it was nowhere near as powerful as Flex.
|
|
|
Message #191605
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Is Ajax gonna kill the web frameworks?
The factors are being able to do all the MVC of a web UI very easily in a small amount of JavaScript on the client. e.g. http://www.formfaces.comIf the Ajax client can fairly easily implement a powerful UI with little code in a highly asynchronous manner; is there a need for a server side based MVC framework?
XForms is very effective for describing the data-entry aspect of the application, but what about the way that the user interface responds to input? This is more difficult to represent declaratively in something like XForms.
|
|
|
Message #191636
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
If you insert content into a page using Ajax, how do you make a blind reader aware of the change without repeating the whole page to them? What happens if you modify the contents of a drop down? These are indeed some of the main reasons why using AJAX for us is a big no-no. For example, one of our most recent government contracts included the "MUST" clause of not depending on JavaScript. In other words, it MUST be possible to turn off JavaScript and have the website function the same. This means that you can only use JavaScript (if at all) to enhance something else; it can never be used to perform something critical. If we had used AJAX to do content-rewriting, for example, we would probably not have gotten the contract (which we did, btw). In Sweden they are extremely picky about WAI right now.
|
|
|
Message #191657
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Ajax - Evolution Vs Intelligent Design
Evolution beats intelligent design here!!!
Though this feels like a monstrocity , the very fact that this has taken ground, proves what a evolutionarily significant step forward HTTP and Browsers are in retrospect.
HTTP to the information world is like life developing something viable in the form of proteins and left handed helical DNA which are set in stone in all species built afterwords. It can spawn such monstrocities which are inefficient, inelegant , have ton of redundancy, but live out by satisfying some of the most important constraints of adoption like "no plugins" pre-requisite which is much more stringent than "work even if Javascript disabled" pre-requisite.
Once these things take ground , why would one need to be intelligent and use Java Webstart or Macromedia where appropriate(20%), when the most prevalent of the applications will be Browser with no pugins as the platform (80%).
|
|
|
Message #191659
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
<quote>
When an end user click "submit" button, there is no guarantee that an AJAX request of an important text input has already got its response(So developers has to set locks to serialize that; meaning more javascript...and biz logic)
</quote>
This is *presentation logic* (working with buttons like turn it on and off, what options and what screens to show, etc.). Business logic is something like "transfering money from one account to another", etc.
<quote>
Therefore, I think the best solution should be a pure server-side presentation layer(Frameworks) that would automatically handle all the rich web client issues. There is no need for a web application developer to know anything about Ajax or JavaScript or DOM. All she or he has to do is simply design the page with widgets and components; write codes to manipulate those components and access data and control the biz logic -- all in server side. Just like writing a windows desktop application, a developer has no meaning to have to write a display driver simultaneously. All widgets should be rendered on the screen automatically and correctly.
</quote>
I think this is already tried by Echo web framework which is similar to Swing API. In Echo you don't see HTML/Java script/AJAX anymore since you work completely independent from HTML/web browsers. Here is the explanation:
http://www.nextapp.com/platform/echo2/echo/doc/tutorial/fundamentals.html
Here is the FAQ:
http://www.nextapp.com/platform/echo2/echo/doc/faq.html
So, Echo is a *purely client-side* web framework (it simulates this behaviour within the web browsers) just like pure Swing/SWT. Echo is indeed the best solution from a *Java developer perspective* since you never need to take care of those HTML/Java Script etc. and you can *reuse* your Swing knowledge. So Echo does not suffer the *half baked solutions* as I mentioned above.
One thing AJAX framework has a plus point against Echo: using AJAX enables you to be open to all *HTML/Java script developers*. So you can let them, who do not know Java at all, to work on the presentation layer independently. You can embrace their knowledge (it is still more HTML/Java script developers available and it is simpler to learn them than Java/Swing API).
See this article for an easy to use DWR AJAX framework:
http://www-128.ibm.com/developerworks/xml/library/j-ajax3/
So if your team has Swing knowledge, reuse them with Echo's way. If your team has HTML/Java script developers reuse them by using pure AJAX... Both are 100% pure client-side web frameworks (yes and not like JSF with JSP/Facelets or what so ever other web frameworks available).
Cheers,
Lofi.
|
|
|
Message #191661
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
The Market drives development
The success of Microsoft is because of its ubiquity which enables it to create standards. This is one reason AJAX is becoming popular.Now that Firefox has 11% of the browser market and MS is down to 85%, it would be difficult for MS to pull the same shenanigans with HTML and Javascript that it did to Netscape. It would break too much compatibility and people would turn to Firefox in droves.
Many business projects could use a client side stack like SWING; and, many do use Microsoft in its many incarnations because of MS's presence and its "ease-of-use" or swing.
But the business requirements drive the frame work. If the business has a portal or makes its intranet accessible through the internet or has an web centric approach to its model (a la eBay) then browser based development makes sense.
In this case it is probably more efficient to keep all development in the domain of the browser.
Costs for total development will most likely be greater if there are two or more develpment approaches- webframework for the outside, and rich-client(swing) for the inside, for instance.
I would be willing to bet that .NET will have a greater absolute number of developers in 5 years than .NET has now and Struts will have less than Stuts has now. Java adherents should keep this in mind.
If SUN could evolve its Java Studio Creator to integrate Swing , Ajax , JMS, Jini, Open Office and J2ME in the same vein of Visual Studio ( I know it can be done now in eclipse, but not out of the box- "some" assembly required)then Microsoft would really have to start running.
I hope Santa's listening or SUN.
|
|
|
Message #191668
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Tired of the Web
I am pretty much tired of trying to understand how particular html/js/etc.-based application is working. Why am I redirected or not to some other page after peforming particular action? Why some fields are disappearing? What happend to the form data I have been so carefully filling out (but it was gone after clicking submit 'cause of timeout)? Why is the menu on top, left, right or bottom(?)? Where is the menu? Why do I need two of those? Heck, why does my right-click does not work?! Every web developer believes to be able to deliver the coolest and most useful UI experience which basically leaves us with huge mess.
As we tend to use more and more applications that have to submit or retrieve data from remote repositories the need for consistent and standard-based UI emerges. The standard has to be open, widely accepted, providing users with customization features, easy to learn from the first experience, cross platform.
http://eclipse.org/rcp - do we need more?
/p
|
|
|
Message #191687
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
AJAX => Put back Presentation Logic to Presentation Layer!
<quote>
So if your team has Swing knowledge, reuse them with Echo's way. If your team has HTML/Java script developers reuse them by using pure AJAX...
</quote>
Developers with strong Swing knowledge, Echo might be the way to go. However, Swing is too complicated for non-programmers or newbie programmers.
Part of the reason that HTML and PHP are getting so popular is easy to get start (though it might get stuck when approaching sophisticated apps).
In additions to event-driven and component-based, ZK adapts the concept of markup languages. It uses XUL. Like using HTML, non-programmers could easily construct a rich user interface intuitively. In the upcoming release, ZK will melt HTML with XUL by separating with the namespace, such that rich user interfaces could be added to existent HTML pages gradually.
Regards,
Tom
|
|
|
Message #191693
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
In Sweden they are extremely picky about WAI right now.
The same is becoming true here in the UK (although most web developers seem unaware of this). Disabled Discrimination Act (DDA) has been adjusted to encompass many types of service. Government organisations and some commercial companies are adjusting (or already have adjusted) their internet content to comply as well.
However, I suspect a great many commercial UK websites are wide of the mark. I wait to see if anyone will be brought to task over it.
|
|
|
Message #191696
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
Presumably, these problems apply equally to standard UIs as well?
They do, but this is not as big an issue as access to services via a public website.
|
|
|
Message #191716
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Who Cares?
Many benefits, but when someone starts questioning the decisions of many companies to web enable their apps, I'm at a loss of words. I'm sure a lot of folks here worked for large corporations and know the headaches of desktop management, from pushing patches, software releases, to setting up environments (i.e. registry changes), incompatibilities, etc... It's almost impossible to manage in a company of a few thousand employees and up.
Yup. Management of desktop deployments is a pain. For some reason, users also seem to prefer webapps, but I've never quite figured that out...
But still, switching from from thick-client applications to browser-based applications just trades in one set of problems for another. I'm sure throwing AJAX into the mix to alleviate some of the problems will just create more.
What we need is something like Java Web Start that works better (or we need JWS to work better), both in terms of reliability and ease-of-use. Then we need Java GUI applications to use about 25% of the memory they use today...
|
|
|
Message #191752
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
In other words, it MUST be possible to turn off JavaScript and have the website function the same. This means that you can only use JavaScript (if at all) to enhance something else; it can never be used to perform something critical. If we had used AJAX to do content-rewriting, for example, we would probably not have gotten the contract (which we did, btw). In Sweden they are extremely picky about WAI right now.
If the complete page is available from the server at any time, would that be sufficient to satisfy the accessibility software and the regulations?
ICEfaces maintains a complete DOM for each page under AJAX control. Naturally everything is dynamically generated, but the complete document is available at any point. This should have a number of advantages for searchability and accessibility.
|
|
|
Message #191818
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
If the complete page is available from the server at any time, would that be sufficient to satisfy the accessibility software and the regulations?ICEfaces maintains a complete DOM for each page under AJAX control. Naturally everything is dynamically generated, but the complete document is available at any point. This should have a number of advantages for searchability and accessibility.
Right, *all* functions must be such that they will work equally well with or without JavaScript. Period. If that can be accomplished by using AJAX techniques that merely "enhance" the experience, it might be ok. And I've been thinking about doing something like that myself. But it is very very tricky to get right.
One thing that complicates the matter is that some functions require additions to the head tag, such as scripts and CSS rules. So, if a function requires both the DOM and head tag to be updated, how would that work in AJAX?
|
|
|
Message #191866
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: For me AJAX is irrelevant
Right, *all* functions must be such that they will work equally well with or without JavaScript. Period. If that can be accomplished by using AJAX techniques that merely "enhance" the experience, it might be ok.
In the case of ICEfaces, the only difference is that the non-AJAX pages cannot be updated asynchronously from the server and they are updated with a full page refresh (not an incremental update).
However, the current implementation does require JavaScript even in this mode. For instance, the JSF commandLink updates a hidden field in the form via JavaScript. commandLink itself could be made to work without JavaScript (with a specially encoded URL) but any other form values in the same form would not be submitted. Would this still be an acceptable degradation for non-JavaScript browsers?
And I've been thinking about doing something like that myself. But it is very very tricky to get right. One thing that complicates the matter is that some functions require additions to the head tag, such as scripts and CSS rules. So, if a function requires both the DOM and head tag to be updated, how would that work in AJAX?
We've seen inconsistent behavior across different browsers with updating the head tag. You may not need to update CSS and scripts. For instance, it should be possible to collect all CSS required for the application and preload it. The ICEfaces approach is to have a single, small, JavaScript library for AJAX-driven DOM updates; all the interesting logic stays on the server, so there is no need to dynamically update any JavaScript.
|
|
|
Message #220807
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: James Strachan: Is Ajax gonna kill the web frameworks?
Yes..The way it is maturing it will definitely spell doom for some web technologies..With the increase in bandwidhth and IDE's like Tibco GI we can build cool AJAX front ends talking to Restful web services and then doing a partial update on the page.
I think the only peice missing is that how to incorporate security and transaction support
Still with things evolving there will be more and more focus on technologies like AJAX.
|
|
|
Message #224908
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: James Strachan: Is Ajax gonna kill the web frameworks?
Absolutely yes. Those frameworks are trying to adapt them to the new scenario, but they are not necessary.
|
|
|
| New content on TheServerSide.comNew content on TheServerSide.comNew content on TheServerSide.com |
|
|
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)
In this session Nati Shalom demonstrates how to take a standard Java EE web application and scale it out or down dynamically without changes to the application code. Seeing as most web applications are over-provisioned to meet infrequent peak loads, this is a dramatic change because it enables growing your application as needed, when needed, without paying for unutilized resources.
(May 19, Tech Talk)
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)
|
|
