version 2.4

[rejetto]

@Mars/Anyone: Do you know why if you use the new template on the old HFS v2.3m, it doesn't work properly? (even using a modern browser). I don't see the reason why it could fail, since all the required files are self-contained on the template.

i think it's because 2.4 fixed some bugs related to the template loading.

[Mars]

why not consider having both versions of jquery.min.js in the exe as resources and somehow make a detection of the new template related to hfs 2.4 and utlser the most appropriate jquery to keep a compatibility


  if data.urlvars.values['mode'] = 'jquery' then
    begin
    if tplversion<'T4' then replyWithString(getRes('jquery'))
         else replyWithString(getRes('jquery2'));
    conn.reply.contentType:='text/javascript';
    exit;
    end;

it would be possible to add a specific instruction in the new templates in order to allow the differentiation of jquery to use

[rejetto]

- Possible bug found #1:
- Possible bug found #2:

thanks for reporting. These bug are of the template itself. I will work on them asap.

- Design issue?: if you give a comment to a folder,

i had actually not worked on this part yet. Now fixed.

What kind of use you make of your XP computer? Is it a media server? a secondary  computer? a primary computer?

[rejetto]

why not consider having both versions of jquery.min.js in the exe as resources and somehow make a detection of the new template related to hfs 2.4 and utlser the most appropriate jquery to keep a compatibility

to get what? maybe you didn't read my previous  post. I tested some old templates and they were compatible with newer jquery.
Let me know if you find some template that is not compatible.

[Mars]

I do not know what to answer, for now with hfs 2.4 and the template of 2.3, i can not check some files but COMMENT button does not work

maybe,  am I in special conditions?

I confirm, the good functioning depends on the version jquery in resource

 I updated data.rc  as it

1 24 "WindowsXP.manifest"
defaultTpl TEXT default.tpl
copyright TEXT copyright.txt
dmBrowserTpl TEXT dmBrowser.tpl
invertban TEXT invertban.txt
filelistTpl TEXT filelist.tpl
uploadDisabled TEXT upload_disabled.txt
uploadHowTo TEXT upload_how.txt
alias TEXT alias.txt
shell GIF shell.gif
IPservices TEXT ipservices.txt
jquery TEXT jquery.min.js
jquery2 TEXT jquery2.min.js

added in main.pas

  if data.urlvars.values['mode'] = 'jquery2' then
    begin
    replyWithString(getRes('jquery2'));
    conn.reply.contentType:='text/javascript';
    exit;
    end;

in the new template

[]
{.$common-head.}
   <title>{.!HFS.} %folder%</title>
    <script type="text/javascript" src="/?mode=jquery2"></script>
   <style class='trash-me'>
   .onlyscript, button[onclick] { display:none; }
   </style>

I put in the directory of exe two tpls named hfs23.tpl and hfs24.tpl corresponding to the versions to be tested, which allows from the menu to quickly change used template and refreh the web page

working perfectly, and the compatibility with the old templates remains whole

use this link to load a demo version

[rejetto]

I do not know what to answer, for now with hfs 2.4 and the template of 2.3, i can not check some files but COMMENT button does not work
maybe,  am I in special conditions?
I confirm, the good functioning depends on the version jquery in resource

good finding, thanks.
Compatibility with template "TR2" is important, as a lot of people have a "customized template" and would have problems updating to HFS 2.4 .
I think i have a better solution than keeping 2 different libraries: I'm appending to jquery file the "jquery-migrate-1.4.1.min.js" that will give compatibility with just 10KB (4 when gzipped). I just tested it for the "comment" feature, and it fixed it.

[Mars]

with just 10KB (4 when gzipped)

women often say that it is not the size that is the most important, but the quality of the "work" and the pleasure it gives 

can you load the demo version that I put and test the addition of userCFG and see result in hfs.ini 

user data can be defined with SET INI and GET INI for use in a template, and managed from the options dialog (F7 last tab)

these data can be used as persistent variables between two hfs launches

[dj]

you are discussing about different versions of jquery.

jQuery was born many years ago when browser implementations were very different, and much of the advanced functionality (like querySelectorAll) was not implemented. Now with the new javascript, there's very little reason for jQuery.

why not use the change and write the template without jquery?
For the old templates you can leave jquery in hfs or change one line in the old template.

If I have (5 hours) time, I will try to rewrite the template without jquery.

[Mars]

@rejetto

discovery new bug with comment  hfs 2.3 and 2.4 are same

comments in hfs.comment.txt or descript.ion  seem saved trough "htmlEconde" function

    case s of
      '&': p:='&amp;';
      '<': p:='&lt;';
      '>': p:='&gt;';
      '"': p:='&quot;';
      '''': p:='&#039;';
      else p:=s;
      end;

test.txt=there is a &quot;bug&quot;\nwith comments\ntext is saved as\nhtml code \nas with &quot;htmlencode&quot; function



when used multilines in comments, lines are serapated wit '\n'  (that is correct), but when editing
comment with web page \n are converted as <br> and appear on screen

when comments are saved in descript.ion, each line of comment is ended with code 0x04,0xC,x0D,x0A

Here, I mean that the descript.ion file contains a backslash and a letter 'n' where I typed a line break, and two special characters 04 C2 at the end of the comment. In addition, the line is ended by a Windows line break 0D 0A.

Apparently, the two extra characters at the end of the line signal the end of a multiline comment. If I remove them, the comment is rendered as a single line in the GUI, and the '\n' sequences are displayed literally.

[rejetto]

with just 10KB (4 when gzipped)
women often say that it is not the size that is the most important, but the quality of the "work" and the pleasure it gives 

that you mention is not the gain, but the price to pay. The gain is that we have 1 library

user data can be defined with SET INI and GET INI for use in a template, and managed from the options dialog (F7 last tab)

Sorry mars but i will consider that feature later.
At the moment my priorities are the new template and bugs.
I'm struggling to find the time to make this new version.

[rejetto]

why not use the change and write the template without jquery?

Well, we are targeting some old browser too.
By the way, i've decided to restrict to ES5. (LEO read here, this concerns you)
I've also just noticed that these resources (jquery included) are not correctly cached. I'll have to fix this too.

[LeoNeeson]

First of all, sorry for my misplaced comment (I felt bad yesterday, and I thought you will never notice my hidden comment). I'm glad to see that you are open minded and that you appreciate my time, and there is no hurry (take your time to make the decision). My initial worries were that you could have been using 'ECMAScript 6' on purpose, as part of the massive 'browser planned obsolescence' there is currently going on (but now after reading your comments I notice that I was wrong, so, sorry again for my comment). Feel free to take whatever decision you think is best.

What kind of use you make of your XP computer? Is it a media server? a secondary  computer? a primary computer?

One of them I used them a media server on WinXP (for local sharing files, offline), but I also have one WinXP online (with a firewall) as one of my primary computers (that PC is used as client of the offline PC), and then I have another much faster PC only for gaming and specific applications, loaded with Win7 (but it's mostly turned off, because it's too noisy to have it on 24/7, and mostly offline).

Does your template work well with that browser (Chrome 31) ?

It does! it works perfect not only with Chrome 31 but even with Chrome 19! (as well it works fine with Firefox 24, Firefox 31, K-Meleon Web Browser 75, and others I've tested). Of course it doesn't work with Firefox 3.x or IE6, but nobody use them nowadays.

don't rush, my dear  Opinions are mostly made by experience. Everybody's experience is limited and doesn't always produce the best of results. [...] I think it's the result of coming to conclusions too fast.

I agree, and it's something I work every day on being better. I'm somewhat "passional", in the meaning of sometimes I take decisions 'being carried away by feelings or thoughts, without rationally thinking about the consequences' (I took definition from the dictionary).

because older javascript is a boring Language. Even when i was using it i had made a function myself trying to emulate the => arrow functions.

That explains all! and it was my mistake thinking it was on purpose (part of the 'planned obsolescence' that is currently happening on many things). Sorry for my mistake.

I thank you for your hard work, i undertand it was very long, but the decision should not be made on the number of hours. Do you agree with this?

Absolutely! Feel free to take whatever decision you think is best.

I have a possible solution to all this: perhaps this could be fixed doing a small routine, that detects if the browser doesn't support "the => arrow functions" (or other 'ECMAScript 6' expressions), and then it 'dynamically translates' those functions/expressions with older JavaScript code. Doing this, you only do that routine once, and you don't have to change every function. What do you think?...

[Mars]

when used multilines in comments, lines are serapated wit '\n'  (that is correct), but when editing
comment with web page \n are converted as <br> and appear on screen

same bug  in previous versions,  the offender is discovered, it is necessary to correct the setcomment function of the template

        function setComment() {
            var value = it.find('.comment-text').html() || ''    // change .html() by .text()
            ask(this.innerHTML, {type:'textarea', value}, s=>
                s===value || ajax('comment', { text:s, files:name }))
        }//setComment

test.txt=there is a &quot;bug&quot;\nwith comments\ntext is saved as\nhtml code \nas with &quot;htmlencode&quot; function

failing to do better: , this patch provides a temporary solution

procedure Tfile.setDynamicComment(cmt:string);
var
  s, path, name: string;
  i: integer;
begin
//as a possible function htmlDecode(s:string):string
cmt:=xtpl(cmt,[
      '&amp;', '&',
      '&lt;', '<',
      '&gt;', '>',
      '&quot;','"',
      '&#039;',''''
      ]);
if not isTemp() then
  begin
  comment:=cmt; // quite easy
  exit;
  end;
....

although in reality the previous conversion is not necessary, there is the problem of the codification of the languages of certain languages and their restitution.

an example is better than all explanations

how to define  comments in Russian characters, store them, and restore them correctly to the web page

this comment как возможная функция saved as %EF%B7%90%D0%BA%D0%B0%D0%BA %D0%B2%D0%BE%D0%B7%D0%BC%D0%BE%D0%B6%D0%BD%D0%B0%D1%8F %D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F%EF%B7%AF in comments file

the question is how to force the creation of comment files in UTF8 and not in ANSI by default

[rejetto]

First of all, sorry for my misplaced comment

don't worry at all, i perfectly understood the situation and took absolutely no offense or whatever.
Just as a side comment on the planned obsolescence, that's a very complex matter and i cannot discuss it extensively, i want just to say that the new version of the programming language has little to do with it. Each p.language, the abstract concept, have always evolved without requiring any faster computer by itself. So ES6 doesn't require a faster PC by itself. Of course this is entangled in the process of obsolescence, but it's just a pawn. We can have better software with old computers, within limits. Then other factors occur causing the obsolescence we know. While some of these factors are malicious, my opinion is that most are not.

I have a possible solution to all this: perhaps this could be fixed doing a small routine, that detects if the browser doesn't support "the => arrow functions" (or other 'ECMAScript 6' expressions), and then it 'dynamically translates' those functions/expressions with older JavaScript code. Doing this, you only do that routine once, and you don't have to change every function. What do you think?...

Sadly the translation is not as trivial as it seems. The software to make the conversion is big, and in general the effort is not worth the result.

[rejetto]

same bug  in previous versions,  the offender is discovered, it is necessary to correct the setcomment function of the template

        function setComment() {
            var value = it.find('.comment-text').html() || ''    // change .html() by .text()

thanks, the solution becomes complete simply by removing the {.encode html.} in the [ajax.comment]