|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
Please chime in on this one, as I know it’s a heavy topic in Westford as well. A very smart friend of mine has a concern about XPages. I think he’s wrong. More specifically, I think he’s making an origami mountain out of a map around a molehill. Even if you normally just ‘lurk’ here, I’d like to see as many people chime in here as possible.
Here’s the issue as my friend sees it:
There is not any 1:1 relationship of an XPage to a specific document. There may be zero, one, or many data notes or other kinds of data sources associated with any given XPage. In fact, that’s a good portion of what makes an XPage different. To me, that’s the most important distinction. The XPage is a layout definition which references data. It can also be used to create new data on submit.
Because XPages are web only for now – at least initially (Maureen has now stated that they’ll work in the client, just maybe not in 8.5) – if you were to click submit on an XPage in the web browser, then go look for “IT” in the Notes client, you’d have nothing to see. The XPage may show up in some views depending how your bindings are set to store data (particularly if you are able to set the XPage itself as the place to store data), but there wouldn’t be any way to just click on it in the Notes client and see the content. Indeed, there may not be any content if all your data bindings are to other documents.
If you did store your data on the XPage itself (for now, I don’t see that as a good idea most of the time, but there may be uses for it if it ends up being allowed by the designer) you would need to set up a field called “Form” and give it the name of a form, then also define a form to show those data elements. Failing to do that, or failing to define a “default” form with the data element names you would want to see, would produce an error in the UI like “Cannot locate default database form” or some such.
My answer to this was twofold. My first answer was “Duh?!?” as in “Yeah, that’s what I’d expect. It would be just as if an agent created a document without a form field on it. We deal with that all the time.” My second answer is “So, what is your big issue?”
My friend seems to think that this will confuse the Notes developer community and is a very bad thing. I just frankly don’t agree. It may confuse a few people at first, but it just isn’t that big a leap to understand and it isn’t far from things we are already dealing with all the time.
So what do you think?
A) You think this is a real problem, and XPages should be held until they work exactly the same in the Notes client as in the Web browser, even if it meant delaying a major release of the product. That’s not going to happen, by the way, but it would be interesting to know if you think that.
B) You think it’s a big enough problem that Lotus should work around it by creating an automatic default form which simply shows the contents and field names of all the data items on a Note if no form can be found to match that note.
C) You think it’s a problem that will significantly hinder adoption of XPages, but that no workaround should be provided and people will have to get over it.
D) You just don’t see how this is that big a deal, and you want XPages as soon as possible.
Personally, I’m fully in the “D – Not a real concern, give me XPages as soon as possible” camp.
Please wait while your document is saved.
doing exactly what it does now with a document without a form, either use the
default form for the database or give an error.
In other words, if I have an XPage, it should have a name, and if that name is
"Foo", the Notes client should look for a form named "Foo". If it exists,
display the Xpage with the data on that form. If not, look for a default form,
and use that. If there isn't a default form, use the same error that exists
now if there is no default form. Part of the advantage here is that it
degrades to exactly the behavior we would expect when viewed in a previous
version of Notes, such as Notes 7. In Notes 7, the item in the view will be
assumed to refer to a note which will act as above.