rethinking the template

[rejetto]

Some thoughts, possibly already made many years ago...
when HFS was born the template (TPL from now on) was just "displaying", and it was/is fully customizable.
The easy and most common way to customize, without diff tpl, means that people is not getting updates.
Now the tpl contains important features and security.
It is very bad not getting updates on this, therefore some thinking and possibly action is very advisable.

What options do we have?

1) hfs numbering the default tpl version, recognizing problematic pieces and patching.
This approach, that is already halfway and may arrive in final 2.4, has a number of problems:
it requires specific work each time,
thus would probably be done only for security problems,
it would have no impact on other templates,
non-zero inconsistency risk after patching

2) not letting the user to access the tpl directly, catch only the changes, produce a diff automatically (not in the diff.tpl format, more like the original diff tool), store the diff result, and use only this, applying it to the current tpl. Problems:
i have to find a lib for that,
3rd party's tpl may need some special treatment,
may be hard to apply to legacy customized tpl starting today

3) removing the tpl editing, leaving only the diff tpl feature. Problems:
bad for usability, requires more skill,
sub-optimal granulary (a whole [section]),
may be hard to apply to legacy customized tpl starting today

4) else?

[LeoNeeson]

I do understand your feeling, sometimes template editing turns HFS in something chaotic, and you want to have 'consistency' for all your work done (especially talking about usability and security).

Personally, I have to suggest two points more, and this is only my opinion (my own point of view, so, don't take my word as something important, since all the users have the same opportunity of leave an opinion). I know my point #4 could sound extreme, but here it goes anyway...

4) Leave TPL editing only as standalone feature (self contained templates), without hfs.diff.tpl and hfs.filelist.tpl (removing diff templates feature). I appreciate the work of some users (especially the hard work of DJ), but I have to admit that sometimes is confusing to the end-user having so many diff templates, since you could not know what template you have to use first (as base to that diff), and this could lead to confusion (and break usability). Although diff templates are a very useful feature, it could make HFS chaotic (for example, try to apply a hfs.diff.tpl to an incorrect base template and you will know what I'm talking about). The problem is, removing diff templates would make users share complete standalone TPLs, loosing official updates, so I guess nobody would like my point. So, here comes my point #5 to solve this...

5) Users have to add a random "ID" to all the templates (similar to the SessionID), and force all diff templates (which makes use of hfs.diff.tpl and hfs.filelist.tpl), to specify for which "ID" are designed for (it could have more than one ID, separated by a comma), and load that diff template ONLY in case the main template is installed and matches any of the IDs for it was designed (if it doesn't match the ID, then don't load it). This way, we remove the possibility of having template chaos. You could get some inspiration on how Greasemonkey scripts have a commented 'header', where a lot of details are specified, for example, see this script header).

» Conclusion: Between your 3 points, I wold vote for point number 1, since it's the less restrictive, but I also like my point number five. About your point #1, I would make a library of all what you consider essential, for example you could have something like "/?mode=section&id=essential.js" and I would force this to be included on the html head of all the templates (and this would keep security without affecting the design of other templates).

Well, that's my 5 cents opinion.
Cheers,
Leo.-

[LeoNeeson]

Example of how the headers described on my point #5 could look (I do this, to avoid confusions).

Code: [Select]

// ==HfsTemplate==
//
// @ID:            MTIzNDU2Nzg5MA==
// @title:         New modern template for mobiles
// @comments:      https://rejetto.com/forum/?topic=12345.0
// @description:   This template is meant to use on mobiles with small screen.
//
// @author         LeoNeeson
// @updated        2020.05.18
// @version        1.2
//
// ==/HfsTemplate==

[put-template-code-here]
And the validation of the diff-template is done with @valid-for:

Code: [Select]

// ==DiffTemplate==
//
// @valid-for:     MTIzNDU2Nzg5MA==; NTY3ODkwMTIzNA==
// @description:   This is small mod for the cited templates
//
// ==/DiffTemplate==

[put-diff-template-code-here]
The user can add more custom '@tags' (which could be ignored by HFS), but (on my example), only 2 tags are mandatory: @ID: in normal templates, and @valid-for: in diff templates. This is only an idea, you can leave a comment if you like it or not (and for anyone reading this, this is currently NOT implemented, and it could never be). Anyway, I'm only commenting this to give Rejetto some inspiration (he could use this or any other method, or not use this at all).

[LeoNeeson]

On second thought, I'm not so sure if a big change on the template editing could be of any good (like my suggestion #5, that could break compatibility with old diff-templates). Template editing was a success of HFS.

Freedom is always appreciated (some users generally want to have complete control on how the template looks). And editing templates gives some users the enthusiasm of being part of the HFS community. Removing template editing it's like cutting a dog's tail...

If it were possible, the security features you are most worried about, should "moved" to be done at server level, at not a client level (on the template), since users could break things when they edit the template. To give you an example, the last feature you added (URL with session), depends on the end-user have JavaScript enabled (if JS is disabled, the resource doesn't load until the page is refreshed). Nowadays all browsers have JavaScript enabled, so that's not a problem. What I'm trying to say is that if somehow we remove this JavaScript dependency, this new feature would work independently of which template the user have installed.

I personally always used the default template (the old and now the new one), because it has all what I need (with a good design choice), but some users want to have almost everything included (an audio player, an image preview, image slideshow, etc), and they are happy editing the template.

So, I think it's server's administrator responsibility their own server's security. From my point of view, is beyond your responsibility if the server admin change your default template and break things. You could make it very clear that 'warranty is void' if the default template is changed, and you can display a 'warning message' on the first time the admin changes the template (if that makes you feel better).

Well, my opinion is not relevant, after all it's your choice and preference. Like we all say here, you are the boss and your decisions will be respected, whatever decision you take (and you always have made good decisions about HFS's functionality, and have designed the template with good taste). So, feel free to do what you think is best.

(I hope some other users can also join this discussion, and leave an opinion about this on the next days).
Cheers,
Leo.-

[dj]

@Leo,

my "hard" work don't help, if it don't help the user.
I leave a comment in the diff.tpl, which tpl work with it.
I know my docu could be better.

P.S. my template works also with webfonts

to your point #5:

I would not use an anonymous ID, but a meta tag
this should be added to diff.tpl:

Code: [Select]

[+]
<script>
const description="HFS fileserver"  //edit here
const id=document.querySelector('meta[name=Description]')
if(!id||id.content!=description) alert('this diff.tpl is not compatible with this template')
</script>you can test it with my latest diff.tpl(sha256)

[rejetto]

thanks for you comment guys.
Leo, chill out, have some margarita, you don't need to always specify that your opinion counts so little Use the standard IMHO disclaimer.

You just gave 2 good suggestions I will think on. Moving some features to the Delphi side will surely help lessen the problem.
Also, the suggestion to have a mechanism to bind some diff tpl to specific tpl is good.
I think as syntax is better to use special [sections] instead of introducing a new syntax.
Like this in the tpl
[template id]
default 2.1

And this in the diff tpl
[my section|template=default 2.*;takeback*]