On Nov 23, 2004, at 12:23 AM, Leszek Gawron wrote:
Miles Elam wrote:Hmm what did you mean by that? JXTT is not parametrizable with src so did you mean:Try this on for size: <map:match type="regexp" pattern="document-(\d+)"> <map:generate type="file" src="mytemplate.jx"/> <map:transform type="jxtemplatetransformer" src="getDocument({1})"/> <map:serialize type="xml"/> </map:match>
<map:match type="regexp" pattern="document-(\d+)"> <map:generate type="jx" src="getDocument({1})"/> <map:serialize type="xml"/> </map:match>
No, my example was a hypothetical, not based on current code.
What if there was an alternate scripting contract? One that instead of requiring a sendPage, sendPageAndWait or redirect-to call, requires that *none* of these exist in the code path and that an object context is returned like the parameter of the sendPage* functions.something like this was already possible when it was not required for the flowscript function to invoke sendPage or sendPageAndWait. Then you could do something like:
function getDocument (docid) {
var myObject;
//
// *** hypothetical Hibernate call with a lookup via docid,
// assignment to myObject and other sundry details ***
//
return myObject;
}
<map:match pattern="someUri"> <map:call function="myFunction"> <!-- the function stores result in request attribute --> <map:generate src="request-attr:mydata" type="jx"/> <map:serialize type="xml"/> </map:call> </map:match>
No, that's not what I mean. That is subverting an existing contract. I don't want to alter the map:call syntax at all. It is great the way it is. I'm talking about establishing a new scripting contract -- a separate contract -- one that specifically forbids the use of sendPage*() and redirect-to().
This is like the function was an action really (which I found kind of nice for fasst scripting actions - I usually used XSPs for that one but the startup time was killing me, syntax also).
Now this call wouldn't succeed. Every call to a function must result with sendPage.
With the current flowscript, yes. Once again, talking about a different contract. I'm talking about finding some middle ground between a continuation-based flow model and the piecemeal sitemap/action model. In other words, the ease of writing flow -- which let's face it, is much more convenient than writing an action -- with a reduction of scope where redirection is not possible, only data gathering.
I proposed the "src" attribute as a data vector because (a) that is an accepted data source input point, (b) a sitemap component would have to be rewritten anyway to take advantage, mitigating the action alternative, and (c) it's easier for users to conceptualize while simultaneously respecting SoC. For a quick "get-in-get-out" problem, this would work. Once they need to go to multiple pages and alternate outputs, they graduate to map:call and the continuation model; They switch to a different contract that fits their needs.
This would also serve as an easy introductory alternative to XSPs. Not only does it respect SoC better than XSPs (which don't respect it at all), but the code reuse in flow would be a boon as well. Continuation code could call the simple data gathering function they've already written. The developer simply cannot write a simple data gathering function that calls continuation code. It's a fail-fast model where the developer knows very quickly that they're doing something wrong. It's also a more natural transition from the simple publishing model to the interactive data processing model.
Function sources are a very specific, directed option unlike the use of an action. With an action -- let's say an action was made to make non-exiting/non-continuation function calls -- you are talking about more complexity and far more side effects since the flow changes would still need to be made, a sitemap component would still need to be retrofitted, the sitemap would be harder to read, the sitemap syntax wouldn't necessarily tell you which components would be consuming the action's info, etc. Also, what is the use case for data injection that spans multiple components but only injects the same content? The actions I've found the most useful are the resource-exists and the authentication/authorization actions. These dynamically alter the structure of the pipeline. The actions which have historically provided information have for the most part been subsumed into input modules. Why? My take on it was that use of actions for content gathering muddied the sitemap semantics and required all sorts of {../../../1} configuration headaches.
<map:transform type="foo" src="getBar({1})"/>Simple, descriptive, and limited in scope. But the exact syntax is IMHO irrelevant. It's the concept I'm more concerned about. If it were a comma separated list like
<map:transform type="foo" src="getBar,{1}"/>or considered another input source
<map:transform type="foo" src="func://getBar/{1}"/>or parameters were specific to the transformer
<map:transform type="foo" src="getBar">
<map:param name="src-param1" value="{1}"/>
</map:transform>...although I can't say I cared for the last two. The second to last is ripe for URI abuse. The only major issue with the first two is that commas become reserved characters.
- Miles Elam
