Disclaimer and License

Opinions expressed here by Tim Tripcony are his own and not representative of his employer.

Creative Commons License
Tip of the Iceberg is licensed under a Creative Commons Attribution 3.0 Unported License.
Based on a work at timtripcony.com.

Unless otherwise explicitly specified, all code samples and downloads are copyright Tim Tripcony and licensed under Apache License 2.0.


« Travel advice | Main| Baron Wasteland »

Web-based IDE for Domino

Category xided
A project soon to be added to OpenNTF is a web-based IDE for Domino. The back end will rely heavily on DXL, which will handle the presentation of existing code as well as creation and modification of design elements. Before I start the project, however, I'd like your ideas and advice for a few aspects of this.

But first, for those of you who have asked for an update on the move, job, etc.:
- Yes, Laura will be joining me. We haven't worked out all the timing just yet, a lot of which hinges on the sale of our current home. But she's staying at least until the 17th, since that's her last day at her own job.
- No, we're not buying a house out here right away. We're looking at listings to get a feel for what we would like to buy when the time comes.
- Yes, I'm liking my new position. I won't say much about it for now, other than that I'm going to be playing with some cool stuff and working with great people.

Now on to my plea for advice. I got the idea when I first saw DXLPeek, because it seemed to me that once you're in a position to view the design of a database from a browser, the next logical step would be to develop a way to modify it. That's a rather Gordian next step, however, so I've just let the idea simmer since then. But the last week alone has given me three distinct reasons for wishing I could make design changes to a template without even having Domino Designer installed. And the easiest way I know of serving functionality without installing software (unless, of course, you count Java applets, ActiveX controls, etc.) is a web application. Like many other folks, I'm stoked about Domiclipse, but despite the bells and whistles it promises, it still requires software to be installed and configured to one's liking - not only Notes, but Eclipse and the Domiclipse plugin. But imagine if you could waltz into any internet cafe and fix a problem with some agent that isn't doing what you thought it would. Even without type-ahead, that kind of flexibility would be invaluable to me (and, perhaps, to others as well).

So now you know why I want to do this... but what advice am I looking for?

1. What should we call it? I've always found that a concept matures more rapidly and cohesively once it has a name. When the most concise description available is a paragraph or even a phrase, the idea remains nebulous, but give it a catchy name or acronym, and it takes off. I don't fully understand that phenomenon, but take AJAX as an example: the technology isn't new, and the approach itself has even been used by some for years. But somebody coined an acronym for it, and suddenly everybody's on board. So I want a name. I described my idea to Steve, and a few seconds of free association took us from "web" to "spider" to "Shelob". Let me know if you think of something that could turn this idea into a household name. Well, technically not a household name... but you know what I mean.

2. What should our goals be? My plan is to build it directly on top of DXLPeek, since their GUI is already pretty intuitive and they've already laid a foundation for extracting the design information. My guess would be that the easiest bit to tackle next would be to allow any LotusScript code to be modified, primarily because:
a. it's a cinch grabbing LotusScript routines from exported DXL
b. presentation of the code in editable form could initially be as basic as a separate textarea for each routine
c. assuming there are no %INCLUDE statements referencing files that aren't available on the Domino server (i.e. lsconst.lss would be fine, but other files previously compiled from a client machine would likely not be current or even present on the server), signing a design element that has been overwritten by importing the modified script will compile successfully.
But then what? Is that functionality enough to make this a worthwhile tool, or should we go further? I suspect that certain design elements, such as views, outlines, and shared actions could be handled similarly, perhaps with a parent/child form-based approach: a parent document would define a view's properties, for example, with response documents handling the definition of its columns. But what about editing forms and subforms? One idea I had was to build a rich text editor similar to (and, more likely than not, derived directly from) one of the many that are in common use today, such as FCKEditor, HTMLArea, etc., but instead of being designed to convert between rich text and HTML, it would allow GUI manipulation of elements from the Domino DTD. In other words, it would support not only tables, bullets/numbering, formatted text, and the like, but also the creation and definition of fields, hide-when properties, and so on. The trouble is... for the time being, such an undertaking is, frankly, hopelessly out of my league. Or I assume it is, since I haven't done any analysis on what would be required. If this were done, however, this tool could function as a pretty decent substitute for the Designer client. One other piece I haven't the foggiest idea how to handle, though, would be Java... how would you compile Java agents and libraries? Maybe there's some way of tapping into Domino's JVM from a WebQuerySave agent, but if there is, I'm not aware of it. If you are, I'd love to hear about it.

3. Finally, compatibility. What browser(s) should this support? Jake's article on XUL Domino views got my wheels turning. At the time, that approach seemed like the perfect way to structure this tool... but then I remembered that XUL isn't implemented in I.E., and from what I've heard, won't be in the foreseeable future. In contrast, DXLPeek's GUI doesn't appear to be functional in Mozilla, so if we start with it as the basis for this new tool, it will initially only support I.E. And, since my whole motivation for wanting to build this is to be able to sit down at any computer and write code without installing anything on it, while Firefox may be the browser of choice for us geeks these days, it's not on most PC's., and I.E. is. On the other hand, Macintosh users have long been waiting for a Designer client... so perhaps Safari compatibility would be an appropriate goal.

So mull that over. Let me know what your thoughts on this are.

UPDATE: This idea later evolved into XIDED ("XML IDE for Domino").


Gravatar Image1 - Interesting project!

Gravatar Image2 - Sounds cool!
Let me know if I can help in any way.