freenet
Redesign first time wizard UI
I want to show a new form from issue 6020. Please do not look at the template engine; I will replace it with HTMLNode
https://freenet.mantishub.io/view.php?id=6020
I would totally love to have a decent template engine in Fred, I don’t know, FreeMarker, or Thymeleaf… :)
We have compared both engines and think that either of them is good for our purposes.
Does anyone in core team have a strong preference in favour of FreeMaker? If not, we would suggest to use Thymeleaf, since we worked with it before. However, since FreeMaker offers similar features, so we are totally fine to go with it.
Please let us know if it is ok to start using Thymeleaf. Also, if you are not sure, let us know if you’d like a more detailed comparison to make the choice.
According to https://github.com/mbosecke/template-benchmark and https://smarterco.de/java-benchmark-thymeleaf-2.1.4-vs-thymeleaf-3.0-snapshot/ , Thymeleaf is quite a bit behind other templating engines in terms of performance. Do you have experience with pebble? That seems to be roughly factor 10 faster than Thymeleaf and has syntax similar to django and makes it easy to build derived pages and to make it easy for designers to adapt pages.
In our case such performance might actually matter, because the server runs locally, so there’s little network overhead, and because many people run Freenet on pretty weak machines (and it would be great to get Freenet onto Freedomboxes).
This is not a strong preference, however, and if you say that Thymeleaf should work without problems within Freenet (with its congested threads: using velocity templates in the Winterface plugin was a bad surprise in slowness, but I did not trace where it came from), and that you’d prefer to work with it, then go for it.
Do you have experience with pebble? That seems to be roughly factor 10 faster than Thymeleaf and has syntax similar to django and makes it easy to build derived pages and to make it easy for designers to adapt pages.
In our case such performance might actually matter, because the server runs locally, so there’s little network overhead, and because many people run Freenet on pretty weak machines (and it would be great to get Freenet onto Freedomboxes).
Pebble also looks fine but I don't have experience with it (this is not a problem but I can't say how comfortable it might be).
Because the server runs locally, this is not loaded part unlike ordinary sites (there is much less page requests). But performance matters anyway.
To sum up: FreeMarker - oldest Thymeleaf - now more popular https://java.libhunt.com/compare-pebble-vs-thymeleaf Pebble - faster and smaller
It seems to me that all options are okey, and only personal preferences matter. I would like to try Pebble or choose Thymeleaf as I tried it before and everything was okey. Maybe you have any preferences in this?
In addition to pebble, slf4j and unbescape libraries were also required. I do not know exactly how they should be distributed properly. I put them in freenet-ext.jar If something is wrong, please let me know to correct
In addition to pebble, slf4j and unbescape libraries were also required. I do not know exactly how they should be distributed properly. I put them in freenet-ext.jar If something is wrong, please let me know to correct
We need to upload them into Freenet and add them to dependencies.properties so they can be retrieved from Freenet upon update (and before activating the update).
We need to specify the exact versions, retrieve and validate them via gradle (see dependencyVerification in build.gradle) and have them in dependencies.properties.
We should have several people separately validate the hashes of the libraries so we don’t push a version someone tried to smuggle into our dependencies by corrupting the jars we download.
marked as afterNextRelease because adding the dependencies needs more testing than regular changes — so I’d like to merge this for 1486.
I had to do 1486 as emergency release, because Java on Windows broke with our jna. We’re working on improving our dependencies workflow to make this PR safer to release (currently dependencies are scattered all over the place, so every updated or added dependency is risky). We won’t make it for 1487, though, because 1486 broke KeyUtils via a change to an API that should be internal but is exposed to plugins, so we don’t have time for the needed refactoring.
I resolved the conflicts via the online editor. I hope it didn’t break anything.