It is possible to set a 'view' in the Template, which apparently bypasses the caching and degrades nested blocks.

Well, what is that exactly, a 'view'?
And second, why and/or when would I use such?

I know it is described (and implemented) in the static page plugin.
But I get lost while reading their docs.

You are correct a view bypasses the regular caching system.

The staticpage plugin allows you to set a page as a template. This template can then be assigned to other pages. These other pages then must use XML to define variable names and what content should be assigned to those variable names.

When you visit these other pages on the website the staticpages plugin then takes the page template (as a view so it can support the template logic and variables that it automatically passes) and uses it as a base and applies the variables from the page you are viewing to the template.

This allows webmasters to easily setup, for example, product pages that can all use the same template and makes management of the layout of your pages much easier.

You can also set the staticpage to use caching if you wish as well so the page when visited does not have to be generated each time.

If a staticpage template is used, the logic code is also looped about 3 times (I believe). This allows for any nested autotags to be run that may introduce additional content that may contain template logic or other autotags.

---

One of the Geeklog Core Developers.

Let me try to summarize my thoughts below. See if I can copy the intentions.

Basically a script is run that creates a template object by pointing to a FILE; a template file, say a 'tFile'. Such a tFile is assigned a name, say tName.
The script declares variables with values to be substituted in the tFile. Call them template variables, say 'tVar'. The template object tricks itself by treating a tName as a tVar.
The script commands the template object to do the parsing of a tVar. Normal usage is that the target tVar equals the tName, so we can say 'parsing the tFile'.
Ergo, the tFile is parsed for tVars and their values are substituted. A tFile is a file and tVars are an array. The HTTP-request targets a script that loads a template and fills it with variables.

Now, there is a static page ( A ) being a template, and another one ( B ) containing the variables. This A is called a 'view'. But A is a file and B too.
My obvious guess is that B must be converted to an array with tVars. In which case, A is a tFile and the template object can be commanded to parse A for B. The HTTP-request targets B, and that causes the loading of the template A and fills it with variables.

Well, why the bypass of caching? When A is a tFile (and nicknamed a 'view' ), it should be cached. Because that is what the caching is for.
In the example of the webmaster, having an easy setup, there is the mention of (a lot) product pages being similar in design. Here the result of parsing A for B is introduced: a similar product page, identify it as (C). I do suspect that the intention is that all these C instances should be cached (or is 'generated' a better wording?). So, the HTTP-request should target C.

However, C does not exist. As far as I understand this, the http-request targets B, which loads A as a 'view'. This means that B will be cached and uses a cached copy of A. I do not see the necessity for the concept of 'view'.
And, as far as I understand functions.inc of the static pages plugin, the code to handle a 'view' is just a workaround to save a file load, and instead parse (A) all the time, which is done 2 times, btw. Referring to the file load saving: I think this is a misunderstanding. Maybe is backward compatibility the key factor, as the code comments suggest?

Please notify me where I go wrong.

Hi Remy,

It has been a while since I have modified the code and really looked into the template cache library so I am a little fuzzy on the details.

Maybe some things where done to keep everything compatible.

A - Is the page being requested. All the settings on this page determines the output like title, meta, block, cache, etc... It can be set to use a template ( B ). If so the content of the A page will contain variables (using XML). This was the easiest way to do it at the time.
B - Is the template (it cannot be requested directly)
C - Is the result of combining A with B

When A is requested by a visit one of 2 things can happen.

If the cache instance for the page is turned on (open the static page editor and look for the cache setting) then the system will look for the final cached version of A page (which is a cache instance of the page and would contain C)

If caching is disabled for A page then the content would have to be generated to create C each time. Obviously this is very expensive to do so Caching for the A page should be enabled.

Some things that might be confusing is that as a bit of a Hack for the Geeklog search, the "sp_content" column for pages like A will contain a copy of C (but only one copy based just on one set of security permissions) which is used for when a search happens in Geeklog. Depending on when this page is created and the permissions on it, security info has the potential to leak as explained here:

https://www.geeklog.net/docs/english/staticpages.html#desc_includesearchtemplate

If this is the case then Search should be disabled for the page. (which is now possible per page in Geeklog v2.2.1sr1)

---

One of the Geeklog Core Developers.

Where A is the product page with variable data and B is the template to be used by A.
This is exactly my confusion. What is a 'view'? And why bypass caching?

I learned that A is called the 'view' and that it bypasses the caching.
Now it is written that A should be cached.

>> Now it is written that A should be cached.

Using a cache instance. This is to speed things up.

The template caching library was built for themes and their template files. At this point Cache Instances was added as well for things like article content and staticpage content

The ability for staticpages to combine one page with another was added afterwards. We have it use the the template library as well so we can use all the logic it provides (like the if statements, etc..) so much more is possible.

There is no point in caching anything except the final results and this is done with the Cache Instance.

---

One of the Geeklog Core Developers.

Aha! Now I understand where my confusion originates. It's the word 'caching'.
There is a cache, template caching and a cache instance. The discussion refers to these 3 slightly different concepts with the same wording: caching.

* 'cache' is a directory for temporary storage,
* 'template caching' loads and compiles template components within the template class,
* 'cache instance' is a creation by the running script.

To me, it was easy to assume that 'caching' was done within the template caching class exclusively. I also overlooked the fact that the CACHE_* functions did not belong to the class itself.

Anyway. Apparently a 'view' is the concept to bypass 'template caching'.
And the reason is that the script creates afterward a 'cache instance'.

$template->set_view is found in lib-article and in functions.inc of the staticpages plugin.

Sorry I didn't explain things better before

---

One of the Geeklog Core Developers.