4Viktor Krantz  05/03/2007 10:56:10 PM  What if....you had data-only Web access to NSFs?

I think it sounds like a great idea. If we also could get all this as JSON as well, I would be really happy. JSON was added to everything that you can get XML out of today in Domino 8 (and it slipped in on 7.0.2) and is faster than XML in many situations.

5Peter Herrmann  05/03/2007 10:57:25 PM  Oh yes.. and this is what other platforms let you do

Yes. Agreed mostly entirely. This is what LAMP, ASP/ASPX/SQL and CFM let you do. Know however that you'll freak some people out because you'll remove the data-to-form perspective they have.

1. REST: I think GET and POST are enough to make all CRUD work (look at the big rest players like amazon, yahoo and google).

2. Data level URL commands - YES (needs a mechanism to protect old nsfs where you could url your way into a note's data fields that were previously unreachable due to a $$viewtemplate). A file upload URL command would be great.

3. a) XML for sure. b)what about json as well c)please make a way to get easyXML vs DXL (cause you will sometimes need it but it would be so verbose and ugly)

4. Ajax friendly? good paging, totaldoccounts that honour authors/readers fields, good ways to handle auth failures on timeouts for single app pages(http response codes? maybe it's already OK).

Agent is a good way to access the Response pipeline, what about also on the Request side - it would allow you to do session handling etc.

A Server side transform mechanism sounds great.

I applaud your progress on this - I think Jack Ratcliff and the Extnd team need to chime in and I'm sure they will.

6Rob McDonagh  05/04/2007 12:13:29 AM  Torn

At first, I thought this was a fantastic improvement on Domino. But then I wondered: this almost turns Domino into a database back-end like mySQL (I'm oversimplifying greatly), and while it lets me write whatever code we want on the front-end, it makes me wonder why I should use Domino as my back-end database after all. It would make developing for Domino much truer to modern web development, no question. But what benefits do we get from Domino at that point? Readers/Authors fields jump to mind (directory services, messaging, can be replaced). But isn't an integrated forms layout capability one of the strongest selling points of Domino for development? I know you said none of that would go away, but if this was implemented it seems obvious that enhancements to the html rendering engine would be few and far between. Would we wind up with a form layout engine that was morphing into a layout region, in terms of support from IBM?

There is one thing that would turn this into a no-brainer for me: will the Notes client support the exact same UI the web browsers support (plus composite apps, plus offline capability, plus Sametime/Quickr plugins, etc)? If so, and if I have THAT much control over it, sign me up. Or, wait, haven't I turned the Notes client into Lotus Expeditor at that point? Confused again.....

7Matt White  05/04/2007 3:42:43 AM  What if....you had data-only Web access to NSFs?

@6 - Rob, your point is a fair one, but we all know that you can actually do some pretty cool stuff with Domino HTML as things stand today. If the current level of support stayed static and then Bob's proposed functionality was added on top I think you're looking at the best of both worlds.

This proposal seems like exactly the sort of thing to kick-start Domino HTML for the next ten years to me.

Matt

8Frederic Block  05/04/2007 3:48:11 AM  Seems overkilling

I agree with Andrew, maybe a great idea but overkilling...

Making the HTML engine work better is a short term need...

Most customers are using Notes/Domino as a way to perform (kind of) RAD. What they are expecting :

- Rich text editor must improve (Web side and ALSO Notes side, we are still using the kind of feature since Notes 4, even in Notes 8...)

- Rendering engine has to support Notes / Web editing (everyone knows what happen if I edit a rich text using Notes, then modify it using Web interface and agin in Notes...)

- Customers are expecting not to have to develop a lot of -complex- XML/XSL/... things. They would love to see views being natively doing AJAX (for scroll, search, type ahead,..). Every Domino developer knows it is possible to do it, but it is not simple...

- the same goes for forms were -for example- drop down luist updates would not require reloading the whole page

...

9Thomas Bahn  05/04/2007 4:20:23 AM  What if....you had data-only Web access to NSFs?

This proposal sounds great to me.

Some ideas:

There are (at least) 3 points, where an agent should be able to hook into the cycle:

1st before the request is being handled,

2nd after is is handled, but before the XSLT is applied and

3rd after the XSLT has been applied.

Have a look at the request life cycle in Struts and JSF to get the idea.

Efficiency: think about initialization costs for theses agents.

@2: I totally agree, that the HTML engine should be modified in such a way it generates more "hooks" for CSS, that is classes and ids. Action bar table with id... No more tricking around... :-)

@3: Great idea to use headers for returning state information for AJAX calls. Could be controllable by a URL parameter switch.

@4: JSON would be indeed a good alternative to have, especially for AJAX calls. OutputFormat=JSON should work in there new URL commands.

@5: Do you regularly change or delete data on Amazon, Yahoo and Google? I presume not. But I do these kind of operations in Domino Web applications. Therefore PUT and DELETE (!) would be nice. RESTful services are really handy...

@6: Openness is a value of itself. Imagine, you have an existing Notes application you want to have a web UI for. Wouldn't it be great to be able to choose, which web technology to choose. In most cases it would be a Domino Web applications, but there could be cases, where (G)Rails, PHP, ... would be the better choice. A choice you now don't have.

@8: I agree that the HTML engine must be improved, too. xhtml (getting rid of these font tags...), CSS "hooks", RichText editor, generally speaking more control etc.

I do not think, it would be easy (or even possible) to create a Web application without using JavaScript with these new URL commands. And since on the Internet there should be always a way to use an application without JavaScript (security, mobile browsers, accessibility - screen readers, braille ...), the form-based kind of Domino Web applications shouldn't be comsidered a discontinued model.

Thanks Bob for caring for our needs.

Thomas

{ Link }

10Dragon Cotterill  05/04/2007 5:04:10 AM  Rich Text, Rixh Text.... Rich Text

The biggest overhaul must be the Rich Text renderer. As Frederic pointed out, you cannot run editing on both Web and Client at the same time when it comes to Rich Text. Data is not so much of an issue. But who on earth uses <FONT> tags these days? Can we CSS style Notes forms? Can we embed Apps and files on the web?

The files upload controls in the iNotes stuff is reasonable to use. Where is it? Why can't we use it in "normal" applications? TinyMCE works brilliantly on the web, why doesn't Notes render HTML properly on the Client?

There are still so many things which need to be resolved to make the apps cross client compatible.

11Andy Burnett  05/04/2007 5:37:29 AM  What if....you had data-only Web access to NSFs?

I would love these features and in particular the ability to write a specific data item back into a document via REST. I think it would make the development process much easier for us.

Also, being able to CRUD a file attachment that way would be fantastic.

12Thomas Gamradt  05/04/2007 6:18:33 AM  Don’t make me do double work

Frankly, I don't care about rich text that much. I care about forms. I have quite a lot of nicely designed forms in dozens of databases. All fields have their properties like width and height and font and so on and they are nicely positioned in a table.

Why the ... isn't it possible to just copy these properties to the web engine? If I tell the field that it's 2cm high and 10cm wide, why isn't it the same size on the web?

I don't care if I have to define these properties via CSS or in a properties dialog like we have it in Domino Designer right now, but I don't want to do both!

13Michael Bourak  05/04/2007 7:17:31 AM  What if....you had data-only Web access to NSFs?

I think the REST api for domino is a great idea but ONLY if it complements a major rework of the HTML rendering.

My idea is that we will use rest API for fine grained operations, or to ajaxify a part of an app but we must keep the great RAD advantage of Domino for designing forms etc...please please do not let us fall in the JSP world ...(remember your article "total waste of time" ?)

Not to mention that writing XSLT is extremelly tedious and know to be slow as hell.

I've a counter proposition for you :

What about exposing the way domino renders elements in HTML (a table, a view etc) as some "html fragments" that could be customized by server/database/design element.

For ex, I would say : to render this outline, use this html template which could be a simple "text" file where I could have some domino tags to put domino data.

By default, you ship Domino with an up to date set of "html rendering templates" for all elements but let us customise them by db/design element.

What do you think ?

14Ladonkin Dmitry  05/04/2007 7:31:34 AM  Pretty good but

Dear, Bob

It is pretty good idea, because webdeveloper need to write plenty of HTML code, use much javascript to change data presentation and to implement the same functionality like in thick client. But despite of all those difficulties webdesigner can create more rich and flexible interface.

But may be we dont need backward compatibility. May be it is time to change structure of the Form in Lotus. I want to design forms in which i can change some properties in style sheet and then the border appear around fields.

I want to have ability

- to change cursor over specific fields,

- to change programmatically color of field,

- to catch event of changing content of field after each entered letter

- to evade recalcing whole form very often

- to create some parent field so that some other fields in varios forms in one database inherit design from it

So i want functionality like i have in javax.swing or other flexible technologies

If IBM create such flexible technology it will be very simple to extend this flexibility to Web. And all properties will be able to be set in one place both for thin and thick client

15Nathan T. Freeman  05/04/2007 8:14:33 AM  What if....you had data-only Web access to NSFs?

@2 - So instead of achieving the goal of data only via a REST API, which would instantly be applicable to every Domino application in existence, we could go do design work on every single element in every single application!? Whoopee!

@5 - JSON's pretty cool, but please don't build multiple XML formats for output. DXL is nearly comprehensive, and it's well-documented in the schemas. Sure, some people will want simpler schemas. That's what transforms are for.

@6 - "it makes me wonder why I should use Domino as my back-end database after all" Because it's still be best business logic engine in the business. Can you think of a better tool to manage security and workflow on a given data entity? Heck, if you're implementing DB2NSF, you're already not using Domino as your back-end database.

Dear readers, I know you want a better HTML rendering engine in Domino. You're unlikely to get it in one fell swoop. But what if you could use some other rendering engine for Domino content? The engine of your choice. Wouldn't that be better?

Also, there's no need to rag on FONT tags. They're already going away in 8.

Bob, if you're looking at essentially a ?ReadViewEntries for Documents and Items, shouldn't we also be looking at a ?ReadDesign for forms and pages?

myForm?ReadDesign&OutputFormat=DXL&stylesheet=myXSLT

Man, just LOOKING at that syntax makes me quiver with excitement. ;-)

16Olaf Meyer  05/04/2007 8:18:18 AM  What if....you had data-only Web access to NSFs?

Hello Bob,

I'm almost perfectly happy with the way that domino databases can be displayed in a web browser. Of course there are some limitation, if you use the Lotus Domino web server (i.e. there is always a default form element or a web agent can't return binary data like images). But important for me is, that I'm able to create an application very quickly. These applications are also very flexible and easy to secure. I don't mind writing HTML and JavaScript code, so I'm in control how the form / page is displayed in the web browser. If there is a need I'm able to generate different content types from a Notes form, page or agent.

Kind regards,

Olaf

17Andy Broyles  05/04/2007 8:59:29 AM  What if....you had data-only Web access to NSFs?

Take my response in the nature of the fact that we don't do rich text in web app here.

Other then the automated transforms, what is going to be better then what we have with WQO agents? I guess I am with Andrew Pollack on this one.

In our small shop, we use WQO agents to write XML today; WQO agents to do large volume paging; to generate XHTML; to write CSS psuedo-files (create customized CSS from profile document options that become CSS files to the browser); and all of this is done in the present context of user based read/write securty.

In previous verions, WQO performance was horrible enough that it became a worse practice...now however (at least late v6.5 and 7) WQO performance is on par with similar queries and formatting against a SQL backend. Scaling might be an issue; but does Domino get used in any really high volume sites? Honestly? Wouldn't a site needing scale already be on Websphere?

Our whole site is XHTML 1.0 strict compliant and CSS 2.0...all from WQO agents. Our public site is small,but our extranet works against databases with hundred of thousands of doucments or SQL records.

18Brian Green  05/04/2007 9:32:53 AM  What if....you had data-only Web access to NSFs?

I have my end user hat on today... Please revisit rich text editing in Lotus Notes. Our technical writers use AuthorIT.

{ Link }

Object oriented writing. Single source for images, paragraphs, etc. Reusable content. Rebrand content.

The writers add style tags to words or paragraphs. There are different publishing formats. XHTML, doc, PDF, etc. A different style sheet (look&feel) can be allied to each publishing format. For example, your PDF output might be 2 columns on A4 paper, while the HTML could be 1 column with special fonts.

Lotus should preserve the existing Rich Text and Rich Text Lite data types and their HTML rendering. Create something new & fresh! User friendly editing, valid XHTML, etc., etc.

19Bob Balaban  05/04/2007 9:53:24 AM  What if....you had data-only Web access to NSFs?

Greetings, Geeks!

I was surprised by so many postings so quickly. I have some replies/comments to make....

@2 - You're saying the data-only serving model is easy to do now, with an agent. That's true, if you want to write your own code to transform between XML and Notes data. My idea is that our server does that for you -- at fine grained levels. For example, you query a document's worth of data from the server and render it in your browser app. Then the user edits a field, and you want to update with the change. In my scheme, you get to send ONLY the changed field data back to the server for an automatic update.

Of course, if you don't want to use that mechanism, we won't force you

@3 - I thought that's what I just said

@4 - Viktor, tell me why you like JSON, what are the advantages? Assuming the transform from whatever flavor of XML we pick to JSON is straightforward and not too slow, I don't see why we couldn't provide an optional xslt to do that

@5 - Let's not forget that before the server sends out the XML, we STILL have to apply security and business logic from the form, the way we do now (figure out hide-whens, etc). We're not taking anything away, we never do, so if you prefer building and running your apps the way you do today, you will still be able to do that.

I'm not sure what you mean by "Session handling" on the request side. Can you clarify?

@6 - LOTS of advantages still in Domino: replication, security, rich client, etc. And just to keep you feeling warm and fuzzy, I'll tell you that we consider it an equal priority to do better "default" HTML rendering too. Your fears about "enhancements to the html rendering engine would be few and far between" are, IMHO, unfounded.

Regarding "will the Notes client support the exact same UI the web browsers support?", all I can say right now is STAY TUNED!

@8 - I hear you. As I just said above, HTML rendering improvements are VERY high on our priority list. We ARE going to do them, independently of the XML stuff.

20Russ Mayes  05/04/2007 10:20:02 AM  What if....you had data-only Web access to NSFs?

First, Bob, I want to say I think it's great that you are even asking questions like this. It's akin to what Marybeth has done with the Notes 8 UI enhancements, and I hope it continues.

Not to speak for Viktor, but the real advantage to JSON is speed: it's faster to load than XML (because there is less data) and it's faster to parse. For lots of data, that can be significant. If you produce XML first and then transform, presumably the "faster to load" option goes away.

I'll just reiterate that the easier you can make it for developers to apply CSS to a domino-rendered page, the better. And I love the idea of being able to update single fields on the fly instead of updating a whole document!

21Tim Tripcony  05/04/2007 11:00:53 AM  What if....you had data-only Web access to NSFs?

@20 - We actually have one option for posting incremental updates already: UNID?SaveDocument. When posting to that URL command (via AJAX or standard HTML forms), any fields that you provide new values for are updated, any omitted retain the same value (with the exception of computed fields, which are recalculated).

Anyway, just wanted to echo the sentiment that the ideas you're outlining are a welcome sight. Particularly the REST API (I've been hoping that would be forthcoming ever since seeing Damien Katz's use of REST with CouchDb) and item-specific URL's.

Another reason JSON is typically faster than XML is that a simple eval statement parses the whole data structure into a JavaScript object automatically. Ergo, in Domino's new ReadViewEntries&OutputFormat=JSON, you can immediately just call viewEntries.viewentry[0].entrydata[0].text[0] to get the first value of the first column for the first document in the view. Heck of a lot easier - and faster - than parsing XML output. XML is much more powerful, but JSON is much more lightweight. Offering both is definitely the way to go.

22Gunnar Almas  05/04/2007 11:10:14 AM  What if....you had data-only Web access to NSFs?

I would really like the OutputFormat=JASON to be an option.

At lest when working with AJAX it would be a great benefit.

It is so mutch easier to work with copared to XML parsing

23Jerry Carter  05/04/2007 12:58:40 PM  What if....you had data-only Web access to NSFs?

Matt, Nathan and Tim have arleady said some of what I was going to say (all members of the Ext.nd team) but I wanted to hasten to add that this is something that would really simplify efforts for the Ext.nd framework. If this foundation of data only access already existed, our project would have quite a leg up.

As others have said, other platforms offer this sort of data querying today, which is part of the reason we have identified it as something the framework might use or support (details still simmering on the stove). It's near enough industry standard to merit a serious commitment to add to the domino http stack.

I think keeping the existing is preferable too - backwards compatibility in that way means the change would have no footprint on existing apps - everything would continue to work as is which would be great as hardly anybody has piles of cash to retool their portfolios.

This would be huge Bob. If I as a developer don't have to write an agent to represent the data in xml format as I might need to do today, my job just got easier and even gives me a significant edge over some other platforms when it comes to estimating project effort.

24Erik Brooks  05/04/2007 1:03:49 PM  What if....you had data-only Web access to NSFs?

Bob - ditto what Russ (@20) said -- asking these questions is FANTASTIC!

We are a 99%-web-based Domino shop running one of the most complex Domino web apps out there. Thousands of users hit the application every day - some with FF, some with IE, some behind mega-proxies, some using AOL, etc.

With that in mind, I'm obviously drooling in anticipation of any web enhancements.

Going back to your original post at the start of this thread:

#1 - People who have to "nudge" Domino's rendering:

How many people would actually need to nudge Domino's rendering if it did a fair job of it in the first place? It sounds (hopefully) like the HTML rendering improvments you're talking about will address quite a bit of this. If IBM/Lotus spent some time on table rendering, for example, that alone would be huge. Padding, height, borders, etc. The fact that in 2007 you can set a table border to 1px red and Domino doesn't honor that on the web is laughable.

#2 - People who want to bypass Domino's rendering:

Again, how many people would actually want/need to bypass Domino's rendering if it did a fair job rendering in the first place? I see views as one special case due to the sheer volume of data, but that's another discussion (I'd love a "What if... ReadViewEntries / SearchViewEntries".)

The problem is that Domino's HTML rendering isn't getting the job done for some because in most cases it's rendering in the EXACT same manner that it did *10* years ago (think about that for a minute), and is hard to "tame" per @2.

Get a doc/design element/whatever, render it to DXL, and transform it? You can already do all of this with an agent. And a very small one at that. That side of things really sounds more like an OpenNTF.org project than something that core IBM/Lotus dev should be working on.

But let's explore it for a minute... "But an agent is slow" - Not really these days (per @17), but ok, so hammer it out with the C++ API, and wrap it up as a DSAPI filter. Heck, I bet Ben Langhinrichs could knock that out in one weekend if the DXLExporter and DXLTransformer classes are exposed in the C++ API. Installation would then be a snap: just copy over the DSAPI file, edit your server doc, and BAM. Just like DOLS.

The only thing I could see being potentially prohibitively slow is in extreme cases, e.g. if you only want info about one field from within a very complex form, and you needed that often. That would take a little bit of CPU power to chew on, as you could be transforming/parsing quite a bit of DXL to get after what you want.

Overall, I agree with others that this sounds like complete overkill for the problem, and would just be yet another area that would require more support and maintenance in future versions. It would help people who *integrate* with Domino ("Yay, I don't need to write a simple agent to extract Domino data for my LAMP solution!"), but not so much people who develop *for* it.

If you want to make Domino a "Kick-Ass Dev Platform" again then make the client work like the web and vice-versa. This means simply making browser rendering as close to the client rendering as possible, and vice-versa. That includes CSS capabilities on both sides as others have discussed, and all of the AJAX-y stuff: Views, Dialog pickers, Calendar pickers, time-pickers, rich text editing, spell checking and file uploads. Hmmm... sounds like the DWA widgets! ;-)

25Nathan T. Freeman  05/04/2007 2:10:13 PM  What if....you had data-only Web access to NSFs?

@24 - Erik, I know you well enough to know that if I could talk about ALL the possibilities this introduces, you would literally be cleaning drool from your keyboard.

I don't normally say things like this, but in your case, TRUST ME. If this becomes a reality, you'll love what it ends up doing.

26Bob Balaban  05/04/2007 2:25:42 PM  What if....you had data-only Web access to NSFs?

Ok, picking up my series of comments and responses....

@9 - Good suggestions, thanks! I agree that JavaScript on the browser client will be key to being able to manipulate xml "feeds" from the server. What do you think of Dojo?

@11 - Don't worry, we're not forgetting about attachments

@13 - JSPs are not part of the current plan for this stuff. Your "html fragment" idea is very interesting. Could you possibly email me a more extended example? Would greatly appreciate that.

@14 - We ALWAYS (always!) build for backward compatibility, although we do want to enable the features that you're asking for as well. These hypothetical new "features" that I am describing are in some cases orthogonal to (have no impact on) our current forms model. In other cases they would only be used in new or rewritten apps.

We cannot (and will not) take away anything that is there today.

@15 - ?ReadDesign... hmmm....Well, really, why not? Stay tuned...

@17 - I'm really glad that you're happy with the current capabilities. Rock on!

@18 - All valid points, but I will defer discussion to a dedicated posting on Rich Text

@20 - Thanks for the input. I'm certainly not opposed to JSON in principle, except for the fact that it's less generic than XML. We offer it as an option now, so it's certainly worthy of consideration for carrying forward.

@21 - Kewl, this kind of example is what I was hoping for. Thanks for the lesson!

@23 - Great! Making easier the lives of Geeks around the world is why I come to work in the morning! :-)

@24 - Great input, thanks. Keep the discussion going!

Regarding "how many people would actually want/need to bypass Domino's rendering if it did a fair job rendering in the first place?"

I would say (from hard-won experience) that the answer is "there are always some!" I claim that no matter how much we invest in improving the rendering (and we will definitely improve it..), there will ALWAYS be things people want that it won't have, or do.

So, one of my motivations here is to make people less reliant on our HTML conversion. Sure, it needs updating, and some people will always want to just get whatever the server does by default in a RAD-style development environment.

But what if we (over time...) made it just as easy to do client side rendering of our XML? If you could do it that way, with the same skill set and expenditure of effort, wouldn't you?

I'm not saying that we know how to pull that off today, but in the meantime, we're not going to take away anything we already have, so you can freely continue to use what's there (and yes, we will be making it better).

I understand your (and Andrew's) point about this being overkill, but I don't agree (and I'm seeing in this thread that several people are saying they want/need it). Plus, you haven't heard the full story yet! A "fixed-up" DXL format is something that we would promote for many kinds of uses, not just Web appdev.

Re: "make the client work like the web and vice-versa", well, STAY TUNED!! can't say more yet.

27Erik Brooks  05/04/2007 3:15:58 PM  What if....you had data-only Web access to NSFs?

@25 - Nathan, I've definitely got some ideas about what this could introduce, *if* it's properly extended down-the-road, but when I first started reading this it didn't sound like that was the direction that it was headed.

Now Bob, if all of this "STAY TUNED!!" you're repeating when I say "make the client work like the web and vice-versa" has the internal backing and implications that it sounds like it might, then there is *definitely* some stuff to get excited about.

I'm hoping that your mention of Dojo, combined with IBM hosting their latest dev conference, has some implications as well with all of this. If so, I might be getting *real* excited.

"What if we (over time...) made it just as easy to do client side rendering of our XML?"

Now you're talking! I didn't think that you were considering going that far with it based off of the initial reading, but *that* would be something.

As a one-off piece it's not that impressive an idea, but if there's a roadmap for where I think you're going with it then I'm definitely on-board.

28Dan Sickles  05/04/2007 4:07:56 PM  What if....you had data-only Web access to NSFs?

"a whole new set of HTTP based URL commands"

Bob, I read "new" as not extending the existing Domino URLs but a completely new (in addition to the existing) API. This is what I hope you are talking about. The current domino API is not RESTful.

29Nathan T. Freeman  05/04/2007 4:15:28 PM  What if....you had data-only Web access to NSFs?

@28 - "The current domino API is not RESTful."

It's not? How do you figure? { Link }

30Rob McDonagh  05/04/2007 6:32:15 PM  What if....you had data-only Web access to NSFs?

Bob, we are definitely STAYing TUNEd, don't worry about that! If that hint pans out, there will be some extremely happy developers out there.

My earlier comment (why use Domino, then?) was part exaggeration and part devil's advocate.

I will say that I'm not terribly excited by the idea of writing a lot of XSL. Maybe it's just me, but for anything but reasonably simple operations XSL leaves quite a bit to be desired. But that's just nit-picking about a specific detail. If I can build a UI that works in the client as well as the web, I'll be a happy LotusGeek. And I'll have lots of extra time on my hands, too...

31Erik Brooks  05/04/2007 11:38:46 PM  What if....you had data-only Web access to NSFs?

@30 - Nobody's excited about *having* to write a lot of XSL. But if - down the road - it was spat out for you by Domino in a decent fashion *and* you could tweak it further, that would be pretty darn sweet.

Your devil's-advocate comment ("why use Domino, then?") definitely made a good point. The goal with all of this shouldn't be to further distance Domino development by extending it into some other framework and point "just do it there", but enhance the native functionality so that Domino's RAD capabilities stay top-notch *and* you get some flexibility out of it for custom purposes.

Of course, CPU speeds and browser resources need to play a little catch-up at the moment to get to where this sort of thing (large amounts of XML + XSLT transformed and rendered client-side) is truly feasible. But there will definitely be time for that before RNext or RNext+1.

32Dan Sickles  05/05/2007 12:18:45 AM  What if....you had data-only Web access to NSFs?

@29 - The link you provided GETs it wrong (pun intended). Domino embeds verbs (methods) in URLs. From restFaq: { Link }

"A view among many people who have heard the REST buzzwords is that any use of the HTTP protocol without using SOAP or another RPC protocol on top of HTTP is RESTful. Either by adding arbitrary methods to HTTP or by wrapping up non-standard encodings of function calls they reintroduce the object-oriented RPC style on top of HTTP. REST is a deliberate set of restrictions on Object-Oriented style, and without those restrictions some of the benefits of REST are not realized. "

From Rest Mistakes { Link }

"Do not put actions in URIs"

33Dan Sickles  05/05/2007 12:20:03 AM  What if....you had data-only Web access to NSFs?

For a great Notes-like example, see the couchdb REST API:

{ Link }

See Also:

{ Link }

{ Link }

34Henning Heinz  05/05/2007 11:15:11 AM  What if....you had data-only Web access to NSFs?

I am with @24 Erik. I do consider it a valuable feature and I would probably use it but there are dozens of other things that I would like to have / be fixed first. Some of them have already been mentioned here.

Maybe this is just too much "Theory" for me because my current demands are just not related to data-only nsf access.

35Ian Morrison  05/05/2007 5:45:27 PM  What if....you had data-only Web access to NSFs?

Bob - Before I add my 2 cent's worth, I just wanted to say that this type of contact with the developers on the ground is as priceless as it is profound. Please ensure that this blog becomes legendary - as long as you commit to it, this will inevitably happen. You can be sure that you will have the captivation of us Domino developers around the world.

Anyhow, back at the ranch...

I am all for this type of extended functionality, as there will always be someone somewhere that finds it priceless for their particular purpose.

However, the developer resource for Notes/Domino is limited, and I would hope that this type of "very nice to have" is not at the expense (whether to a greater or lesser degree) of much more important (IMHO) enhancements, such as:

1) Proper handling of custom LotusScript Classes in the IDE.... please, please, please can we have a property/method browser native to the IDE. Even better, can have a separate "Class" script library, with a section for Properties, and the Methods shown separately. Of course, for backwards compatibility and convenience we would keep the ability to use the Declarations section for classes. Classes are great things, but how many thousands of LotusScript programmers would benefit daily from a proper handling of them?

2) Javascript libraries... Why are the functions not separated automatically like LotusScript functions? It is a pain to scroll up and down hundreds of lines of Javascript, and given the ever-increasing amounts of Javascript in Domino web apps as we embrace Web 2.0, this type of improvement would improve the lives of thousands of developers worldwide daily.

3) As mentioned by many, the HTML rendered needs brought into 2007, with clean HTML and using all the modern trickery of Web 2.0. Whilst the experienced web-savvy developers will simply make use of their best friend, passthru HTML, there must be huge numbers of web developers out there that would benefit hugely from a much-modernised HTML renderer.

Apologies for hijacking this blog about data-only Web access to NSFs to bang on about other things on my wish-list, but I feel it is appropriate. I want to see IBM nail the things that will have a massive effect on massive numbers of developers on a daily basis. After that's done, there's time for all the other nice-to-haves....

36Stephan H. Wissel  05/06/2007 6:22:08 AM  It is not only great for end-user computing

Hi Bob,

great idea. I would like to see configurable options. In Designer there should be a tab where the XML output/input options could be defined (like: is there an XSLT to be run before/after sending/accepting data). In the various R5/6/7 Beta databases I made entries about that.

One thing where a XML/Rest API would come in VERY handy is system integration. In a SOA world there could be systems that want to talk to Domino and XML/Rest is well established and has less overhead that SOAP... especially if you don't need to code anything on the Domino side.

:-) stw

37simon letourneau  05/06/2007 12:46:35 PM  What if....you had data-only Web access to NSFs?

First, xslt should never be done by domino but client side. The same result but far more scalable!

Second : there is my personnal view on web2 and domino :

I have built a domino web app using ajax already. My first idea was to have a generic view to xml agent that outputs data in a convenient xml format. It simply pushes an xml to the browser based on some parameters wich includes the name of the view , the category(optional), the page and docPerPage(optional) and a serach(optional). The way I built it, the browser request first (with ajax) only the number of documents the user wnant per page : the first page loads very fast. Then ajax automatically make another behind-the-sceen request to get the whole view (in xml) and caches it. fitlering(per column), sorting(per column), page navigation, collapsing categories : all the later happens without a single request to domino (pure ajax). The general layout is a form and it includes a subform containing the javascript and the html div zones to put content. The good thing then happens: every single domino view is now ajax.

Other good tricks :

1-a javascript function that moves the domino action bar into a menu div anywhere on the page

2-a templating system to isolate presentation

3-an 'ajax-gateway-engine' that evaluates request parameters and dynamically (with Evaluate) call a lotusscript function and returns result (JSON or XML): this enables ajax rpc to existing lotusscript functions

4-a dhtml prompt(playing with div and css(z-index, position...) : where a single code line of javascript can produce a dhtml dbcolumn picklist

5-a default WEB form that generates every field type correctly : dates, numbers, etc.. with a javascript validation. Once this is done, we make every other form by first copying this one and removing or duplicationg fields type.

once those five + viewEngine elements works fine, you can build web2 apps quickly.

My regret was the choice of xml over JSON to pass data from agent to browser because of the burden to marshall xml to javascript everytime.

the best thing would be to have an open-source project that produces a FRAMEWORK in a .nsf that would give those features.

38Thomas Schulte  05/07/2007 4:31:20 AM  What if....you had data-only Web access to NSFs?

One of the core problems while developing for notes and web client is that most of the time you have to develop twice to get results that work perfect both ways.

In an ideal developers world you would develop a navigation form, actionbar, action or view once and it would work the same way if you use either the notes or the web client.

Giving us the possibility to do our own rendering is fine if someone wants to get into the very dark corners of web development. But for me, i am in sync with what Erik said @24. If the domino server would do a decent job of rendering and CSS would work all over the place, there would be much lees need for the other solutions.

Yes they are very cool and yes the technical savvy people will like them much more, but if you look at what would give more people a benefit that would be what Erik said.

39Brian Miller  05/07/2007 10:44:46 AM  What if....you had data-only Web access to NSFs?

Bob (@26),

I personally don't care for Dojo. It's big, poorly documented, tries to shoehorn Java-style OO where it doesn't belong, and slower than dirt. Just trying to *load* the API documentation locks up my whole browser for 15-20 seconds. It carries the potential benefit that Alex Russell may have solved a particular problem first, but I don't think that outweighs the fact that Dojo is impractical to use. And, for the record, I've never seen a Domino developer use it. All the examples of library integration out here in the wild involve the other major JS libraries. The reason for that is probably that no one can figure it out. :)

My preferences for library integration are jQuery ({ Link } ) and, to a lesser extent, Yahoo UI ({ Link }

And, lastly, don't look at Prototype/Scriptaculous - it's a poorly-supported, memory-leaking waste of time.

40Brian Miller  05/07/2007 10:46:20 AM  Reposting broken link to Yahoo UI...

{ Link }

41Nathan T. Freeman  05/07/2007 4:13:03 PM  What if....you had data-only Web access to NSFs?

@39 - Personally, I'd like to be able to just choose my rendering library set with a radio button.

( ) Ext ( ) Prototype ( ) Dojo ( ) DWA

42Richard Collette  05/07/2007 4:57:51 PM  Again with the half complete mentality

I definitely think XHTML, JSON, REST and AJAX (EXT please) need to be implemented but it should be used as a foundation for beefing up the default HTML rendering that Domino provides. Why shouldn't we have drop downs that perform typeahead on the web merely by selecting a property in the designer? If you do it right for that use case, the URLs should of course be reusable for more custom HTML development but PLEASE... focus on making Domino a great RAD web tool. Exposing the raw data does nothing to justify Domino in my environment. I would have no use for Domino since there are other more proficient ways to design a web ui than to manually construct a page hitting Domino proprietary command URL's.

And this gets to another point that I wanted to comment on from another IBM blog. As a developer I would LOVE to develop 1 interface and run it on the web and in the client with no thought as to where it was running. IF you focused on the browser and delivered superb rich rendering, perhaps we could stop worrying about all the faults of the client UI (static, minimal css, etc.) Implement the Notes client as a browser based interface only (using Mozilla or IE, etc rather than building your own) and you free up more IBM resources to do a more focused and quality effort on that single user interface.

43Rob McDonagh  05/07/2007 6:32:45 PM  What if....you had data-only Web access to NSFs?

@41 - Exactly, Nathan! Well, other than the fact that you left off jQuery, my favorite.

What's more, choosing a given library should give you certain defined functionality and widgets and typeahead (can you say "include/use?" Settle down, that's rhetorical...). And adding a new library should consist of defining the syntax and behaviors it supports. Otherwise, it's impossible for us to keep up with the potentially killer next library. Or impractical, at least.

44Erik Brooks  05/07/2007 7:05:51 PM  What if....you had data-only Web access to NSFs?

@35 - RNext will hopefully have Designer-revamped-for-Eclipse, which will bring Domino script editing into the modern world. It may also make Domino extendable to where the Lotus Component Designer can be used as well, which might solve alot of this AJAX debate.

On that note, I would like to throw in something else to chew on with this topic:

Domino 8 is soon-to-be-released, and we're not going to get anything we're discussing here within that version. So we're talking about RNext features which will probably arrive in early 2009.

With that in mind, I would like to maintain that the REST API by itself is only a minor change within the Domino development scheme, and more beneficial for integrators, e.g. @36. Only with the addition of Domino-self-generated View Dialogs, date fields, etc. via highly improved HTML (or XSL that renders the aforementioned XML) will Domino's RAD capabilities be maintained. And if that doesn't happen until RNext+1 (2010/2011) things will be in pretty bad shape.

And on an AJAX-related note:

My company built and deployed a Domino AJAX view-applet replacement over 2.5 years ago. It's been in-use since then by thousands of *internet* (not intranet) users, and has been working flawlessly across IE 5.5+, FF 1.0+, and NS 6.1+, including AOL users and financial institutions behind ultra-heavy proxies, firewalls, over ssl, etc. It has also been used with literally tens of thousands of *user-designed* views. It's one of those things that "Just Works (tm)".

No ActiveX or Java is used -- it's all JS. All CSS-able, including placement and use of "Next Page", "Previous Page", etc. It fully supports categorized views, "Starts with..." functionality, "Restrict To Category", etc. etc.

About the only thing it doesn't do is (1) Formulaic column colors - which would be easy to add, and (2) let you open multiple non-nested categories at the same time - which would be *really* simple if ?ReadViewEntries&Expand supported multiple arguments, e.g. &Expand=1.1,1.2,1.3.

It's fast and lightweight on the server, using only ?ReadDesign and ?ReadViewEntries calls.

Bob, I'd be more than happy to e-mail it to you if you would like. Heck, we'd give it to IBM if it would help AJAXify Domino.

Anyway, I've been looking long and hard and keeping tab on the various rendering libraries out there. Here's my $0.02:

Dojo 0.4.1 (the current version) is pretty bad. Hopefully the 0.9 and 1.0 revamp/re-release this summer will consolidate and document things. It has some nice architectural design philosophies for 1.0, which if they follow through should make it a decent toolkit.

Prototype/Scriptaculous I know the least about, but I would have to agree that on first glance it's memory-leaking and pretty rough.

Ext looks pretty nice, you can choose your framework, and the fact that you can throw down for a $$$$/year support contract is encouraging. They have an active forum with lots of developer/customer feedback as well.

And then there's DWA - obviously battle-tested, supported, and in-production. The dev team knows just a *bit* about integrating with Domino, too. ;-)

Being able to choose our rendering library would be great, but I wonder if that would be cost prohibitive from a Lotus Support viewpoint. I'll take one integrated, maintained, *supported* library from IBM over anything from any of these other companies. Though if IBM checks out ExtJS and really likes it, they could potentially buy them (or a license), and it wouldn't break my heart. :-)

45Rob McDonagh  05/07/2007 8:21:29 PM  You say po-TAY-toe, I say po-TAH-toe

@44 - Hey, if the whole US government can't tell the difference between an N and a Q, what does it matter if the rest of us cross up an A and an R... *snicker*

/Well, actually, I say poTAYtoe, too.

46Nathan T. Freeman  05/08/2007 7:41:50 AM  What if....you had data-only Web access to NSFs?

@46 - Erik, Prophet was using AJAX strategies before they had a name.

If you want to contribute your view code to a project, why not send it to the guys working on Ext.ND? jack.ratcliff@gmail.com

I'm not sure why people think having a REST data API is a separate effort from implementing an AJAX framework into Domino's HTTP rendering. It's a necessary component to get there. Without a comprehensive data API, how would any framework ASYNCHRONOUSLY get XML?

The key thing is for Domino to ultimately separate data and presentation processing. That's the Achilles Heel of the process today, since at a document/form level, we don't draw any distinction. I proposed using XML-retrieval as a way to separate those out in 2002. { Link }

If you want the killer RAD generation for Notes-based design, you first have to filter out the generation for Notes-based data. Then we'll have a basis remaining for how to handle design-only processing, just as we already have ?ReadDesign for views.

47Tim Tripcony  05/08/2007 10:13:30 AM  What if....you had data-only Web access to NSFs?

The benefit I see in "exposing the raw data" is that, with an average of two years between major releases, and each release alternating between a focus on the client and a focus on the server, there is absolutely no way that the default rendering can stay current. Four years ago, there was no "Web 2.0". Did not exist.

But the more powerful and flexible the API - no matter its age - the more easily each of us can leverage current tools and techniques to create modern, usable, even impressive interfaces. When everything is rendered for you, you're stuck with what you get, even if that happens to be amazing when it first arrives. Sooner or later you're going to have a customer (internal to your organization or otherwise) with very specific interface requirements. Rather than tell them, "sorry, this is what IBM gives us, so that's what you get," if the data itself - with no preset visual abstractions - is easily made available to us, then we can plug that into whatever client-side framework will most fully address our customers' requests. That's how we'll truly keep up with the rest of our industry... not by asking IBM to make every possible interface characteristic a checkbox/drop-down setting in Domino Designer.

48starrow  05/08/2007 10:16:32 AM  What if....you had data-only Web access to NSFs?

Yeah, the incapability of the domino web engine is what I've been complaining and heard.It should be revised to emit more elaberate Html, a direct access to data via xml is a wonderful complement.

49Dan Sickles  05/08/2007 10:54:47 AM  What if....you had data-only Web access to NSFs?

@46 - Good point. With a clean separation, tools can evolve independently and layers can be added as neeeded.

On a differnt subject, It's very interesting that Sean McGrath uses Notes as an example of a powerful tool in "A little knowledge is a dangerous thing" { Link }

50Philip Storry  05/08/2007 11:04:18 AM  What if....you had data-only Web access to NSFs?

Whoops. A little late to the party...

But yes, this would of course be of interest to me. :-)

It's actually probably more work than I was thinking of when I last left a comment around here, but to be honest if it's well-implemented I'd happily do more work knowing that I have a proper, flexible interface that can do many things well rather than one thing kludgily.

:-)

51Erik Brooks  05/08/2007 12:09:18 PM  What if....you had data-only Web access to NSFs?

@47 - You hit the nail on the head for where this can go. Strategically speaking, exposure of design elements (and granular pieces of them) via XML is huge. If IBM pulls this off, it could easily give Microsoft and .Net yet another kick-in-the-teeth. It would be open, it wouldn't be ripped-and-replaced, and it would (naturally) be heavily cross-platform-compatible.

I'm mostly playing devil's advocate at this point. I'm in a lucky (unlucky?) subset of Domino developers where 95% of the time I'm *not* developing for the Notes client -- just the web. And almost never do I care about building something that will be used simultaneously in both worlds.

I would gobble up form fields exposed as XML in a heartbeat.

I think the hangup that people are having with the idea of a REST data API is that it *alone* from IBM will make them say "big deal."

What people want is the end-result - most don't care how they get there. People want to create a Date/Time field and have Domino generate HTML/JS that doesn't allow somebody to type in "I ate cake today". They want "Input Enabled" formulas to work on the web. 95% of the Domino dev users wouldn't *need* to be able to override a form's HTML rendering if a form they created simply looked and worked the same on the web as it does in Notes.

These people cringe when you say "Notes and the Web" because they are performing double-duty, creating entirely different forms, subforms, etc. strictly to handle *layout* issues (tables anyone?) from client-to-web. And that's where (I believe) most people's time is spent.

I think that, if we had such an API, those of us that could (and would be excited to) do the integration gruntwork ourselves would be in the vast minority. I believe that the true value for the bulk of Domino devs, who hate to "roll their own", will be realized only when it's extended down the road by IBM with a fully *supported* rendering library.

52Kerr  05/08/2007 1:12:47 PM  What if....you had data-only Web access to NSFs?

Does anyone actually develop (or do orgs request) applications that have full parity operation on both web and notes client? Do they have too much money? Typically the stuff I build ends up being hybrid where certain user functions are carried out on the notes client and others on the web, usually administration and super control in notes and normal user on the web. If my business told me they wanted full parity for both clients I'd tell them it would cost twice as much and they'd tell me to forget it.

It's a nice idea in theory, but the model on the notes client is too different from a web browser to make it really work. Of course if you could make the notes client behave more like a web browser, then you might make some head way. (Nathan will now jump in with a link to a bunch of scary Notes client code that makes it look and feel just like a web browser)

Coding good web apps for Domino is a pain. You can get a lot for very little effort, and the security handling is great, but when you want to step it up a level, you start having to work around Domino instead of working with it. Bob's suggestions here sound like a good place to start making the situation better.

53Nathan T. Freeman  05/08/2007 4:23:49 PM  What if....you had data-only Web access to NSFs?

"Nathan will now jump in with a link to a bunch of scary Notes client code that makes it look and feel just like a web browser"

SCARY!??! LOL I always though my client code was like the Care Bears. ;-)

@51 - You're starting to see where I'm going.

54Jack Ratcliff  05/08/2007 9:39:57 PM  What if....you had data-only Web access to NSFs?

First on my list would be ?SearchViewEntries. ?ReadViewEntries has been great for domino web developers and has allowed us to take the xml output and pass thru xsl or plug into frameworks with advanced grids (my favorite being the one from Ext). However, not having a native way to return the results from a view search in the same xml format means developers can't leverage their view generating code.

Second on my list would be to beef up ?ReadDesign for views. Currently, its missing the view name and alias, and more importantly, it's missing the information for view actions. The only way you can get this information is thru the DxlExporter class. We shouldn't have to do this extra work. At least I don't want to. :)

As for forms and documents, if you could give us an http command to get this data while still honoring hide-whens then that would be the ultimate and I think would satisfy those who have been opposed to unid?ReadDocument.

As for frameworks, I've used Dojo, prototype/scriptaculous, and Ext. In my opinion Ext is the best and thus the reason I'm working with Nathan and others on a Domino version of Ext called Ext.nd.

55Thomas Schult  05/09/2007 1:50:04 AM  What if....you had data-only Web access to NSFs?

What Kerr said @52 and Erik @51 summarizes it pretty much.

My organisation is one of those who needs to have applications working both sides with at last 95% common functionality.

Well if you consider portal three sides.

So the developers have the pain of doing every single development two or three times and if domino would do HTML rendering better we could cut our production time a lot.

56Martijn de Jong  05/09/2007 4:44:53 AM  What if....you had data-only Web access to NSFs?

The great thing about the Domino rendering engine has been of course that it made it easy for developers to quickly make web-enabled forms and pages. The biggest problem I usually have with Domino's rendering is usually that you can only choose to let it render everything or nothing. There's no in between. Some granularity there would be great already like an option per field to render that field (rich text field) if the rest of the form should not be rendered.

57Mark Vincenzes  05/09/2007 3:40:44 PM  What if....you had data-only Web access to NSFs?

@15 The FONT tag is still used in domino 8.

I have a prototype implementation with a bunch of options

that you can provide to cause the web engine to render

rich text font information without the font tag but

it isn't in 8.

Maybe 8.0.1...

58Nathan T. Freeman  05/09/2007 4:07:47 PM  What if....you had data-only Web access to NSFs?

@57 - Oh, man... that's terrible news. :-(

Well, at least it's in-progress. Sorry for the misunderstanding.

59Samuel deHuszar Allen  05/09/2007 5:44:19 PM  What if....you had data-only Web access to NSFs?

I'm fairly low on the Domino developer's learning curve and am much more of a straight web-designer who dabbles in Domino for his own business and a few select clients, so if this sounds wildly unrealistic, please say so kindly/gently.

...but doesn't it make sense to just build hooks into a modern web engine that already does all this stuff? I don't know, say - Apache? It's open-source, clean, stable, etc. It seems like it would be much easier to build new connections to a fully functioning stable project with tons of momentum then to rebuild an old wheel with tons of dependencies that hasn't been modernized much at all in many many years. Relegate it to an install option for legacy support for those that need it, move on to more open-standards as IBM likes to rightly trumpet.

As for the Rich-Text object conundrum, again there's already a mature, well-documented solution that's already XML based, has tremendous stylesheet layout capabilities and can store objects as attachments, and is cross-platform... OpenDocument format! Since the 8 client is incorporating an OpenDocument suite, and the development hooks to access the open-document model from a Notes/Domino programming perspective are being developed as we speak, why not just build new bindings for a framework that does everything we'd like to be able to do NOW and leave Notes Rich-Text object support for legacy DBs?

Too simplistic? Too much work involved? This is "In Theory" after all, is it not?

60Todd Phillips  05/10/2007 12:18:05 PM  Two Cents...

Any and ALL enhancements to the Domino Web Engine would be extremely welcomed on my end. My primary strength is forcing Domino to do things on the web that it doesn't really want to do. I say move forward with this 100%.

In R5, Domino got some much needed attention to the web side of things. I think it's time for even MORE attention.

Cheers.

61Bob Balaban  05/10/2007 2:28:03 PM  What if....you had data-only Web access to NSFs?

Greetings, Geeks!

Finally catching up with my replies to the postings of the last week or so...

@27 - Erik, excitement is good! I can't say much more about it right now,

as internal discussions are proceed apace. Can we pull it off? I hope so!

@28 - I'm talking about a new set of URL commands that follow the REST patterns.

As usual, EVERYTHING that we alreay have continues to be supported....

@30 - I understand your point, Rob. Of course people don't want to be forced to write

a lot of XSL. So we really (really!) intend to dramatically improve the way we produce HTML too.

But I'm thinking that data-only feeds are STILL very useful for Web apps that might want to

pull specific data for various reasons, AJAX-style. Scott Good showed me some kewl applications

of this technique (name type-ahead, indexing into a table and reading N entries, and more). I

believe it to be true that not EVERYTHING you want to get from the server should be in HTML....

does anyone disagree?

@35 - Hi Ian. Wow, I hardly EVER get accused of being "profound"!! I'll have to try it for a

while and see if I like it :-)

Regarding your other suggestions:

1) I hear the request for a LS class browser about every week. I myself have often wished we had it.

Believe me, there is a widespread awareness in this building (where I work for the daylight hours)

about this.

2) JavaScript libs, also heard frequently.

3) Better HTML - yes, we have to do this.

@37 - Re: client-side vs. server-side XSLT -- personally, my goal would be to support both, and let

decide what you want to do on a per-application basis.

Re: your other "Web 2.0 tricks", thanks for posting! These appear to be very clever, and I'm sure

very useful. My comment would be that it sounds as though you had to go to significant trouble to

implement these techniques -- I want to be able to let you get the same (or better) results, but

with less work.

@38 - Yes, Thomas! Single-source design is one of my big goals. Unfortunately, it will be

rather difficult to achieve. But I have some ideas! (Just not quite ready to talk about them

publicly yet)

@39 - Since Dojo (and virtually every other browser based "framework") is just a pile of JavaScript

code in a file somewhere, I'm morally certain that, whatever we deliver in Domino, you wlil be free

to not use it, and to use something else instead.

I am not qualified to pass judgment on the relative merits of Dojo vs. other packages. I do hear

that it has some good visualization and other functionality, and I know that there is a team here

at IBM developing contributions to it (which means I have a shot at getting really good internal

tech support if we adopt it!). But no decisions have been made yet, either way.

@46 - EXCELLENT points, Nathan! I couldn't have said it better myself. Well, perhaps I could,

but I would need many, many more words than you used :-)

Separation of data and UI - ABSOLUTELY the point.

AJAX - you cannot do AJAX if you can't get the right granularity of data feed

Meta-data -- Yes, people need descriptions of forms and views too.

@47 - Precisely!!

@54 - Good suggestion, thanks!

@59 - ODF is a great format for word processors and spreadsheets, I'm not real convinced (though

I am still very open to discussion about it) that it's suitable for Notes rich text.

But don't worry, I will bring this up again when I do my "What if...." posting on rich text

62Mike VandeVelde  05/10/2007 6:29:09 PM  What if....you had data-only Web access to NSFs?

All this stuff sounds super, but I would be more than happy with some much simpler things. Like <input type="file"> - why does that need to be so weird? I'd like to code my own, give it the same name as a rich text field, and have the file show up there as an attachment.

I don't really use the default HTML rendering at all. I roll my own stuff almost 100% of the time. Set content-type to HTML on a Notes form and code away. Use subforms to cut down on the work and Notes fields to hook into the back end. For fancy stuff I write LotusScript agents that spit out HTML. I wrote this bit here:

{ Link }

And I would be more than happy with a few LotusScript extensions to help me make it better:

NotesView.AlternatingRowColor

NotesViewColumn.IsTotal and/or NotesViewColumn.TotalType

So beaver away on the next big step, sounds awesome, but please don't let it slow down making minor improvements to things the way they are! I'm just not quite that deep into it to have much to say about the things being discussed here, so I guess that's it. Thanks!

63Brian Miller  05/11/2007 10:20:52 AM  What if....you had data-only Web access to NSFs?

Bob (@61),

Of course I'm free not to use Dojo. But, I have this sinking feeling that I'll be forced to download it anyway. And, its presence may well interfere with other JS libraries.

But, if IBM is contributing, then it looks like the decision *is* made after all. I'm just displeased that they bet on the wrong horse, so to speak.

At the very least, I'd like a design element-level checkbox for "enable/disable dojo integration", if I need it.

64Michel Van der Meiren  05/13/2007 4:43:18 AM  What if....you had data-only Web access to NSFs?

Thanks Mr. Balaban, for this very inspiring post!

Making an Ajax single page interface to a Notes database can already be done with Domino, from version 6.5 onwards: the views are available in XML format and the documents can be rendered as content-type: text/xml. JavaScript can be used to transform the XML with XSL into HTML fragments and insert them in the page. You don't even need heavy Ajax libraries nor LotusScript to do that. I am currently making a POC of this and explaining it on my blog.

65Nathan T. Freeman  05/24/2007 4:34:28 PM  What if....you had data-only Web access to NSFs?

{ Link }

66Pejman  05/28/2007 7:30:14 AM  What if....you had data-only Web access to NSFs?

Having the possibility to intercept the request processor would be nice :

- checking rules (cookie - app or session variable)

- controlling the app flow (forward, redirect, handle exceptions...)

- add more login in a Domino app

67Tan Seng Chye  05/29/2007 3:17:31 AM  HTML ID for all Domino Elements

Dear Bob,

Domino Web Development can be much more trendy & powerful if we can have HTML IDs for all Domino Design Elements.

Up to now, many Domino design elements, action bar, actions, embedded views, embedded editors, etc. do not allow HTML IDs. For sections we have IDs that are auto-generated by Domino & not according to Section Field Name.

When there is no ID, web developers are unable to improve these elements look&feel with CSS and have to work with the static & old fashion-looking presentation provided by the Domino HTML Engine. Of course there are work-arounds with additional DHTML. However this makes designing Domino Web Application messy & involves many tweaks.

For example, today (the default) Action & Action Bar presentation is definitely unappealing. And I still see many NSF applications still use them because they don't have a better (maintainable) choice to turn to. With HTML ID, developers only require some CSS to make the Action bar & Actions look great or float at the top of the form(something many would love to have).

In addition HTML ID also provides more programmability to the Web Interface. Something Web NSF is losing out when being compared with outer languages or products. I'm referring to Web NSF without the additional tweaks & tricks.

Bob, you have my full support for a Domino Application that Kick-Ass.

68Bob Balaban  05/29/2007 8:18:13 AM  What if....you had data-only Web access to NSFs?

@67 - I agree with you. We are seriously investigating some options in this area - microformats, RDFA, etc.