logo

Survey: Is There a Future For Non-XPages Domino How-Tos?

I've just finished plugging an e-commerce gateway in to an existing Domino website. To do this I added some fields to a standard Domino Form and then ran a Java WQS Agent when it saved to communicate directly, server-to-server, with Authorize.net.

Nothing particularly ground-breaking in what I did, but there were a few gotchas, which made it tricky. Also, for the non-Java-heads it's would be a little harder than you might expect.

A couple of years ago this would have been the kind of thing I'd have written a How-To article on. Now, I'm just not sure whether it's worth my time. It would take a good couple of hours (probably more) to write a decent-length how-to, complete with screenshots. Before I do that I need to know it's worth it.

The thing that's making me wonder this is not just whether people still read this site, but whether there are still people doing old-school non-XPages Domino development out there.

So, time for a survey:

Cast Your Vote

Are you still developing non-XPages Domino websites?




Comments

    • avatar
    • ursus
    • Tue 6 Sep 2011 04:41 AM

    I never really got into the whole HTML thing in Notes - any time we needed anything I actually got you to do it :o)

    Now that XPages is around I have started doing things myself - I have a couple of new applications out there and, to be honest, am no longer doing anything new "the old way"....

      • avatar
      • Jake Howlett
      • Tue 6 Sep 2011 05:17 AM

      Another lost customer ;-)

      Glad to hear your getting on with XPages though!

      Show the rest of this thread

  1. I'd be interested in such article. I also worked on a similar project lately where I had to communicate with payment gateway using web services. It turned out it cannot be done with Domino alone because Domino cannot present SSL certificates when consuming web services. You can read about this issue here: https://www-304.ibm.com/support/docview.wss?uid=swg1LO50384 . Even though the site says "The problem will be fixed in the next release of the product" nobody at IBM can answer when it will be fixed (if ever).

    Since IBM wasn't interested in implementing such a feature, I used PHP to communicate with web service. PHP and Domino then exchange data through simple GET requests (REST style). PHP part is invisible to users.

    I know it can take a lot of your time to write a detailed article, but you've been quite quiet lately, haven't you? ;-)

      • avatar
      • Jake Howlett
      • Tue 6 Sep 2011 05:26 AM

      I hit a gotcha with the SSL part of things too. Although I could get round mine with a change to the java.secuity file in the Domino\Java\lib\security folder.

      If I don't publish an article I can still let you know how I did it...

      Show the rest of this thread

  2. Even though I like to spent more learning/doing XPages, as it sure is the future direction, the reality is that almost all of my customers have 'classic' Notes/Domino app that need to keep going, fixed, improved. So yes, quite a lot of 'good old' stuff around.

    I do have the impression people are afraid of posting blog-entries dealing with 'classic' Notes stuff. Too bad.

  3. Hi Jake,

    Long Time,

    I still read you, enjoyed the recent LS posts. Had a similar Script Library hell situation recently, but was stuck with designer 7 (and i.e. 6) for reasons I won't bore you with.

    Since my tantrum with Domino, where I unwisely posted never again Domino, I'm now a hardcore Xpages fan and use nothing else. Love it , as long as you avoid the usual horrible Lotus stuff (the ghastly one-ui comes to mind). - My customers also like the Xpages stuff a lot more than the old form based stuff...This is a good test, as I converted all my apps to Xpages.

    A lot of your good old tricks are still applicable when hacked about with to Xpages development.

    You should write your article. It will still be valid for Xpages heads...We just call WQS's slightly differently, but your stuff is always good value, and worth the read.

  4. Some applications are too large or the customer simply doesn't have the budget to migrate to XPages. I see there being a lot of hybrid sites for some years, and maybe some that remain with no XPages design (though the pace of change in web development makes it more likely that the client will want or need to redesign or enhance)

  5. There are still applications in certain circumstances where developing in XPages in not appropriate. Internal mobile apps for one. "Smart" mobiles are still limited by the amount of memory, processing power and bandwidth. Admittedly it's better these days, but the overheads and costs with can XPages version of an app compared to an "Old School" version is still surprising.

  6. Jake, I had abandoned domino before XPages came along. I've just voted "No, I don't do either" but I think you should have added; "..but I still visit the site because it's a cracking read" to this particular option.

    Loved the Android stuff recently.

  7. To tell the truth, I haven't done a single thing with XPages yet. :X I created a JSON-based system for Notes Documents before XPages came around, and have just stuck with it for years now, just upgrading my JavaScript front-ends.

    I haven't seen a need for XPages yet, and wonder if I ever will before my company completes its .NET transition. :(

  8. A couple of things come to mind (as usual). IBM has set themselves a rather expensive bar. Keeping up with rapidly evolving internet standards in terms of the output generated by XPages is going to, in my opinion, reduce IBM's incentive to keep Domino up to date going into the future. I've thought about this in the past - what is the motive for IBM to keep Domino on the cutting edge if the tools are let go for free, the market is shifting and they've added so many developers to update the tool to where it is (presumably though many of those come and go, the balance being less than those needed for the 8 build?). And I'm no seer, I don't know all of what goes into this... just superficially, I can see where IBM in the near future see's the benefit of stopping updates to the Domino code. Which leaves XPages where legacy domino is, stuck... but worse in that it has so much baked in to it it rapidly loses pace with standards with a large technical debt for any developer tasked to update it.

    It has often been noted by you, Jake, and others like us that IBM's decision to have Domino decide how to generate any HTML or JavaScript has been the biggest problem for Domino as a web platform. XPages and One UI + Dojo only doubles-down (or worse) on this same problem. If you have to update these to meet new standards, tweaks are probably not going to cut it. Rip and replace will be the order of the day.

    The smart developer is going to keep his toolbox full of tips and tricks for how to do it the old way. Sooner or later, you will find yourself with some other platform and knowing a lot of how to do it from scratch and building your own way around a problem is going to serve you better as a developer than knowing how to wrangle XPages into giving you what you want.

    I sat down last Friday to try a benign little XPage idea I had. I wanted to take a view with a simple document and create a repeating section for each document. Really, drop-dead simple. I added a repeat control, added a data source (view), and mapped the control to the data source and the first column. It all compiles fine with no indication of error. But to run it, I get a "error getting property 'columnname' from bean'. Issue: the designer let me easily make something that breaks right off. If I'm writing my own code, I expect this. But if the framework is tightly integrated with the IDE - - it should just work. Then I go to correct it and the 'bean' is apparently broke for good as the same error shows no matter what I do, including replacing the controls with simple text. No recompile option? Apparently not. So why such a struggle to get XPages to do something that would be drop-dead simple with a bit of LS or Java? There's the other reason I don't see XPages as as long term solution. The ROI is low for your efforts as a developer. The framework is so deep that anything you want to do in XPages is wholly dependent on XPages. You can't easily beg barrow and swap code between non-xpages stuff and you "have to" do it the XPages way to get it to work... and to top it off, that "way" is a bit esoteric and difficult to come to grips with when the IDE can't even guide you to creating functioning content without serious issues.

    Now, no doubt, I'll once again be raked over the coals for breaking faith with IBM, ridiculed for being too stupid to see the beauty of XPgaes and accused of damaging reputations. But honesty demands it, and we owe it to ourselves and our customers to be honest about the short-comings and outlook for XPages. For me, the "old way" will always be the smart way while I acknowledge that XPages is the "cool" way, the shine will fade in time as browsers continue to move forward with new standards and features and XPages becomes more expensive for IBM to keep up to standard.

    So, Jake, sorry to lay this here but your question brings the issue to the fore. I find most of what you share of value, but like you question the level of interest in doing it the old way. Personally, it's a post I would read with interest. It's the sort of adventure story I like. Worth your time? That's up to you. If you enjoy sharing and telling a good story, why cut yourself off from your joy?

      • avatar
      • Jake Howlett
      • Wed 7 Sep 2011 03:19 AM

      "If you enjoy sharing and telling a good story, why cut yourself off from your joy?"

      Good point. I do enjoy sharing. BUT. I bet most musicians enjoy playing music, but would they play alone in the Albert Hall if nobody turned up to listen?

    • avatar
    • Michael
    • Tue 6 Sep 2011 09:30 AM

    Hey Jake,

    I tried to vote but It's telling me that someone else at my IP has already voted. I don't know if that means I was counted or not but we're still old school all the way on 8.0.2! We're a big company and we only use one public IP at a time (we have backup IPs if one is down).

    I'd love to see an article on this!

  9. I haven't seen if pages will support HTML5. I've been on disability for over a year now. As a programmer very interested ion the front end code I'm not impressed with the little I've seen. I believe that Jerry Carter has a good point. Also, many of the clients my friends support haven't even upgraded to 8.

    I'd like to see what you had to do.

    • avatar
    • CJ
    • Tue 6 Sep 2011 01:06 PM

    I think any article is worth publishing regardless if it describes some techniques that solved a problem.

    Maybe nobody will have the exact same situation, but having read how you did something may well get the brain thinking in another direction when someone has a different issue.

  10. The learning curve for XPages has been too steep for me to get much traction.

    I have a set of Java libraries and Domino infrastructure I've written that supports the kind of web applications I've specialized in for about ten years now. I can get Domino to do most anything I need without XPages.

    What Jerry Carter said earlier in this thread really resonated with me. The fact that IBM doesn't keep Domino in the same decade with the latest technology is one reason I've recently started looking (again) for some FLOSS framework to move to and Zope/Plone (again) leads the pack in my research.

    What I want is a flexible content management system to start with which I can style, configure and modify any way I want. Notes/Domino is such a system but the start up and maintenance costs from IBM make it hard to justify to the small customers.

    But I'll continue to read your blog just because I like what you write. Now if you start developing with Plone ... that would rock!

    Peace,

    Rob:-]

  11. Hey Jake

    Just wanted to chime in too.

    I haven't done anything with Lotus in almost 2 years, but I still come to Codestore very often just to read. Like I said before, I follow you because I enjoy your writing and enjoy seeing where you are in your engagements.

    I enjoy reading them no matter the topic.

    Thanks for many years of good reading and I hope for many more!

  12. I am saving domino development related articles, blog entries, presentations for about 10 years now.

    I see weekly 1-2 'traditional' Domino development items appear on the web compared with 10-20 good XPpages related entries.

    So I assume most 'front edge' developers are now occupied with XPages. I am too.

    So if you want to be a margin, go with writing traditional Domino development articles. But if you want to have broader focus my suggestion would be to write XPages development articles.

    A lot have been discussed, presented etc. before but I guess XPages development for most has gone to the next level (from novice to medium/advanced).

    We all know how to display a Notes view in a viewtable by now. But we search for education 'there where no one has gone before'...

    Welcome on board!, by the way =)

      • avatar
      • Jake Howlett
      • Wed 7 Sep 2011 03:11 AM

      "my suggestion would be to write XPages development articles."

      It's not as simple as that though. I can't just write about something I know nothing of. I write about what I'm doing at the time and so far that has yet to be XPages. I get a nice varied selection of jobs come my way, but nothing with XPages.

      The results of the survey above have been interesting. It appears to me that what most bloggers are talking about doesn't necessarily reflect what's going on in the real world.

      Based on feedback above I will write the article. After all - if I am still writing ecommerce apps in Domino the old way - what's to say other people aren't?

      Show the rest of this thread

    • avatar
    • Barry McGovern
    • Wed 7 Sep 2011 06:04 AM

    I'm finding it's just not cost effective to implement an xPage system into an existing traditional system. They really are not compatible and you seem to have to redo quite a bit. Many times the only justification I can give is because I want to and need to to stay current. Which of course the client is not going to pay for. So it's just a non-starter for me a lot of times.

    So yes - please keep with the traditional posts.

    • avatar
    • Chris C
    • Wed 7 Sep 2011 09:50 AM

    Years ago I was looking so forward to XPages and what they could do (like making data more relational), but when I actually got my hands on it and tried creating some sites, I was not too impressed. I think the web pages that XPages spit out are ugly and I haven't found a theme or style sheet that makes it nice enough looking to use. I've also found XPages painfully slow. I use multiple templates for my sites and if I used XPages, it would bring a powerful server to its knees. I know with Domino 8.5.2, you can share the same XPage across multiple databases, but you need to restart the HTTP process every time you make a change. I don't know how IBM could believe shutting down a production web server and kicking everyone out (session based authentication) is a reasonable requirement!

    I also don't like how poorly integrated XPages are into the whole Domino model, it just feels bolted on.

    So I still do things the old way. Recently, I've found myself shying away from LotusScript and its limitations as a OOP language and limited feature set and I've been doing most of my new agents in Java. At least with doing things in Java, I can transfer my skills elsewhere when IBM eventually lets Domino wither and die. I'm also still bitter all these years later that IBM removed native JSP support from databases, which could have been a real game changer.

    1. First of all, don't expect Domino to be more relational, it's a document based system at heart :)

      Domino 8.5.2 has integrated support for OSGi and Apache Equinox. Equinox is a lightweight servlet container, and is from 8.5.3 replaced with a full servlet engine. If you don't like JSF, feel free to use something else, we use Freemarker and our own MVC framework, built in Java and Groovy. It gives us full control on the result, is lightening fast, and we feel it's easier to develop for than xPages.

      In my experience, the xpages engine is seriously fast, much faster than traditional forms, but I don't develop much with xpages itself, I find dragging and dropping unvieldy, and "programming" in xml an abomination.

  13. Jake,

    XPages has many nice things that you can do with it. If you are use to the traditional Domino Web development method, the learning curve is steep. However, if you come of other platforms it is not that bad. However, XPages has many undesired consequences that I do not like. Therefore, I use my own content management system that generates Dojo and HTML that allow me to create cross platform code. It requires less resources than XPages and uses a simpler approach.

  14. I have to echo Robert Shaver's comments

    "The learning curve for XPages has been too steep for me to get much traction.... I can get Domino to do most anything I need without XPages."

    We're still happily using R7 and haven't seen the need to upgrade. Hopefully, you will continue to write articles supporting the developers out there who use the legacy versions and functionality.

    • avatar
    • Richard
    • Fri 9 Sep 2011 08:24 AM

    Unless there's an obvious need for a web browser, most of my Notes customers still prefer "old school" Notes apps. And if the Notes client can't provide the functionality I need, I can almost always get what I need by using Java -- either in agents, standalone Java clients that talk to Notes or even embedded custom Notes applets. The only way my customers will abandon standard Notes development is if IBM pulls the product from the market.

    • avatar
    • chuck
    • Sat 8 Oct 2011 11:45 AM

    Legacy domino is not going away, or this book would have no sales.

    IBM Lotus Domino: Classic Web Application Development Techniques by Richard G. Ellis

    Packt Publishing

    • avatar
    • David
    • Thu 13 Oct 2011 05:17 AM

    As much as I'd like to get into XPages, budget constraints at my employer mean we can't upgrade, so we still operate on 7.x and 8.0.x

    I have to say that I've never struggled to do what I wanted with any Domino web app I've written and all I've ever needed to use is pass-thru HTML and jQuery/jQuery UI.

    Using non-platform specific stuff is also useful as I recently used the exact same methods while putting a PHP based site together.

    In saying that there are many features of XPages that would be very useful, but we simply can't upgrade.

    • avatar
    • Thomas
    • Tue 13 Dec 2011 07:39 AM

    Just doing "normal" domino client/web development, lokoed into Xpages but could not really find out the proos of it when building complex applications, perhaps i gave up to early, now the company i work at are trying to remove Lotus as server from the company, even though all intranet and 100's of important applications are up and running, seen that before... sad that some people dont understand the value of have a platform like 8.5.*

    • avatar
    • Dennis
    • Thu 5 Jan 2012 09:30 AM

    Yes. XPages is overkill for many. I found it to be buggy and more time consuming. We're frozen on 7. Will continue to support several apps for years to come.

    • avatar
    • Jon
    • Sat 27 Oct 2012 07:40 AM

    I found learning xpages very time consuming with very little quick payback. Recently I've been using bootstrap, jquery, jqueryUI with Domino to build applications quickly and they really go down well.

Your Comments

Name:
E-mail:
(optional)
Website:
(optional)
Comment:


Let's Get Social


About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content