The state of DXL 15 Aug, 2006
Mac Guidera recently posted about the state of DXL today, DXL - What is it good for? Mac’s post gives a good summary of where we’re at, and his hopes for the future with people like Dick Annicchiarico at the helm. I would encourage you to head over to Mac’s site and chip in with your thoughts and observations.
What I find interesting is that his post harkens back to some DXL-related buzz that took place almost two years ago. Yikes! Until Mac brought this up, I simply hadn’t realised how long ago we’d been talking about all this. The discussion as shifted focus slightly though: to my mind there are two main “movements” that have brought DXL to the fore once again:
- DXL from things like
?ReadViewEntries
in web applications now that we’re all doing the Ajax thing - DXL as a possible mechanism for skinning Notes applications
The latter point has come up during the recent Nifty Fifty discussions, specifically from Charles Robinson who is looking to put together a DXL-based “UI skinner”. That would be pretty cool. I started out with something like that a while back, but as with many of my bits of code, I didn’t see it through : Simple DXL processing.
That being said I think that DXL has been a welcome additional to the Notes/Domino API's since a tool like LotusScript.doc would never have been possible without DXL so I at least am happy about for it.Mikkel Heisterberg#
It's probably also worth noting that DXL isn't yet "complete", in that you can't fully express a database and its content as DXL (outlines spring to mind, but there are other things).Ben Poole#
http://www.timtripcony.com/blog.nsf/BlogByCategory?OpenView&RestrictToCategory=XIDED
But nearly all of what I've seen it used for is read-only, such as the ReadViewEntries… and the less common ReadDesign URL command that displays DXL information about the layout of the view, allowing you to know how many columns, for example, to expect before you parse the actual view content.
With all the chaos of moving (and changing jobs) twice in one year, I haven't spent as much time on XIDED as I'd intended, but another idea I recently had was for a search-and-replace tool for design and data, similar to TeamStudio's Configurator.
The biggest factor that I see so far preventing its widespread adoption (because there really is so much it allows us to do) is that it's huge. The Domino DTD, that is. So not only must one become familiar with additional tools / techniques, one must also become familiar with the contents of the DTD in order to know what can be exported and imported, and how. A perfect example of where this gets messy is the representation of rich text… try exporting any document with rich text that contains more than one paragraph definition and you'll see what I mean.Tim Tripcony#
I was aided in my field altering endeavors by some code written by Ferdy Christant (http://www.ferdychristant.com/blog/articles/DOMV-674NCF), which is definitely worth a look if you're in the DXL business.
Also, I recently noted another set of "Teamstudio-like" development tools called "NotesHound" which might (haven't tried them yet), be using DXL in some manner. You'll find them here: http://www.noteshound.com/notes_hound_tools.htm
I also definitely see DXL playing a part in the whole "standard architecture/skinnable UI" thing.Kevin Pettitt#
http://www.lotusgeek.com/sapphireoak/lotusgeekblog.nsf/d6plinks/ROLR-6LUS98
I also used it in Notes access for SAP solutions:
http://www.lotus.com/notesforsap
There are a couple of hurdles left to scale before we can really exploit DXL.
The first is that it MUST be able to "round trip" a design element at 100% fidelity. It is REALLY close - probably over 95% - but it still isn't 100%. When it gets to 100% when round-tripping an element, then we can begin to do things like skins, automated design changes, etc.
The second is that the LotusScript interface to DXL/XML MUST be maintained on-par with the Java interface. At the present time the DXL side is pretty much there, but the XML interface is woefully behind. We must keep in mind that roughly 85% of the Domino Developers out there are LotusScript developers who know very little, if any, Java.
So, is DXL important? You bet. Will it continue to be? More and more so. Does it have a way to go before it is where we want. Yes, yes it does.
--RockRock#
http://www.ferdychristant.com/blog/articles/DOMV-674NCF
I took a deep dive into DXL 2 years back. I found it to be a very unreliable feature. It crashed Notes clients in some versions, choked on externally compiled Lotusscript and didn't even see it own unmodified exported DXL as valid input for an import.
I hope things have changed, but I'm not trusting it again until proven reliable. Just my two cents.Ferdy#
For my purposes, which were simply to make a change in a collection of fields from CFD to Computed, it did work OK. After importing the altered DXL back into Designer (as a new form), I just cut out the needed section of that form and pasted it into the original form, and haven't discovered any problems with the altered fields, so far.Kevin Pettitt#
Thanks for chipping in everyone, keep ’em coming (and Ferdy, I hear you—I get weird errors on the code I wrote in 2004, but it still works OK-ish).Ben Poole#
Chiz
Spug
Spug#
Oh, and Ben - you can "legally" allow the modification of design elements to a system for people with less than designer access by simply basing the changes on config docs that the user fills out, and then have a scheduled agent that is signed by an ID with designer rights that performs the work. Used this in many customer sites, works great - and also allows you to have tighter code control to make sure to avoid some of the pitfalls in DXL.
--RockRock#
It would seem that the completeness of DXL is a major issue amoungst developers today.
I had thought that URL commands would dominate the discussion and wishlists.
--MacMac Guidera#
Rock — good point!Ben Poole#
Sumeet.Sumeet#