Discussion on: Introduction to the Document Makeup Library (DML)

[artydev]

Thank you Eckhard,
I really believe in DML ant its potential :-)

[Eckehard]

Yes, first commercial projects we have done using DML have been very promising.

But there is one issue I could not solve til now:

Using scripts instead of ES-modules is quite convenient, as it let´s you use all your functions without effort. BUT: it adds all defintions to the global namespace, which earlier or later will result in name clashes. Additionally, DML currently contains lot´s of constants and functions just for convenience, giving a total of about 170 names in your namespace, and most of them are rarly ever used.

There are several solutions discussed here using ES-modules, which is the right way to do, but has drawbacks too:

• Using named input with a list of 170 in every module is not very convenient. Maye, we can organize our import in functional groups like this:

    import {selectBase,  unselectBase, setAttributes, make, appendChilds} from "./dml.js"; // base routines
    import {h1, h2, h3, h4, h5, h6} from "./dml.js"; // page elements
    ...

Don´t know if this has some negaive impact?!?

• Using wildcard import makes us use the alias on every identifier, which may sum up to some thousand alias in every project. This is boring and reduces the readability of the code.
• We could put the whole script into a function and use the "revealing pattern" to isolate the namespace, which in fact has the same result as a wildcard import from an ES-module that we need the function name as an alias
• we can use a mixed pattern using named import, but put things together like this:

export const css = {
    bold : "font-weight: bold;";
    italic : "font-style: italic;";
    bigtext : "font-size: 130%;";
    bg : "background-color: ";
    bgred : "background-color: red;";
    bgred2 : "background-color: #f50;";
    bgy : "background-color: #ffc;";
    bggreen : "background-color: #695;";
        ...
}

Here, all constants are grouped in JSON-object "css", which can be import as an entity. Now we use div("",css.bold) instead of div("",_bold), which is not really bad, but does not really improve the readability. As it makes the intention clearer, maybe this could be an advantage.

• We could split the core script into functional parts like:

DML_core.js
DML_util.js
DML_consts
DML_...

which would allow more fine grained import, but I assume, most of the time we would import all modules anyway.

Is there a better solution?

I would really appreciate if there was a way to use the library inside a scoped context, so all definitions live only inside this context, similar to the revealing pattern.

We CAN implement such a pattern using classes:

class DML {
        privateVar = "Ben Cherry",
        publicVar = "Hey there!";

        privateFunction() {
            console.log( "Name:" + privateVar );
        }

        publicSetName( strName ) {
            privateVar = strName;
        }

        publicGetName() {
            privateFunction();
        }
    }
export { DML }

---------
class myNewApp extends DML {
      main(){
               this.setName( "Paul Kinlan" );
               ...
     }
}

This would be a nice approach, if it was not Javascript we where using. Here we need to write this as a prefix, which is not any better.

Using named inport currently seems to be the most appealing and correct way, but it seems to have very little advantage over the current "script"-approach (beside the possibility to avoid name clashes). If there is any better solution, any suggestion is very welcome.

[artydev]

Hy Eckehard,
I also believe named import is the best solution, and let tools like Rollup do tree shaking for production.

But, I also think you could, at the same time deliver DML_core.js (and co.) which would benefit those who want don't want to deal with node.

Regards