Still Not Quite Sold On XPages.
Despite the fact that XPages seem to solve many of the gripes I've had with Domino over the years I'm still not quite convinced they're the answer to all my prayers (or even that they're of any use to me at all).
First of all I want to thanks all of you who helped me on Monday in understanding what XPages are and (more importantly, I guess) what they aren't.
There was me thinking they'd fit in nicely with what I've been doing all these years. Turns out I need to radically rethink my approach to Domino development. Not that that would be a bad thing I guess.
Before I delve in to them I have a few more things that are troubling me:
Query 1
First thing troubling me is the front-end that comes with XPages. By that I mean the fact it's tied to Dojo. To use the goodness that comes with an XPage you need the user to download a hefty list of JavaScript and CSS libraries.
I'm guessing it is tied to Dojo and one specific version of it? A version that will probably always be several behind the latest release and so annoyingly limiting in what you can do (a bit like with Java and Domino).
Or can you use a different library? This was asked on Monday in the comments and, while I'm sure the answer is obvious to those who know, there are some of use who are unsure (myself included, although I think I know the answer).
Query 2
Is it possible to use the back-end power of XPages but leave the front-end alone? Can I opt to use no libraries and just have XPages output normal HTML to which I add my own JavaScript if needed?
Most of what I build with Domino for the web are not web applications per se. Also, a lot of what I do needs to be accessible. Both of which make me think XPages are a no-go for me in the most part.
Query 3
Another thing I'm wondering about is whether XPages are strictly for front-end use or can they be utilised as a back-end only solution?
By this I mean can I use the power of XPages's server-side JavaScript processing from an Ajax call for example. Can I point a normal (jQuery say) Ajax call to a URL that ends in "/myxpage.xsp" and have it just return XML or JSON under the relevant content-type and without any GUI?
I'd also like to point Flex applications at URLs ending in .xsp for their data. Is this possible? Only if I can specify the content-type and remove the GUI elements.
Again I think I know the answer to this, but this would be what I'd like it to do.
Lazy Me
I know this all seems like lazy research on my part, which, to a degree, it is, but I ask in public (at risk of looking even more stupidly out of touch than I did on Monday) as I assume I have readers who, like me, are yet to delve in to XPages and are wondering the same things.
At some point soon I am going to play with them and read the suggested links you guys have provided (particularly Declan's comprehensive series on the matter), but for now I just want to make sure I know what I'm working with and clarify what I already think I know about them.
Skip to the 
You can subscribe to an individual
Regarding Query 2, I asked the same in my blog. The answer I got was that it is possible, but you have to write your own "XPage-compiler" in Java.
Regarding the third query, you can write XPages almost like agents.
Read more about that here:
http://www.wissel.net/blog/d6plinks/SHWL-7MGFBN
I think I feel more or less the same as you about XPages. I love the speediness/the ability to write pseudo JS on the server-side. I don't love the enforced bloat.
Hopefully this is only the first step to a great technology, and not the only step as with so much other half-assed implemented Lotus tech (CSS/JS in the client, to name a couple).
You are not alone in your thinking Jake.
I too have avoided the XPages for my websites because there are just too many issues.
My biggest gripe is state transitions. Where is the indication that you are actually saving data and thereby modifying the system? When you move back through the history you lose a lot of the current position. For example when searching a "view" you move onto the second page in the view, click onto the document, realise that this is not the doc you are looking for and go back in your history. You are now back at the first page of you search rather than the second where you left it.
There are still too many inconsistancies with it to throw it at end users at present. There are a lot of CustomControls that need to be written to replace the shed load of subforms that developers have built up over the years.
Trying to add in external features causes too much conflict. I have a routine that uses MooTools, can I add that without out conflicts? Apparently not. It does conflict and cause huge issues.
Another issue is with mobiles. I now develop for mobile browsing. The huge bloat of Dojo and it's libraries means you have no way to gracefully degrade your pages. So now I have to develop for the Client, for XPages, and revert to normal pages for Mobiles.
Thanks, but until XPages solves a lot of the problems involved with it, I won't be putting it anywhere near my production systems.
Jake,
Of course XPages are not a panacaea but they do massively improve the lot of the Domino web developer, especially if you don't want to learn the multi level hacks that you have to employ to produce anything nice in classic Domino web development.
Query 1 - The 8.5.0 server comes with Dojo 1.1.1 (I believe 8.5.1 will ship with 1.3) but you are able to install your own version of Dojo on the server and then can switch you use in your application. Though of course you have to be aware that certain Domino generated code may no longer work. In theory you could use other frameworks but it would largely negate the benefits of XPages (i.e. that you don't have to write very much client side JS).
Query 2 /Query 3 - are largely the same question and Tommy has pointed to the answer from Stephan. You can effectively turn your XPage into a servlet with no UI component.
@Dragon - A lot of your state transition issues can be handled with sessionScope or requestScope variables (which are used to store information about a page or user session in memory on the server), but you're right there's little you can do with people who use the back and forward buttons, the app just has to be designed with this sort of activity in mind.
Matt
"there's little you can do with people who use the back and forward buttons, the app just has to be designed with this sort of activity in mind."
Whilst this may not have been your intention, you make it sound like people who use a browser in the normal/ expected way are in the wrong. :S I can sympathise with the issue as I have had a problem with something similar in the past, but you can't expect people to not use the back and forward buttons on a browser... so as you say the app needs to handle it.
@Matt,
So you still have to create your own hacks to make the system work properly. How is this different from "traditional" Domino development then? Oh thats right. It's not. It's just another kludge. Thank you, but I'll stick with the kludges I've developed over 16 years of traditional Domino hacking until this new whippersnapper actually solves some business issues that I have.
It's all very well having a new way of developing apps (and I applaud it for that) but it does not ease my development needs. Just using it because it's there is not a valid reason for changing the development styles of what works.
@Dragon.
All I can say is do as I have done and recreate your app using xpages..Look at the difference between your existing app and what you have built in xpages and then make your mind up.
I am also a sharepoint developer and I know for absolute undeniable users prefer sharepoint, not because it's better, 'cos it ain't, but because for some reason it is more intuitive.
Now put a view in a view panel in a Domino xpage and you are looking at the same user intuitive interface that sharepoint users enjoy.
As for Java in domino, Jake, I realised that the problem was me, and not Domino. Having sorted myself out I am well happy with Java in Domino.
xpages in it's early generation is the same. I have to say that I have never seen web based Domino views render faster than they do in xpages.- I am today replacing my existing web views with xpages containing views.
Yes I have my gripes, WQO and WQS agents and at the moment ie8 breaks dojo, which should be fixed with dojo 1.3 in 8.5.1
What you describe is a typical Ajax problem and not related to Dojo or IBM. An Ajax call does not create a history entry and manipulating the history is not permitted (in theory it would be quite elegant to just write the back url link into the browser history). There are ways to address this. Last.fm for example has a very good way of mixing Ajax with regular html elements.
It seems that you now discover some of the quirks with XPages. That is why I normally describe XPages as an Intranet 2.0 technology. When you are inside a LAN and bandwidth, response times and search engine friendliness are less important XPages can be a good thing. If you work for the real web things get a bit more complicated. Much of what is described here is addressable and XPages is just in its first release. Speaking only for myself I really like jQuery and am not yet willing to give it up. Domino always had the tendency to generate a lot of code for you. Experienced developers just got a tendency to switch it all off (and become passthru junkies). I think it will take some time and experience to get the most out of XPages.
From one ultra-Domino-web-guru to another ultra-Dominio-web-guru, I understand your line of thinking.
My #1 gripe is similar to yours - the lack of ease with which you can integrate them into existing apps. Sure, you can start replacing forms one-by-one (and just being able to do that is actually pretty cool) but you do have to recode your subforms, etc.
The biggest problem here is the lack of incorporation with WQS agents, as was mentioned. If you happen to have written your agents in Java you can tie them in directly on the xPage in a fairly straightforward fashion, but LotusScript agents are just plain stuck.
But aside from that, xPages are definitely way, way WAY awesome.
Real CSS hooks, javascript-accessible Domino object hooks (no creating <computed value> tags just to expose a hidden doc field to Javascript), REPEAT CONTAINERS, self-contained/automanaged JS namespaces, etc. etc. etc. etc. And custom controls make subforms look weak in comparison.
The future sounds awesome with them, too:
- 8.5.1 introduces xPages to the Notes client
- 8.5.1 (rumored) to have on-the-fly GZIP compression for all web-delivered Domino content (should drop the Dojo/JS/CSS bloat a bit)
- some later release having way awesome integrated mobile support for xPages
And on top of that, showing new Domino developers xPages isn't a complete disaster/embarrassment (like it is with traditional Domino webdev).
"By that I mean the fact it's tied to Dojo. To use the goodness that comes with an XPage you need the user to download a hefty list of JavaScript and CSS libraries."
Only if you want to use the default provided controls, like the RT editor or attachment handling. But you were stuck with whatever classic Domino provided you with before, unless you rolled your own custom solution, so the problem is the same as it was before. Except now your editor is open source.
"I'm guessing it is tied to Dojo and one specific version of it?"
Dojo 1.1.1 is embedded into the 8.5.0 shipping code. It's not buried down in the source code, though. You can go to the folder on your Domino server and open (and edit) the .js files.
"A version that will probably always be several behind the latest release and so annoyingly limiting in what you can do (a bit like with Java and Domino)."
Except neither of those is true anymore. 8.5.0 has Java 6 on both the server and the client. And 8.5.0 comes with Dojo 1.1.1, which is 1 rev behind. And you can replace it yourself if you so choose. (I'm not sure if they're providing 1.2 with 8.5.1.)
"Or can you use a different library?"
You can include any additional Javascript libraries you want, whether you simply drop them on the file system of the Domino server, or you import them in as JS resources in your template. You only risk is namespace collisions, and I'm pretty sure all the major packages have made very specific efforts to address that.
"Is it possible to use the back-end power of XPages but leave the front-end alone?"
Yes.
"Can I opt to use no libraries and just have XPages output normal HTML to which I add my own JavaScript if needed?"
That's actually pretty much the default behavior, especially if you're editing from the Source tab instead of the Design tab. Except for Rich Text, you actually have to go out of your way to force the Dojo controls.
"By this I mean can I use the power of XPages's server-side JavaScript processing from an Ajax call for example. Can I point a normal (jQuery say) Ajax call to a URL that ends in "/myxpage.xsp" and have it just return XML or JSON under the relevant content-type and without any GUI?"
Yes, absolutely. http://www.wissel.net/blog/d6plinks/SHWL-7MGFBN
"I'd also like to point Flex applications at URLs ending in .xsp for their data. Is this possible? Only if I can specify the content-type and remove the GUI elements."
See above.
@Nick,
"All I can say is do as I have done and recreate your app using xpages..Look at the difference between your existing app and what you have built in xpages and then make your mind up."
Love to. But it's called time. Or rather the lack thereof. When you spend a year creating a website, there is no point in trying to spend a few days trying out which is better. Face it, it's just not going to happen.
So do you spend time building something in XPages for a new client? Well no, because the client will not tolerate the delay whilst you re-write everything.
Until XPages has had at least a couple of years of settling down I do not see the need to switch.
@Erik,
"And custom controls make subforms look weak in comparison."
Agreed. Re-usable. Versatile. And the fact that you have to re-write all your old subforms for XPages.
"8.5.1 (rumored) to have on-the-fly GZIP compression for all web-delivered Domino content"
And thats better? Yes, much better for the Intranet. But not for websites. There is a huge explosion in mobile devices, you need to be able to degrade nicely. XPages does not give you that option. It's all or nothing. GZIPing the content does NOT help mobile devices. It makes things worse.
Though I am definitely looking forward to better mobile integration, because without it, XPages is going nowhere.
"XPages does not give you that option. It's all or nothing."
This is factually incorrect. Xpages provides different render kits for different target platforms. You probably won't see strong mobile differentiation in 8.5.1, but it won't be long thereafter.
@Dragon, you may be right but I went out and learned sharepoint, which I don't like at all, because here in Oz it is slaughtering Domino, yes on intranets/extranets - not websites, but int/ext's what I do.
8.5 and xpages makes me believe that I can once again go pure Domino and compete on an equal basis.
I'm afraid that out there in the marketplace that I exist in the old Domino way just doesn't cut it anymore, and I'm not going back.
Hi all..
I have been a Notes Developer for over 10 years. In that time, i have gone from R4.5 to R8.5. Over all those years, I have always had a gripe with Domino on the Web...... It's not tailored for the web. You have to write too many work-arounds, etc... to get anything done.
XPages promises to help us to rectify this. Where as it does add in some nice novelties, it does not fix some major unlying problems and bugs with Domino on the Web. It's still not tailored for the web. What do i mean???
- GZIP (mail file only? Puakma Web Booster???)
- Proper Caching (Puakma Web Booster???)
- SearchOrder=4 (no longer a bug, now a feature!)
- View Navigation (Next / Previous, Page Count....)
- Server Side Scripting, AJAX, JSON
- etc....
They are my major gripes. There are loads more....
I really think that IBM, should fix the current issues on the Web side of Domino, first! Instead they have added another thing, that we will have to learn and create new work-arounds too....
Later
Patrick
I used to make allot of ajax calls to agents to run lotuscript and return data back to the browser, when i first started with xpages i wanted to do the same thing, but then it hit me, i just change the lotuscript into server side java script and have the same logic, the only thing difference in the code is the formatting really.
Server side java script makes my life allot easier and i have not found anything i could not do that i could in lotuscript
@Dragon:
"And thats better? Yes, much better for the Intranet. But not for websites. There is a huge explosion in mobile devices, you need to be able to degrade nicely. XPages does not give you that option. It's all or nothing. GZIPing the content does NOT help mobile devices. It makes things worse."
I'm talking about Accept-Header compression. If the browser client supports GZIP/deflate encoding, Domino 8.5.1 will auto-compress the content prior to delivery. It should be fine for mobile devices.
@Patrick:
GZIP (mail file only? Puakma Web Booster???)
---- 8.0.x supports this with external files, 8.5.1 should do it for ANY NSF also.
Proper Caching (Puakma Web Booster???)
---- Not sure what your gripe is here, Domino's caching algorithms are pretty good and you can tailor the headers further.
SearchOrder=4 (no longer a bug, now a feature!)
---- Yeah, this sucks, but there's workarounds now and xPages actually does help quite a bit here.
- View Navigation (Next / Previous, Page Count....)
---- Again, xPages help a lot here.
- Server Side Scripting, AJAX, JSON
---- xPages, xPages, xPages.
@Erik Brooks
I stand corrected. XPages does a lot more than i thought it did.
As for 8.5.1, is it confirmed that GZIP will be for all db's?
As for the SearchOrder=4 and View Navigation, is XPages the only solution? I would rather see a solution for my current databases and designs.
- Why can't i make the default view navigation for all db's on the server, similar to XPages?
- Why not just fix SearchOrder=4, for the server?
Ha, ha, ha......
Here's another gripe..... I now have to go off and learn XPages to put all this new stuff into my databases!!!
All I'll say is that once you get over the learning curve and see how powerful XPages are then you'll be able to develop some great web apps in half the time you currently spend on them.
@Patrick -
Yes, pretty much anything that was Domino Web development before XPages is in support mode. Meaning they are only fixing bugs that get customer demand.
Yes, you need to go learn XPages. But the flipside is that with 8.5.1, your web apps will work in the client and off the server. And soon after that, natively on a blackberry and other devices.
Change can be hard to accept. People hate it and reject it. But sometimes change brings new ideas, methods, and outcomes. Personally, I think XPages will revolutionize Domino web development and we won't do anything but withing 18 months. We shall see if I am right or wrong.
@Patrick - There's no reason you can't use XPages ONLY to replace the view navigation in your current apps. Solve your view navigation issues and change nothing else. Easy. Really.
What I will be REALLY interested in seeing is your thoughts on Flex compared to XPages for Domino developers.
Haven't sued XPages, as the company I work for might be staying with 7 for the conceivable future, but all I know is that at one time I said I'd never use JSON, either. :P
I haven't used xpages yet but I am working on a technique for running fully integrated ajax apps inside the Notes client without running http.
I have a working prototype that uses the Adobe Spry framework to format the results (returned as xml) of an FTSearch that Spry then converts to an html table. The application is on a tab inside the Notes client (developed in v7.03 and tested in 8.5) and from a user perspective is just part of the application.
This approach should work with any ajax libraries, as well as Adobe Flex and Silverlight).
I still have some kinks to work out but things look promising and will provide a lot of choice for developers.
I would love IBM to more formally announce a statement like "pretty much anything that was Domino Web development before XPages is in support mode". If customers are forced to overhaul all their applications the risk is high that parts of the customer base may not follow. The assumption that XPages is exeptional in the market often is not shared outside of the yellow bubble. It's core is derived from a product that died a painful dead some time ago. This does not change the fact that from a Domino perspective this is a hige thing of course. And I agree that you cannot continue with the traditional way of developing Domino applications. Either adopt or move on. The market is full of exiting stuff nowadays (although I cannot confirm this for Sharepoint).
Jake, you should think about a preview function. Shame on my English but it is not my mother tongue.
Just read most of the posts.
One thing I like about xpages... It brings RAD to domino web development. One thing I didn't like about web development with notes was the fact that I had to decide which js framework I had to use. I lost lots of time learning a new js framework (dojo, ext, prototype,etc. ). My primary goal is to develop applications web and/or notes. I want to get my things done. With 8.5.X I'm able to do it with (almost) one tool. RAD in notes client and with xpages in the browser too.
Before I go to bed I wanted to thank you all for the input. I've been reading it all as it came in and have been taking it in.
I think I'm just about sold on XPages now. Enough to want to spend some time getting to know them in detail. I need to do that before I can decide exactly where they fit in my bag of tools.
The only comment from above that I want to respond to for now is that "pretty much anything that was Domino Web development before XPages is in support mode". I guess that should concern me but, as I think about it, nothing's changed for so long now that it doesn't at all. My toolbag has had so little added to it over recent years that I don't think I'd really notice.
BTW: Henning. The preview function is the box you're writing in. Just re-read that before you press the button ;o)
@Patrick: gzip is actually available in 8.5, but only within the xpage context (take a look at the db properties/xpages tab from domino designer). @Erik: glad to hear that gzip will be a db-wide feature in 8.5.1 - hope the rumor is true ;)
The more I play/develop with xpages, I find myself more and more happy with the technology. I use xpages both the regular way but also as pure data sources (delivering JSON with ease to different front-end components (with the json package from json.org), and XML to external systems). Access to the native servlet context is very convenient (it also allows you to output binary data directly, not just textual stuff)
I really like that I can join data from several locations and display it in a view control (thank you Nathan for the tutorial). Access to the back-end at runtime from almost everywhere inside the xpage is very, very powerful
Another thing I like is that we now can put several view-components on one xpage and control them individually from the URL to the xpage (via the RequestParamPrefix property on the view-component). This means for example that you can perform a search in one view and a single-category restriction in another and expand a category in a third, directly from the URL (or compute it at runtime)
The property definition mechanism on custom-controls and how it allows us to build reusable and very advanced components that can be configured to plug in nicely to different contexts is another thing I find very useful.
The possibility to store stuff in different scopes is something that’s been on my wish-list for a long long time. This makes overall development way more effective.
The “large” number of JavaScript includes, and CSS includes (http requests) is something I hope eventually will go away - I hope a solution similar to Yahoos service that allows you to merge all js files into one file (automatically on-the-fly) will be developed for Dojo/domino (or for all js files in domino). Today’s solution can be implemented more elegantly imho.
I can live with the “hi-jacking” of id’s, and the extra effort to calculate id’s if I want to access them from a client side JavaScript or similar (I understand why). I can live with the bugs currently in Domino Designer (for now) and other strange stuff happening from time to time because I can see progress and (true) commitment, stuff is *finally* happening in the domino development area.
I really don't like the over-dependence on JavaScript with XPages. The beauty of the best JS frameworks is their un-obtrusive design, so if JS is not supported on the user's browser then the site is still usable, albeit with more limited functionality. You just don't get that with xpages.
For example, disable JavaScript and all links in an xpages view will break. Even with JS enabled in Firefox, if you click on a link with the scroll wheel to open in a new tab (something I do all the time to increase productivity - opening numerous documents at the same time saves waiting for the page to load each time) you don't get the document you were hoping for, just the view again in a new tab. Not very helpful at all (try it out on the new OpenNTF catalogue).
There is a lot of talk about traditional domino development and how it is not possible to do the stuff XPages can do. That's just not true. Domino in its traditional form is so flexible that if you just use a framework like JQuery with it you can create equally stylish, web 2.0 style web apps. Those who say otherwise are probably stuck in their ways doing things the same way as 10 years ago, and so are more likely to be blown away by XPages. It may not be as drag-and-drop quick to create the app, but so long as you know your stuff it doesn't take a great deal longer.
Like Jake, I am concerned by accessibility as most things I do in Domino are client facing, so must meet accessibility guidelines. I see the lack of functionality without JavaScript enabled to be a big problem in this sense.
I have played with XPages, and undoubtedly some things are cool; most notably the repeat container, and I may use them for internal apps that can be knocked together quickly to serve a limited purpose, but large-scale customer facing apps? No, I just don't believe that they're ready for that yet.
"Like Jake, I am concerned by accessibility as most things I do in Domino are client facing, so must meet accessibility guidelines. I see the lack of functionality without JavaScript enabled to be a big problem in this sense."
@Cass & Jake: Can you expand a little on your reasoning behind the above comment please ? Using Javascript on a page does not automatically make a Web page inaccessible...?
DConnolly: "Using Javascript on a page does not automatically make a Web page inaccessible...?"
True. But, it does make it inaccessible if the page doesn't work without the JavaScript on it, which, in the case of XPages I suspect is true.
From what Cass is saying it sounds like XPage "views" have links that are JS-only, so you can't get to the underlying documents without JS.
"Using Javascript on a page does not automatically make a Web page inaccessible...?"
This is very true, but sole dependance on JavaScript can be an issue if you want your site to be fully accessible to all devices. JavaScript support in some browsing clients such as Screen Readers has traditionally be flaky at best, which is why I always try to make sure my apps will still work in some form or another without JavaScript enabled, albeit with more limited functionality.
Admittedly, my knowledge on this subject may not be completely up to date and I may not be fully informed into the capabilities of the very latest screen readers, etc (feel free to correct me on this if an expert in the field reads this), but either way I believe JavaScript use should be unobtrusive, and should be used to enhance an app's functionality, not be reliant entirely on it.
@Jake: Sorry, but can you point me to the source where you got that "it does make it inaccessible if the page doesn't work without the JavaScript on it" please ?
Many of the latest assistive technologies have no problems working with javascript on web pages and each of the controls that come with XPages have added attributes that enable them to output more accessibility friendly HTML.
DConnolly: When you say "latest assistive technologies" what do you mean exactly? Things like JAWS? Like Cass my understanding in this area is probably a little out of touch.
Are you seriously implying that if you are using a device that does not support JS and you go to a page where none of the links work, you still consider that page to be accessible?
WCAG Priority 1, Guideline 6.3:
6.3 Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.
http://www.w3.org/TR/WAI-WEBCONTENT/#tech-scripts
Actually Jake, if you ignore the Links property in xpages view containers and then in column properties of the view for that one column specify html and code your view with an html link in that column only, you have one html link in a normal view in xpages that will open the underlying document. The other columns are rendered as notes content.
This is one of the huge powers of xpages. You can mix and match where before we had to do either or.
I can now write a view with html only in the one column I wish to use to open the underlying document, and render the other columns using the view display property...Easy or what?
@Jake: yes, screen readers like JAWS have been working to add support for the new Web 2.0 technologies as they become more prevalent.
@Cass: The WCAG 1.0 standard that you refer to was published 10 years ago in 1999. There is a newer WCAG 2.0 standard that is available that is more in tune with advances in Web technologies. You can also read up further on Web Accessibility Myths around the use of Javascript here...(see Myth 4)
http://www.techsoup.org/learningcenter/access/archives/page9994.cfm
@DConnolly: Thanks for the info... I think it's about time we update our accessiblity software on our testing network then to something that supports WCAG 2.0. We're still using Hi-Software's AccVerify tool which only covers WCAG 1 priorities 1,2 & 3 and Section 508.
I know the WCAG 1.0 was published in 1999 but it looks like it was still valid until as recently as last year.
I would still like to see XPages use an unobtrusive technique with a valid href (instead of '#') on the view links. This would allow the link to fall back on the href url in the event of a user not having JS enabled and would also make the links work when opening them in a new browser tab.
Nick mentions that you can obviously code your own html links, similarly to how you could always use your own HTML in domino views, but I believe this should be the default behviour of the links property, not something extra you have to code in yourself.
For no good reason other than I just REALLY enjoyed reading the above discussion.......
Jake - I just wanted to say thank you for still having one of the easiest to read Domino blogs. It has been over 6 years since I started reading and contributing and I am still enjoying it.
Thanks Mark. It's the comments like yours that have kept me going all this time!
just a confirmation on GZIP in 8.5.1
See my blog:
http://nevermind.dk/nevermind/blog.nsf/%28lookupblogdocs%29/JBKR-7NHUJ7!opendocument
"Thanks Mark. It's the comments like yours that have kept me going all this time!"
Jake,
I no longer do hands on work on domino. I am more into websphere portal and its integration and next thing in my plate in coming month is filenet. But I am still responsible for managing team of domino developers and I 100% agree with Mark Roden. I am following your blog for many years and I still open your blog everyday. Thanks for all your efforts to serve under served domino community.
@Nick Hopkins: Sounds like a hack to me and I thought xpages got rid of hacks.
My main problem with xpages right now and admittedly I haven't done the research is the requirement to use the DOJO javascript framework. I hat the HTML editor and prefer other, smaller javascript frameworks.
What about mobile support. If I want my site to be accessible on a phone. Not an iPhone are many of the PDAs, just a phone. If a programmer uses Web Standards and CSS, most of my pages work on a phone, though forms often have to made custom for the phone. Does xpages support the phone?
I am battling with xpages at the moment, mainly because we are trying to use in the Notes client.
They dont work in framesets.
You cant use window.open or close to control the window the xpage is in within the client (these are in 8.5.2).
It really makes me wonder if xpage in the client has been designed and used or if it being added on the fly.