[GoLUG] DRY in my 444domains.com system

[Ron / BCLUG]

Steve Litt wrote on 2024-12-11 22:50:

> In my December GoLUG presentation I spoke up for DRY: "Don't Repeat 
> Yourself", and mentioned it as related to database normalization.

A worth topic!


> My 444domains.com website...

... eschews DRY by repeating domain info once for every sortation option.





> Yet I still need the price in the conversion script in order to sort
> by price.

The sortation should be *within* the page, which fixes the DRY problem.



> Of course, the easy way would have been to make a fourth column with 
> an (optional) URL.

Or a fourth column with a boolean flag indicating the already-existing 
domain name should be a hyperlink to itself (normalization!).



> But then there would have been a price in the 
> Moretime.Com website and in the 444domains.com data file, and they 
> would have needed to be kept in sync

Both the build tools *and* the moretime.com should be pulling the price
from a central, canonical store.

Then a price change requires zero rebuild and redeploy, just an update
to a field in a DB or file.



> I need each domain's price in exactly one place, either in the
> 444domains.Com data file or in the Moretime.Com website

Those are not the only options, just bad ones.

How about storing them like this JSON? (complementary `curl` added):

curl http://bclug.ca:3010/golug/list/



> Having it in the data file would have necessitated my remembering to
> run Moretime.Com's index.html through the script every time I changed
> the price, and I didn't like it.

Yeah, that is far from optimal.



> So what I plan to do is have the possibility of a URL instead of a 
> price in the URL field.

Wait, URLs go in URL fields, prices go in price fields. Very basic DB 
stuff here.


Generally also a consideration for semantic web sites (navigation in nav 
tags, not div tags, etc.).


> Then my 444domains builder script will look 
> inside Moretime.Com's index.html file for the price, and use it to 
> sort.

Please, no.



> Which isn't so simple

I believe that is an "understatement".


> So I need the price in exactly one place in 
> index.html

In one place, yes.

That one place being index.html? Hell no!


> and stated in a way that it can easily be parsed out.

Parse prices *into* HTML, not *out from* HTML.


Each index.html could <script src=...> which points to the JSON file 
like above, with a slight modification to the JSON to "export myList = 
...", then each site can easily use its location info to parse from the 
array of objects its price (and description), then insert it anywhere in 
the page.



> So the one and only place the price is quantified is in the line:
> 
> span.bux::before{content: "$54,321.00";}

Oh. My. Gawd.

As far back as the early 2000s, maybe even the late 90s, it was common 
to complain about people using spreadsheets as databases.

In 2024 someone's going to use *CSS* inside HTML files?!?




> Once the preceding CSS line is stated, anywhere I want to put the 
> price can be displayed simply by the following HTML tag sequence:
> 
> <span class="bux"></span>
> 
> And as far as the 444domains.com builder script, all it needs to do 
> is look in the Moretime.Com (or whatever domain I'm selling with a 
> website) index.html for "span.bux::before{content:", and then
> capture the string that follows. In the 444domains.com builder script
> I can strip out the dollar sign and commas and turn it into a number
> for sorting.
> 
> Kinda slick, huh?

No!

It's all a horrific Gordian knot of kludges.

It breaks rules of databases, web pages, the Geneva Convention, UN UDHR, 
all Articles of the US Constitution, and worst of all, still leaves 
444domains.com with the Don't Repeat Yourself problem.


It's like a database where each person's name is stored in its own 
table, but somehow even worse.



> PS: I don't use Javascript except where it's needed

This is exactly what it's designed for, and superior to a hack of some 
combo of curl, sed, awk, bash, and / or whatever.


It seems like an ideological dislike of JS that makes this whole project 
ridiculously more complicated.


JS would let you keep a central store of all data - maybe even in a 
proper DB like PostgreSQL if you want, or at least a JSON file (see my 
link above).




Something like this is how it could be done:

 > https://ronaldbarnes.ca/react/444domains.com/

Normalized, centrally stored, non-repeated data, sortable, searchable, 
sends a formatted email of the items in the shopping cart with a sum of 
the prices,...

One could add URL links to the domain names (keeping the prices in the 
price column) with the simple addition of one boolean field to the 
central store (JSON in this case), and a couple simple lines of code.




This all feels like a prank of some kind.