Backbase has announced the release of BackBase AJAX Java Edition 1.1. BackBase AJAX Java Edition extends JSF by including an AJAX engine on the client side as well as out-of-the-box AJAX-enabled UI widgets for JSF 1.2. The widgets include various client-side only objects such as menubars, trees, detailviewers, pager, SVG charts, and more (and can be viewed online ). It also provides capabilities for bookmarking pages constructed as a "single-page interface." On the server-side, BackBase provides transparent execution of server-side event handlers from client-side code (a facility JSF provides as well through PhaseListeners, although BackBase' mechanism may be cleaner.) It also is able to automatically synchronize client state on the server. The development environment is integrated with Eclipse, providing full deployment, testing, and debugging capabilities. The Backbase Java Edition pricing starts at $5000 per CPU (Basic License) or $7000 per CPU (Basic License + 2 Year Upgrades). Developer copies are free.

I just have to wonder how quickly these boxes will be flying off the shelf at those prices? Sure the developer copies are free, but from the questions we asked, even the integration and QA servers are charged licenses. They're very nice components, but too rich for our blood. I wonder how many others will choke on that price?

Ya especially given that we have the free open source ZK around

It depends on the quality and usability of the components. If I can buy a library that saves my team 200 or more development hours for less than the $20k+ I'd otherwise have to pay, then it not only saves budget money but also shortens our delivery cycle time.

It depends on the quality and usability of the components. If I can buy a library that saves my team 200 or more development hours for less than the $20k+ I'd otherwise have to pay, then it not only saves budget money but also shortens our delivery cycle time.

For what i have seen of it and know where it will go to, the treshold will be reached sooner then one might think. This stuff rocks. The level of abstraction is very high and therefore creates space in ones brain that would otherwise be occupied with low level details.

For what i have seen of it and know where it will go to, the treshold will be reached sooner then one might think. This stuff rocks. The level of abstraction is very high and therefore creates space in ones brain that would otherwise be occupied with low level details.

This really is true. What they have written here is absolutely huge and very well done. It's a bit pricey but I think thats just the sticker-shock still talking. I think if you sit down and see what this buys you, it may be worth it. It says it works with JSF 1.2. Has anyone been able to get a fully functional copy of JSF 1.2 ? And get it working on something other than GlassFish (preferrably Jboss?)

Google just released their AJAX stuff: http://code.google.com/webtoolkit/

Google just released their AJAX stuff:

http://code.google.com/webtoolkit/

oh my, here we go. This will hurt a lot of companies. There strength is hard to overcome.

Google just released their AJAX stuff:

http://code.google.com/webtoolkit/

oh my, here we go. This will hurt a lot of companies. There strength is hard to overcome.

oops "their strength"

oh my, here we go. This will hurt a lot of companies. There strength is hard to overcome.

Google's stuff looks promising. Its written with Java in mind and they provide some nice help in getting setup in Eclipse. Nice job Google.

Between jMaki and Google's stuff, the client-side flare is cool, but the server integration is horrible. Writing async methods and DTO contracts only to marshall stuff across the network-- welcome to 1999. We have some ideas on how to get true mediator architectures into JSF such that the end developer doesn't need to code anything for AJAX. jMaki and Google's widgets could then use JSF as a mediator instead of forcing lots of specialized code on the part of the end developer.

Between jMaki and Google's stuff, the client-side flare is cool, but the server integration is horrible. Writing async methods and DTO contracts only to marshall stuff across the network-- welcome to 1999. We have some ideas on how to get true mediator architectures into JSF such that the end developer doesn't need to code anything for AJAX. jMaki and Google's widgets could then use JSF as a mediator instead of forcing lots of specialized code on the part of the end developer.

i didn't take the effort to look at it in depth, my assumptions where based on the picture i have in my mind of google. I think they are pretty innovative, escpecially on the user experience side. On the other hand they probably have enough resources to work with tedious frameworks. Anyway time will tell.

Between jMaki and Google's stuff, the client-side flare is cool, but the server integration is horrible. Writing async methods and DTO contracts only to marshall stuff across the network-- welcome to 1999. We have some ideas on how to get true mediator architectures into JSF such that the end developer doesn't need to code anything for AJAX. jMaki and Google's widgets could then use JSF as a mediator instead of forcing lots of specialized code on the part of the end developer.

Are you kidding? You know, I read http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.html in 10 minutes and I got it. Ready to program, not even one initial 'WTF'. Yes, there are a few rules to obey. But they are clearly explained, easy to follow and they'll still let you use plain Java. How 1998. -- Eelco

Between jMaki and Google's stuff, the client-side flare is cool, but the server integration is horrible. Writing async methods and DTO contracts only to marshall stuff across the network-- welcome to 1999. We have some ideas on how to get true mediator architectures into JSF such that the end developer doesn't need to code anything for AJAX. jMaki and Google's widgets could then use JSF as a mediator instead of forcing lots of specialized code on the part of the end developer.

Are you kidding? You know, I read http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.html
in 10 minutes and I got it. Ready to program, not even one initial 'WTF'.

Yes, there are a few rules to obey. But they are clearly explained, easy to follow and they'll still let you use plain Java. How 1998.

-- Eelco

i thought you where against rules )) for the 1998 thing i can say that i am not that happy with everything that happened between 1998 and 2005 so i have no problem going back and head forward from that point in another direction.

i thought you where against rules ))

Not at all. Any good API/ framework has rules that force you into a proper way of using it. I'm not against abstract classes for exactly that reason. Though saying that out loud typically attracts a bunch of zealots that think the only purpose of an API is to provide flexibility.

for the 1998 thing i can say that i am not that happy with everything that happened between 1998 and 2005 so i have no problem going back and head forward from that point in another direction.

Exactly. I hope you got my sarcasm there :)

i thought you where against rules ))

Not at all. Any good API/ framework has rules that force you into a proper way of using it. I'm not against abstract classes for exactly that reason. Though saying that out loud typically attracts a bunch of zealots that think the only purpose of an API is to provide flexibility.

for the 1998 thing i can say that i am not that happy with everything that happened between 1998 and 2005 so i have no problem going back and head forward from that point in another direction.

Exactly. I hope you got my sarcasm there :)

i certainly did

Between jMaki and Google's stuff, the client-side flare is cool, but the server integration is horrible. Writing async methods and DTO contracts only to marshall stuff across the network-- welcome to 1999. We have some ideas on how to get true mediator architectures into JSF such that the end developer doesn't need to code anything for AJAX. jMaki and Google's widgets could then use JSF as a mediator instead of forcing lots of specialized code on the part of the end developer.

Are you kidding? You know, I read http://code.google.com/webtoolkit/documentation/com.google.gwt.doc.DeveloperGuide.RemoteProcedureCalls.html
in 10 minutes and I got it. Ready to program, not even one initial 'WTF'.

Yes, there are a few rules to obey. But they are clearly explained, easy to follow and they'll still let you use plain Java. How 1998.

-- Eelco

no, not kidding. the tires have to hit the pavement somewhere. if you do pursue the pure remoting, where does the UI correlation occur? even if you did deliver the data to the client, how are you going to update the presentation? think beyond api's and focus on the big picture required by end developers.

Is anyone having trouble accessing the application using Internet Explorer? I can access it fine in Firefox but when I pull it up in IE, I get a JavaScript error. 'bpc' is undefined. I can't even access just www.backbase.com. Not sure whats up.

Is anyone having trouble accessing the application using Internet Explorer? I can access it fine in Firefox but when I pull it up in IE, I get a JavaScript error.

'bpc' is undefined.

I can't even access just www.backbase.com. Not sure whats up.

i just reached it, on both FF and IE ,strange