nk4um

Hi Tony,

I'll try your solution, it gives me control what a template is allowed to do.

Thank you,

Stefan

Hi Stefan, if all you're after is a change in syntax of the source TRL template then I wouldn't suggest constructing spaces to create aliases for the passed arguments. There is much more elegant, in my eyes, way to achieve what you want.

I would create a transform accessor that takes your alternate form of TRL template, let me call it STRL (Stefans Text Recursion Language) ;-) and transforms it to plain old TRL. It's easy to do this with regular expressions.

Then we would give this transform a grammar. A simple way to do it would be an active grammar like:

active:STRLtoTRL+operand@res:/myTemplate.strl

then when you call TRL you call TRL with a template of this identifier rather than just "res:/myTemplate.strl". There are many options, in terms of grammars to make this more concise though.

Cheers, Tony

Hello Tony,

I want to do the following:

• use TRL and XRL as templating language as view for my application
• all the data must be sourced before the view gets them, the view is not allowed to source data, e.g. active URIs are not allowed
• the references to the data must be as simple as possible like $(title) and have a uniform notation, so the creator of the template doesn't have to know where the data comes from like $(arg:title) or $(res:/title).
• create a clear documentation for each template which variables can be used

I want to use one endpoint per template, that collects the data, calls TRL/XRL with the appropriate template as as argument and returns the resolved template.

To push the data into the template I could try to

• construct a space as you mentioned (what are the disadvantages?)
• or adjust TRL/XRL so that calls by the template are resolved as arguments too. E.g. if a call to 'title' can't be resolved, maybe one to 'arg:title' can be resolved.

Thank you,

Stefan

Hi Stefan,

if you SOURCE "title" then you are going to be looking to resolve an identifier with the identifier "title". When arguments are added to requests they are put into a pass-by-value space with an identifier "arg:title" so that is how they must be sourced. I.e. you must use ${arg:title} in TRL.

Now it is possible to create your space, add resources with an idenfier of title to it and then inject it into the request scope of an issued request. Then you could resolve a resource with an identifier of "title". But is that what you really want?

Cheers, Tony

Hello,

I do have a problem in understanding the the pass-by-value construct. The documentation says:

When invoking functions and other services that might require arguments it
is often necessary to pass a specific value or literal representation.
[...]
Each specific value or literal representation should then be given a 
unique identifier and placed into the dynamic space. The unique identifier
for representation should then be specified as the appropriate argument
in the identifier of the function evaluation request.
[...]

Examples: NetKernel Foundation API: INKFRequest.addArgumentByValue()
Literal layout

I tried the following with TRL and a template that requests $(title).

req = context.createRquest("active:trl");
req.addArgument(template, "res:/something.xml");
req.addArgumentByValue("title", "The Title");
req.addArgumentByValue("content", "The Content");
context.issueRequest(req);

The result is an exception because of a failure to resolve 'SOURCE title'. In the scope of the resolution as shown by the exception there is a space '(pbv(title, content))'. Why does the resolution fail?

The objective is to use TRL in the described way without having to write something like $(arg:title) in the template.

Thank you,

Stefan