RealTime Template Compressor

[ShiningArcanine]

Hey could someone port this to vB3:

https://vborg.vbsupport.ru/showthread.php?t=56589

I'd really really like this.

[Logician]

When time comes, it will be ported to VB3 by its author.

[Koutaru]

thanks Logician

[Logician]

I didnt work on this yet so this is just a thought but this hack can be problematic in VB3 though. VB3's javascript/DHTML structure is more sophisticated than VB2 (eg. WYSIWYG post area etc.) and removing spaces/new lines can cause some bugs. We'll see when I start to work on it.

[Andreas]

I think it might be a good idea not to do this realtime, but when the templates are being parsed for conditionals (eg. in process_template_conditionals).

This way there would be no overhead when serving pages

Does anybody have figures about the decrease when GZIP (level 1) is enabled?

[ShiningArcanine]

Originally Posted by Logician

When time comes, it will be ported to VB3 by its author.

I'm sort of new to the forums so I had no clue you were still around to port it. ^_^;;

[Logician]

Originally Posted by KirbyDE

I think it might be a good idea not to do this realtime, but when the templates are being parsed for conditionals (eg. in process_template_conditionals).

This way there would be no overhead when serving pages

I didnt check VB3 algorithm extensively yet but I'm not sure if it helps. The hack needs to apply a "preg_replace" to the page output code and I think it wouldnt matter in which step and where you apply it. It will add a very small amount of overhead at the moment it runs regardless of its location, dont you think?

The only workaround is to compress the template when it is formed and save the compressed form in database. It will save the overhead then but I think it will be a very bad idea because templates will be unreadable to the admin in the edit page as well.

[Andreas]

@Logician
It you take a look at the table template, you will see that vB3 keeps two versions of each template in database: Unparsed for editing reasons (field template_un) and a parsed one (template) which is being used for actual page generation.
So if you put your code into process_template_conditionals the compression will be only done "once" (each time a template is being saved to database).

This way, there would be no overhead when serving the pages, but the original layout (for editing) could still be preserved.

[Logician]

ok great, I'll look into it, thx!

[Princeton]

Originally Posted by KirbyDE

@Logician
It you take a look at the table template, you will see that vB3 keeps two versions of each template in database: Unparsed for editing reasons (field template_un) and a parsed one (template) which is being used for actual page generation.
So if you put your code into process_template_conditionals the compression will be only done "once" (each time a template is being saved to database).

This way, there would be no overhead when serving the pages, but the original layout (for editing) could still be preserved.

that's a great idea!
-----------------------------------
Jelsoft has taken giant steps to make vB3 more adaptable; but, it has taken quite a few steps back when implementing javascript into to many of it's pages. They should have placed all javascripts into external files.

To take full advantage of the compressor you should compress EVERYTHING (even javascript and css). However, if you do this the user should be aware that they must remove all comment tags from any javascripts found within templates.

This could be an option to the user - COMPRESS JAVASCRIPT?, yes/no, 1. And give instructions to search for <!-- || --> || // -- they all must be removed.

I'm looking forward to the new release.