Over the last month or so we’ve been spending a lot of time doing testing of the new version of IdeaJam so that the XPages plays well with “Classic” (as we’ve taken to calling it). Today we got to the point where we applied the latest beta template against a copy of the IdeaJam production database. Shock of shocks, everything worked exactly as designed. It’s getting to the point where even we can’t tell the difference between the classic and the new versions (which is what we were aiming for). So we get all of the benefits of XPages and very little of the pain from the user’s point of view of things changing because there’s a new technology under the hood.
IdeaJam “Classic” is a good Domino web application (if I do say so myself), but to work on the design of it requires any developers that help us to have a serious amount of experience with Domino web development (I’m talking like 5 years plus). But with our XPages version there really is none of that history required, all the new design elements can be worked on by a developer with the same experience as me, or indeed any other XPages developer, 3 months. It means that we can go from having to worry about all of the Domino “hacks” to make things work, to concentrating on the important stuff… developing a kick-ass application for our customers.
So this is the XPages version of IdeaJam:
and this is the classic version:
So now our copy of production is at the point where we can go to the database launch properties and flick between launch a navigator and an XPage when the user goes to the home URL, and that is all that needs to be done to switch between classic and the XPage version.
Obviously from our point of view there’s a lot of work behind the scenes going on, but for our customers, switching to XPages couldn’t be easier.
Very cool. Did you notice a difference in amount of code between the two version? Could you reuse all of the css?
Chris
Chris,
We are going to share our experiences in some future blog entries and podcasts as well as at Lotusphere 2009. Stay tuned.
What is the benefit of doing this?
To me it looks like you have two code bases to maintain, Xpages and Classic, both serving the same interface. Xpages runs on the forthcoming 8.5 server, Classic on other servers as well.
Is there a benefit to the customer using Xpages over Classic?
@1 – There was quite a difference in the code base, but the new XPages code is a lot simpler than Classic. A lot of the CSS could be re-used but not all of it, again, the new CSS is a lot simpler.
@3 – The benefits come from many different places…
– We can use other developers to help us a lot easier on the XPages code base
– We had customers pushing us to move to a Dojo based front end, which we can obviously deliver on with Xpages
– The XPages interface to IdeaJam scales much better than classic for very large implementations
– There are certain upcoming features which are much easier to develop in XPages than classic, where they would probably have been too expensive to develop.
– And from a purely personal, selfish point of view, it was great fun developing http://www.11tmr.com/11tmr.nsf/emoticons/DLYH-5MZVLY/$File/smile.gif“ />
I understand the fun part very well. http://www.11tmr.com/11tmr.nsf/emoticons/DLYH-5MZVLY/$File/smile.gif“ />
Where does the scalability come from? Less agents to run for rendering HTML??
@5 – Yes there are certainly less agents, we are also able to send smaller web pages out to the browser. Come by stand #227 at LS and I’ll show you the differences http://www.11tmr.com/11tmr.nsf/emoticons/DLYH-5MZVLU/$File/wink.gif“ />
Congratulations on being on the leading edge. Nothing sells a new technology like success.
@Volker, I’m not privy to their codebase, but I’m assuming (based on the work I’ve been doing on Lotus 911 XPage projects) that the bulk of (if not all of) what used to be in agents now runs in server-side JavaScript, which really just means it’s JS being interpreted as Java within a servlet engine, so not only is there less overhead because the servlet is resident the whole time (as opposed to instantiating an agent for each equivalent transaction), but the server can also cache objects that would otherwise have to be re-instantiated for every agent run. Hence, all users can share memory pointers to application settings, etc., which also reduces the amount of database queries.
@8 – Spot on Tim, plus we get some other performance improvements to do with the computation of whether the user has voted on each idea which just add to the benefits of XPages.
“WELL DONE” Bruce and Matt.
Can’t wait to see it at Lotusphere 2009
Tim
Thanks, Matt and Tim, for the explanation. It’s kind of what the Websphere guys told us all the time, right? http://www.11tmr.com/11tmr.nsf/emoticons/DLYH-5MZVLY/$File/smile.gif“ />
In understand you still have to maintain the Classic code, so you are not saving work, but have more scalability.
Matt, do you have any reference for “here’s the broken bits” that you could share? Things like field names in subforms on XPages not showing up in dropdown lists, etc? I’ve been reading the 8.5 Beta forum to try to keep up with what’s known to be broken, what will be fixed in a future release, and what’s just beta weird behavior.
@12 Charles, I don’t have anything documented I’m afraid and I suspect that it would be a bit of a waste of time at the moment with the impending release of 8.5.0. I certainly have three or four things to check but other than those I haven’t got any serious bugs open at the moment.
Ping me on BleedYellow if you want some details.
Matt
I’ll just hold off for gold code and go through my list and see what’s still broken, then we can compare notes. http://www.11tmr.com/11tmr.nsf/emoticons/DLYH-5MZVLY/$File/smile.gif“ /> Thanks for the offer.