- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Hunderdth
Edit Admin
Aren't you making a bad assumption here? You know, that someone, anyone, even thought at all about it?
Edit Admin
The whole "dynamic UI" stuff is such a complete waste. One of the apps at my company has that; if I recall (I work on a different one), there's the real UI and the "EZ" UI, which is all dynamically generated from the columns relating to that entity in the database (which has a separate table indicating the metadata type so that like Name will be a textbox, something else might be a radio or checkbox, and so on). I can only imagine the idea was "This way we dont' have to modify the UI when we add a field!" which on the surface is sound but is just madness.
Edit Admin
Using JSON for anything other than data interchange is a WTF in itself. It's actually surprisingly unwieldy to write and there's no comments allowed by design.
Addendum 2025-03-31 08:24: I say "by design" because JSON was specifically designed for data interchange when they added comments, they found people were using them to sneak in processing directives for their parsers which automatically makes it non portable.
Edit Admin
My former employer is changing everything to be generated UI (server creates UI, ships it to client which executes it). This is not working very well, as testing this is a nightmare. It means you can generate anything at anytime, with zero testing time. It's basically a bug generator.
Edit Admin
Isn't "dynamic UI" just another form of Inner Platform? (Especially at the level that @ObiWayneKenobi described.)
(If it's just two modes that are mostly static layout, sure, it's not Inner Platform, but ...)
Admin
Once the decision to use JSON as a source language has been made, there's little reason not to go the whole distance and throw in a YAML translator. At least then you can have comments.
Admin
BFF is a well-known pattern that I've seen used in at least one company, where the backend coders were so busy with refactoring and cloud-shift work that they absolutely could not be bothered with UI-related requests. Generating a UI is not part of the pattern.
Edit Admin
From: [email protected] (Paul S. Winalski) Newsgroups: comp.os.vms Organization: Digital Equipment Corporation
Furthermore, [your wishlist item] would end up being the sort of system feature that we in software engineering call an "SPR generator".
Admin
Came to say the same thing. BFF is not unusual and far from a WTF.
This particular (mis)understanding and implementation, on the other hand, most certainly is.
Admin
The lengths that companies will go to, to avoid hiring a database engineer are staggering…
Admin
I actually attempted something like this. The idea was it was more or less a data storage web service for different settings in the app, broken out across several levels.
As part of the API, there were metadata endpoints telling you what data type a particular field in the json was, and what it was used for. The types were pretty compact, usually some combination of a enum and zero or more dates.
I toyed around with making a UI in AngularJS back when it was just Angular that would read the metadata and generate the appropriate widgets in the UI. I got it about 90% working.
Happily? the UI got sent to another team that had to work with other web services doing similar things in different domains, and it was scrapped. Call me crazy all you like, but I still like the idea for my specific use case.
To the story, though, definitely needed a different variable name than 'maxvalue'. Like, 'maxyearsout'. Kinda feels like a weak wtf to me. Surely the system had worse examples?
Admin
Clearly the configuration data should have been in XML, embedded in the CDATA of even more XML which in turn is a single field in JSON notation.
Edit Admin
About a decade ago, I worked next to a team that was doing internal-user-generated data display. And yeah, we used JSON to define the page layout. That wasn't great, but it worked, because there weren't terribly many options available.
The biggest problem was that it would have been faster, less buggy, and generally more suited for the customers if we'd just built bespoke pages for each internal customer -- there were only 6 or so teams using our site at first. Making generic components that work from a wildly-varying configuration is a lot slower than making reusable bespoke components. We could have banged out six team-dashboards in the time it took to both a) make those configurable things and b) teach the teams how to build their own pages with those configurable things.
We have since ditched the JSON-configured UI.
Admin
I actually work with a framework for generating a UI out of service metadata. It's called Fiori Elements and is developed by SAP. It's surprisingly robust and feature-rich, but you can enter a world of pain if you need to do something that's not part of the template.
Edit Admin
Many people already said that this is not really "BFF", Backend For Frontend (usually a backend that handles the minimum that cannot be done in frontend, typically authentication/authorization and session).
It's more like Frontend From Backend (FFB), but the best acronym is probably Frontend From Schema (FFS).
Admin
Took me a second to realize that the 99 didn't mean "accept up until 99 years after the minvalue" but "accept up until 99 years after the current year." If this is the level of jank in the codebase, I'm sure this one example is not even scratching the surface in how counterintuitive things can get!