Thu 18 Feb 2021
Getting the point(s) across with Domino, O365, and Outlook365
Mon 15 Feb 2021
Exciton Boost 4.6.3 released
Mon 1 Feb 2021
Why AREN'T layout regions rendered to the web?
Fri 20 Feb 2009, 08:13 AMTweet
by Ben Langhinrichs
Yesterday, I set out to render layout regions to the web, and I have to say, I am more confused than ever. The big advantage layers seemed to have over layout regions was that they were supported on the web, so I assumed (I know, I should never do that, especially with IBM) that there was some major reason why layout regions were not supported on the web. It took about three hours of work to add basic support for layout regions to iFidelity, and thus basic support for rendering layout regions to HTML. Sure, there are minor issues to be resolved, but I am now more mystified than ever. Why continue to support layout regions, but not provide a simple translation to allow them to work on the web? There are reports that layout regions are slow, which may or may not be true, but the rendering to the web is very similar to that used for layers, and certainly wouldn't be slow there. If layout regions are in the product and have continued to be supported for the past ten years, why would IBM not at some point enhance the web engine to support them. That would allow customers to choose (and I have to say, I don't see such a ground swell of use for layers that they are the "only real choice"). There are some things that are far, far easier to do with layout regions than with layers, so why both refuse to truly deprecate layout regions and also refuse to support them in browser applications. It just doesn't make any sense.
Having said that, does anybody have an old (or new) database that uses layout regions extensively so that I can test the rendering a bit more. I am also tempted to write a ConvertLayoutToLayer method in Midas that would convert the layout region itself, as well as the layout fields to regular fields, and layout buttons to regular buttons, and so forth. That would allow people to use the complex layout regions they have developed in the newer technology, but also to design layouts with the layout region UI and convert them rather than trying to start with the cumbersome layer technology.
Copyright © 2009 Genii Software Ltd.
What has been said:
792.1. Craig Wiseman (02/20/2009 06:01 AM)
My perception was that once the decision was taken that WAS was IBM's web platform, the web-side of Domin went into cryogenic freeze. Web support for layout regions were on the to-do list and that list was frozen into "support mode-only".
792.2. Ben Langhinrichs (02/20/2009 06:08 AM)
@Craig - Perhaps a thaw is in order...
792.3. Kevin Pettitt (02/20/2009 06:32 AM)
Very interesting. On the one hand, I could see a nice little niche market for a "Layout Region Converter" of some sort, which wouldn't necessarily have to render the end result in a cosmetically identical manner since the headache comes more from having to recreate all the fields etc. as "normal" fields etc. If you did try to preserve cosmetics, then the question becomes much more complicated since I've seen layout regions where fields are stacked 5 deep on top of each other and key off hide-when formulas (Note Firefox thinks Formulae is a misspelling...hmm).
I almost think the most useful output would be a table where the layout element (field, label, button, etc.), it's field type if applicable (CFD, CWC, etc.), and the hide when properties/formula all appear in separate columns. Not only would this let the developer easily reuse the elements, but it would serve as beautiful documentation of an often nearly indecipherable piece of an application.
And then there are xpages...
792.4. Ben Langhinrichs (02/20/2009 06:37 AM)
@Kevin - Actually, the cosmetics are easier than you might think, as I simply place each field in its own layer, and every layer has a paragraph automatically, so adding the hide-whens in there is easy enough. Granted, I'd hate to have to modify the darn thing with all those layers around (150 fields means at least 151 layers), but you should be able to get a virtually identical design.
If I did it, it would mostly be for the curiosity value, which is why I'd just make it part of Midas and not a separate tool.
792.5. Kevin Pettitt (02/20/2009 07:27 AM)
@Ben - If its just for fun then why not give it away? I do still think the idea of exploding all the elements into a readable table will prove more useful if changes are being made, though doing that AND the cosmetically preserved version would be ideal.
792.6. Erik Brooks (02/20/2009 07:40 AM)
I could go on for hours about all sorts of little things that could - easily - be added to increase client versus web fidelity on HTTP, but I think Craig is right: cryo-freeze.
792.7. Ben Langhinrichs (02/20/2009 07:52 AM)
@Erik - But why do we put up with this? OK, we can't force IBM to change, but I'm an ISV. I can put my own frontend on Domino's HTTP if I like, or otherwise generate the HTML from Designer. So, by all means, let me know any and all items that I could fix. Obviously, I'll also give them maximum exposure so IBM can choose to fix them as well, but if what everybody says is true, it may be time to stop waiting for IBM.
792.8. Erik Brooks (02/20/2009 11:21 AM)
You're probably already the expert on many of them. General rich text rendering from design elements is a great place to start.
E.g. Table borders: Make a new form in Designer, add a table to it, give it a 1px red border. Open said form in Notes, and it'll look like you'd expect. Now open it on the web. RT <> HTML rendering at its finest.
Now put some text in that table, set it to Arial, 12 point, and open in Notes and on the web again.
All the RT-to-HTML rendering flaws you've found over the years translate in the same nasty ways via HTTP.
There's other functional aspects that are also Notes-client-only that we've all been screaming for for years, such as:
- date/time pickers on date/time fields (on the web they are just a text box)
- picklist functionality
- making a field's "input enabled" formula actually work
Most of these things were a pipe-dream back in the days of Netscape 4 due to lack of browser consistency, but they *should* have been dropped in at some point in the past several years.
It may be a little late for something like an HTTP-renderer-overlay (though 6 years ago you probably could have made a *killing* selling such a module) since xPages may solve almost all of these problems.
Even with xPages, though, we're once again all back to the problem of developing for:
1. The Notes client (great fidelity, but no xPages)
2. The Web client (xPages, everything else is pretty bad)
3. DOLS (same as #2, but without xPages currently)
...you get the idea. If they add xPage support to the Notes client, AND the fidelity is good, AND package xPages in with DOLS (which honestly should be easy) then xPages might turn out to be the "killer component" of Notes/Domino that truly gets us back to "write once, render anywhere."
792.9. Kevin Pettitt (02/20/2009 12:44 PM)
@Erik - I know there is work being done to make xpages work in the client, but we need to keep pushing to make sure it really happens.
792.10. Richard Schwartz (02/20/2009 04:46 PM)
Remember the time-line. Layout regions were new in Notes 4 in 1995, and that was about the same moment in time when the web entered our consciousness. Work on the Domino add-in for bringing Notes applications to the web started at about the same time and debuted in early 1996, but it didn't become official until later in the year. Lots of stuff happened really quickly. The Notes server was renamed Domino, the add-in became part of the standard product, and the development team expanded -- but was still pretty small. Meanwhile HTML was still very primitive, the browser wars were just heating up and it was not at all clear who was going to win or what standards would emerge, and getting something like a layout region to render reasonably in all the browsers available at that time and continue to render in what was going to be coming up... was probably quite a bit more of a problem than you are giving it credit for, and probably could not have ended up with a rendering that was discernibly better than what could be achieved without layout regions.
After that, it was probably just inertia.
792.11. Ben Langhinrichs (02/21/2009 06:10 AM)
@Richard - You had me 100% until the last line. You are absolutely correct that layout regions could not have reasonably been presented on the web in the R5 time frame. They could have been by the ND6 time frame when layers were introduced, because they would have used exactly the same web constructs as layers. So, by the time a replacement was introduced, they could have been rendered properly.
Which brings me to that last line. We tend to say "inertia" when what we mean is "not caring". That seems to apply in this case. In eight years, nobody cared enough to either actually deprecate Layout Regions or update the web engine to use them. Why do we put up with that as partners?
792.12. Richard Schwartz (02/22/2009 08:05 PM)
Just saying that inertia had already set in before ND6. By the time work began in earnest on ND6, layout regions had already been languishing without web support for four or five years. Not that this was a good thing.