Description | Content | Contents

[nofue]

Depending on the component, the same thing is achieved by three different names. Is there any chance to allow slowly phase out the use of content | contents in favor of description? It's just confusing and annoying to get trapped by such a minor thing every now and then … Maybe allowing description in all such occasions for the time being, and changing the manual pages to description to avoid new code is written using content | contents.

[lovasoa]

Hi ! I agree on principle that we should strive for consistency, but could you be more specific as to what components you are suggesting to change ? I think for instance that contents is a good name for the contents of a title, code or text components, whereas description would be a poor fit... Some components have both a description and contents. Where do you feel we have contents that should actually be descriptions ?

[nofue]

If you can't decide between content, contents and description, just follow what you did in component "text".
That's to the core of the issue.

It's just crazy to have to look up the manual because of the (abstractly speaking) same thing uses content instead of contents or description with the very component in question.

In the same sense, cards -> footer + link is possible, whereas footer_md + link is not. I understand the reason behind it, but user friendly is different. SQLPage is super nice to work with, but this "debris" accumulated over time makes it hard to love it.

[SebastiendOrnano]

It is true that there is sometimes a lack of consistency between the names of parameters in different components. However, aside from the difficulty of finding terms that resolve these consistency issues, it is important to bear in mind that a change in a new version of sqlpage could cause problems for apps created using older versions.

However, sqlpage is flexible and allows you to create custom components. In my case, I find it is a shame that the ‘title’ parameter is available in the “list” component but not in the ‘table’ component. I got round this by creating a custom component that I use every time.

It’s perfectly possible to create custom components using “content” (or whatever term feels most intuitive to you, such as “description”) instead of “contents”. It takes just five minutes to code, but it saves you from having to think about it later when you use a particular component.

[nofue]

As it is true that there's always a way around things, I'm not a big fan of changing a running system to fit my needs. Basic stuff as parameter naming should be consistent between all users of such a tool, just for the sake of exchanging or demonstrating source code.

Regarding backwards compatibility: In similar situations I just used a switch/case statement to do the same task with various keywords. I suppose this would also be possible with Rust and thus I proposed that consolidation. No throwing out the keyword to make every app written so far to fail, but mostly changing the manual and adding some code to let new code use the new keywords
The old parameters may be phased out in some years from now, so not a big deal anyway.

In my experience, less cluttered interfaces help to make more people enjoy the product -- but I'm only coding for 42 years now, so I might be wrong.

Regarding the general way of using SQLpage: I think it's a very mature and nice tool and I choose it for my prime UX dev. As I write plenty of rather boring stuff, I don't need a fancy presentation, but one that just works on all devices. Most of my code goes into Postgres with some Go attached, and that are the "variables" of my dev. I'm happy to have SQLPage at hand without major tinkering like when using a PHP based webinterface, using a gazillion of modules and libraries where you have to spent hours over hours just because somebody had a great idea, which then breaks all the code you built upon.

You see, milages may vary and I'm a fan of maximum stability and performance. And, bottom line, this is a suggestion and I'm quite sure Ophir knows very well as how to handle it. He built a marvelous system I'm happy to use, and the least I can do is to add some of my thoughts from time to time when I feel it would make sense for everybody.

[lovasoa]

If you have concrete suggestions of renaming and deprecation, they are welcome. But as I said above, just a broad phase out the use of contents in favor of description everywhere is IMHO not desirable.