addedValues Plugin

...Powerful Free! Database Expansion for Manila
logoBottle:

(1 or more words)


Get tropes here!
Click to see internals
Report bug


Vaetertag, fete des peres

sitepic_vaetertag.ch.jpg:
Viewable with Any Browser

Members
Join Now
Login

Static Rendering

Mnila websites may be static rendered, see Userland documentation , for example http://frontier.userland.com/manila/staticRendering/ and http://frontier.userland.com/manila/staticRendering/developersGuide.

Addedavlues can render static pages with queries. There are 2 issues which make static rendering of such pages problematical. First, the query may return a different hit list each times it is run, for example, if might use randomIndexValues. This problem is resolved by ignoring it; on the basis that if you static render a page, you understand it won't change until the next static render. The second issue that a page whose query returns more hits than fits on one run of the search report will have next and previous page links. But these link use the same url with a different searchargs. Static servers typically do nothing with searchargs, so the 2nd and subsequent report pages are unavailable. One way to deal with this issue is to write the search result 'pages to a reserved directory (addedValues) in the static site and using server side include and conditional directives to render each static page . This technique works well for Apache 1.2 or higher, but does not work for Microsoft IIs, due the lack of conditional directives. So the choice of static server determines whether, and how, addedValues can render pages with queries. For this reason, addedValues can support a range of static renderers and there is a new panel on the preferences page to select the appropriate renderer. No renderer is shipped by default, but one implementing the Apache 1.2 solution described above, is available from the author.

Web pages served by a static server cannot be interactive, i.e. have forms , unless the submissions are passed to a dynamic server. Appropriate addedValues forms can now work this way , their submissions are directed back via Frontier to addedValues and the response pages are generated dynamically but links on those pages generally point back into the static site. Appropriate means search forms and user transaction forms, but not edit this page or message/gem update forms. Because static sites are by default, public, Manila must render static pages as they would be seen by non logged in visitors; for addedValues forms that means the forms are rendered in their public form also.

Pages rendered with the serverReportURL macro are rendered to the static site in a reserved directory (addedValuesStatic) .

Managing the Render process

n Manila itself, you always render paths in the site structure, one path or a directory. In complex Manila/ addedValues websites, it is sometimes advantageous to render more than one page (URL) from the same raw content by flowing it thru different reports and templates. In these sites, when the content is changed, typically you want to re-render all the paths. In addedValues you request the rendering of stories, and addedValues determines which paths correspond to each message number in the site structure and renders them all. This allows you to detect that the static pages were rendered before the content last changed, and to use an updater to set a flag in each message, perhaps automatically with an after new story or an after edit story trigger. That flag can be an indexed boolean message variable, which in turns permits writing queries to generate list of pages that need to be rendered. These queries can be used with a picklist report with a [[picklistrender]] button for on-demand rendering, or as a periodic batch process with a timed task using the renderMessage action.

Limiting stories that are rendered

The renderMessage timed task action supports 2 configuration options (unique to each website it is used in). flHonournoStaticRender is a boolean flag that means do not render any relative path in the site structure if it, or a parent, has a path attribute noStaticRender with a value true. This is intended as a way to mark stories and categories as non-renderable (by addedValues, Manila does not support this flag).

renderCapableCohorts is a list of cohorts. If a message or path is controlled to be accessible to only certain cohorts, addedValues will not render that message or path unless one of the permitted cohorts is in the list renderCapableCohorts. addedValues knows nothing of how the static web server might restrict access, the assumption is that you would not allow controlled message or path to be rendered unless you had resolved that question.</P.

Manual renderings initiated from picklists respect the constraints, but do not allow overriding the message an path attributes.

Rendering RSS feeds

addedValues can render its RSS feeds to the static website. There is preference, Static render RSS feeds?, off by default, to enable this. The path to a feed flowed thru report reportname, with hits selected by query queryname will, by default, be
/addedValuesStatic/xml/reportname/queryname.xml
but the directory addedValuesStatic/xml can be overridden for each site on its preferences page.

Static sites are by definition public, so the feed contents is restricted to publicly visible messages. When a page with an RSS link is rendered, addedValues constructs a Timed Task , with a name RSS_reportame_queryname, to potentially render the feed once an hour from that point. Potentially, because no render is done unless a change requires it. Managing editors can view Timed Tasks and see the last 10 render attempts and their success, by highlighting the timed tasks for the feed, and clicking Show Options. The render times can be rescheduled and disabled there also. The feed rendering requires an enabled Timed Task action - renderFeed - which an be configured from the addedValues admin site addin page. If you run addedValuesPI.install() in a quickscript it will be configured and enabled automatically.

b305 - page rendered with the serverReportURL macro are now rendered to the static site in a reserved directory (addedValuesStatic) .

fc2 - This version contains significant new implementation to manage static rendering. In Manila itself, you always render paths in the site structure, one path or a directory. In complex Manila/ addedValues websites, it is sometimes advantageous to render more than one page (URL) from the same raw content by flowing it thru different reports and templates. In these sites, when the content is changed, typically you want to re-render all the paths. In addedValues you request the rendering of stories, and addedValues determines which paths correspond to each message number in the site structure and renders them all. The new features in this release allow you to detect that the static pages were rendered before the content last changed, and to use an updater to set a flag in each message, perhaps automatically with an after new story or an after edit story trigger. That flag can be an indexed boolean message variable, which in turns permits writing queries to generate list of pages that need to be rendered. These queries can be used with a picklist report with a [[picklistrender]] button for on-demand rendering, or as a periodic batch process with a timed task using the renderMessage action.

fc2 - picklist reports can now optionally have a Render (this page) button; which is added to the picklist page or group layout using [[picklistRender]]. If clicked , checked items on the picklist reports results page - which have one or more paths in the site structure - are rendered to the static site. When a message is rendered, pages are rebuilt for each relative path; hitList candidates that have no paths are skipped, as are paths for which the path Attribute noStaticRender is true. This feature is a programmable "render this Page" button , with the advantage that a query (or a search form) can be used to select candidates. The option is not available in a website unless static rendering is enabled for the website. Due to the limitations of Manilas static rendering implementation only one static render can be active on the server at any one time., if a second is attempted addedValues issues an error.

fc2 - a new macro, timePathStaticRendered, takes a string parameter is a relative path within the site structure, and returns the time it was last rendered. It requires a small change to Manila to function.

fc2 - a new message builtin, isStaticRenderCurrent, a boolean computed value return true if all the paths rendered in the site structure have been rendered after the last change to the message. isStaticRenderCurrent is a computed variable because addedValues does not know when the site structure changes or when the static site is changed. However , in a trigger another conventional boolean can be set after a new story or changed story using an updater with an expression such as values(siteStructurePaths)>0 and not isStaticRenderCurrent. It requires the same small change to Manila to function, as does the timePathStaticRendered macro .

fc2 - a new timed task action, renderMessage, is shipped with addedValues. It renders all paths found in the site structure for each message in the timed task hitlist, which do not have the path attribute noStaticRender with value true.

fc3 - the renderMessage timed task action has been extended to allow 2 configuration options (unique to each website its is used in). flHonournoStaticRender is a boolean flag that means do not any relative path in the site structure if it, or a parent, has a path attribute noStaticRender with a value true. This is intended as a way to mark stories and categories as non-renderable (by addedValues,Manila does not know of this flag). renderCapableCohorts is a list of cohorts . If a message or path is controlled to be accessible to only certain cohorts, addedValues will not render that message or path unless one of the permitted cohorts is in the list renderCapableCohorts. addedValues knows nothing of how the static web server might restrict access, the assumption is that you would not allow controlled message or path to be rendered unless you had resolved that question. Manual renderings initiated from picklists obey the same rules.