There are currently a number of issues with DXL round-tripping that affects use of source control. These include:
I discussed this with Andre Guirard at Lotusphere 2014 when I (Paul Withers) also presented a Show and Tell session with Declan Lynch. The impression I got at Ask The Developers was that there are other issues I hadn't identified. I know DDE does something to extract Java agents as a separate "Project" when you edit them, so I'm not sure how DXL round-trips those. When analysing DXL for design elements recently, I've encountered failures to read the DXL sometimes, possibly related to older databases. I believe there may have been some improvements around DXL for or in ApplicationInsights, I don't know what they were or whether they're in recent Domino or Domino Designer versions.
WHY IS THIS IMPORTANT NOW?
With the news about HCL Nomad there has been an increased focus on traditional Notes Client applications. But the issues identified and potential for others makes this an inadvisable route for source control management. Other proprietary solutions are limited to Domino, meaning differing source control tools and experiences for Domino and non-Domino solutions. In the current landscape and the desired future for Domino, that also is not desirable.
THINKING BIGGER, OPEN AND DEVELOP AS ODP
Source control requires single flat files rather than the Design Notes in an NSF. I don't know if that can be addressed. It's not beyond the realms of possibility that opening a database in DDE could actually generate an ODP or allow conversion to an ODP, and an "Applications Navigator" could launch the simulated, "Views" of design element types (Forms, Framesets etc) generated based on metadata, with the appropriate editor launched automatically.
BENEFITS FOR DEVELOPERS AND HCL
Faithful DXL round-tripping could result in developers using a consistent toolset, which is a benefit for everyone.
It would also mean source control could properly be used for all Domino projects on OpenNTF.
It could also provide flexible deployment options for users / developers / administrators from an "Application Catalog"
It could allow OpenNTF / Business Partners to more easily deploy applications to servers/ end users
It could allow IBM / HCL to easily deploy updated templates outside the traditional release cycles
It would allow developers to easily send pull requests to open source projects
There are some IBM templates already open-sourced on OpenNTF. Future versions or other templates could then be open-sourced. It would allow IBM / HCL to receive pull requests for standard templates accepting bug fixes, new features, improvements for interface, extensions for integration outside of the NSF etc.
Seems to be a really hard issue to enable developers in the Domino world of having the same supportive code control like in other worlds.
I think that the datestamp issue alone would remove most of our issues.
Would that be difficult ?
Sean
The DXL approach is a nice starter but the file is a mess and by far not human readable with all the weird attributes.
One possible approach is to use some of the results of the HCL Domino REST API (aka Projekt Keep). Clean and simple JSON.
If a form is saved in the native Designer Client, the information about fields and layout need to be separated in at least two files. One file contains the blunt field definitions of the form (i.e. what type of field, field name, field settings) - in JSON. Like it is shown here: https://opensource.hcltechsw.com/domino-keep-tutorials/pages/collabsphere21/postman_contacts/creation
The second file contains the layout of the form, where special tags (see also vue, angular, react) are used to embed the fields - some similarities with HTML5 are very appreciated. Here the visibility options, values and formulas can be part of the field tag. Easier to maintain would rather be, to have these parts in a third file, where all the programming of the form and fields is stored.
On creating a new form via the designer, the form name is also the name of the folder on the disc, where the files for the fields (form.fields), the layout of the form (form.layout), the formula and script of the form (form.code) are generated automatically - populated with the standard events like we know them in the designer.
Why this method?
When separating the data model information, form layout, form / field code there is a great chance to also use modern code formatter and code analyzer and let the Domino Designer be the "translator" between the NTF/NSF and a local git repository.
If someone likes to work on a single file, there should be also the option to define separate sections within the single file - instead separate files for each section.
Still waiting for a working source control management.
The teams in "the other world" can work in parallel on features - we in the Domino world are not able to work in parallel in an application (say, a team is working on a form, but on different sections).
The result is, that the person who save the last, either kills everything that has been contributed by all other team members, or is foced to drop his changes
Additional incomplete DXL encountered for Agents, Document Selection, By Field when selecting a date or number field - the operator is not included in the DXL. So when selecting a date field called DateField and looking for date "after" "12/12/2020", the DXL outputted is <search type='byfield'field='DateField' value='12/12/2020'>. The operator is not included, so is not expected to round-trip with full fidelity for all operators.
Related https://twitter.com/PaulSWithers/status/1310936651603083275
Issue here: https://stackoverflow.com/questions/64120666/web-access-properties-of-a-notes-view-dont-appear-in-source-control
Related idea: https://domino-ideas.hcltechsw.com/ideas/DDXP-I-251
Ensure the produced DXL is formatted to allow merging without breaking the DXL. ie. Forms break when merging changes because end tags get duplicated
See https://twitter.com/bgewehr/status/1161498453979144194?s=20
The alias of javascript libraries (or files- I can't remeber which) seems to be held in the .metadata file rather than the actual library file, so if you git-ignore *.metadata, you lose the alias.
A simple tick box on the database options could start this off:
"Use DXL v2 for Source Code control" and add some sort of native bit bucket and/or github controls etc
This issue is starting to become a show stopper for me.
Build and deploy tools need to be able to pull the branch, build it and deploy it. There is no reason for organizations to have Domino as this island when organizations have a DevOps culture, Cloud first, QA team that will run tests against a deployed build.
when using swiper to remove noisy parts of dxl you sometimes ends up in a loop. export -> swipe > import > changed element > export > swipe ... and at the end some design elements get broken.
Moving this idea to product : Domino Designer
Adding to the list of issues:
Pretty sure there are other issues as well.