Oh the HUMANITY!!!
I was having a discussion with some colleagues recently about the Design tab for XPages in IBM Domino Designer 9.0. This visual editor, while useful in certain limited situations, is also the source of any number of problems in Designer itself. The most important thing to know is that the visual rendering is highly responsive to everything happening elsewhere in Eclipse. For instance, if you’re typing a new URL as the source for an image on your Xpage, the visual editor is checking whether it can resolve the URL on *every keystroke,* even when those keys are being press while the cursor is in the Source pane.
Consequently, this means that the Design pane has a lot to do with bizarre Designer behavior, and if IBM allowed us to get rid of it and deal only with Source, then we could have a much more stable and performant XPages Designer experience. Of course, you can accomplish something similar by switching your default editor in Eclipse to use the standard XML editor for .xsp files, but then you’ll lose access to the Properties and Events views that show up for various Xpages components.
In the conversation, I made the assertion that for applications of any sophistication, the Design pane becomes useless, simply because it tries to present such an overwhelming amount of visual information. To illustrate this point, I have compiled a screen shot of the mobile.xsp design element from the Teamroom template in Domino 9. It’s over 8900 pixels long. I cannot imagine any circumstance in which navigating a design of 8900 pixels would be useful. Maybe if the editor had very good zoom in/out controls, but the Xpages editor clearly doesn’t.
This is a visual representation of an XML tree that creates an enormous amount of work for the CPU with a result that seems somewhat less than useful. I can accept that there’s some learning curve for Xpages that this visual editor helps with. But that curve, while steep, is also short. And once a developer has climbed it (in about 30-60 days) they really should be able to turn off this needless burden on the performance and stability of their IDE. Just a right-click on the Design tab and a “hide Design tab from XPages editor” would be sufficient to trigger a disconnection from the text editor to the visual editor.
Alternatively, we could get a new editor that extends the standard XML editor (including it’s “design” pane) but also binds to the property editors that we see in normal Xpages. Thanks for reading!
The Rabbit Hole 
Ironically, despite how hard it tries to keep both tabs in sync, it frequently fails, causing code to be simply lost unless you’re paying close enough attention to the Source tab to notice the disconnect, copy the ghost code, close the editor, open it again, and paste it where it ought be. Furthermore, even when the code is correct, the visualization is often a misrepresentation of the actual component tree. I have a mantra when mentoring developers… to paraphrase Obi-Wan Kenobi: “the Design tab can deceive you; don’t trust it.” Developers coming primarily from a non-Domino background take that mantra to heart quite rapidly. They know that WYSIWYG has always been a crappy way to write good web apps. Domino developers, however, have relied for so long on the visual editors for forms (and subforms), views, and pages — since the only structural alternative was to hand-edit DXL, which they were warned for years was dangerous — so it’s typically instinctive to treat the Design tab as the primary development context, and the Source as merely an approximate representation of the page structure. The moment you realize that this is precisely the opposite of the truth, “you’ve taken your first step into a larger world”.
makes you wonder if these are the reasons Microsoft dropped the design pane from Sharepoint Designer
Editing XML source is soooo 90’s
There are times the designer page can help find an error such as a misplaced tag. It would be nice if they made it a manual refresh instead of automatically.
I find the outline is somewhat useless especially when you have HTML tags on the page. If it worked correctly and should all tags, then it would make it easier to edit the source.
At least make DDE faster, easier to find errors and a real context sensitive help like Notes had.
Could this be simple and easily solved with an option for “computed custom control” like we had for computed subForm – it would indicate it was there – but not “load and draw” anything?
I think Marky is missing the fact that you can use Design definations to act as GUI place holders. I use them for Mobile control apps. That’s a must for performance.