Scripts in Styler

[dthursfield]

In the Editor manual ist says you can access scripts out of the Styler using Xpath with one of the following expressions:

- _js:eval()

- _acl_eval()

It also supports an example for starting a Jscript ( _js:eval("new Date().getFullYear()")), which works out just fine.

My problem now is, that I just can´t figure out how to call a function, which needs to be deliverd a parameter.

Anyone?

To substantiate my problem:

I don´t know how to deliver a parameter that is taken out of the document, which ist to be styled. For example I want to deliver an attribute out of the root element to the function and return a different string depending on the actual attribute.

Nachricht geändert durch Daniel Thursfield

[ClayHelberg]

Hi Daniel--

I don't think you need scripting for this. The use case you describe is one best handled (IMO) by adding conditions in your styler element, I think. For example, suppose you have a language placeholder called <lang>, and you want this to be rendered as a human-readable language name, based on the xml:lang attribute of the root <doc> element. To do this you would have something like this:

Element lang:

Condition: (Can either use an ancestor attribute test, or XPath) /doc/@xml:lang='en-us'

Generated Text: "US English"

Condition: /doc/@xml:lang='de'

Generated Text: "Deutsch"

Condition: /doc/@xml:lang='es'

Generated Text: "Español"

etc.

Does that help? If I've misunderstood the use case, please clarify.

--Clay

[dthursfield]

Dear Clay,

first of all thanks for your reply. As you said this would be a typical use case for conditions. I just wanted to find a way to save me some work. In my case not only the lang-attribute is necessary, but also the appearance of an element which might differ in its type-attribute shall be checked. Which would end up in about 150 conditions. Something like:

first condition:

language is english, info[@type='type1'] exists, info[@type='type2'] exists,info[@type='type3'] exists.

second condition:

language is english, info[@type='type1'] exists, info[@type='type2'] exists,info[@type='type3'] doesn´t exist.

...

and so on.

If you multiply all possible languages with all possible combinations of existing/non-existing info-types it adds up to a whole load of conditions.

That´s the reason why I tried to call a function delivering the @xml:lang as a parameter, as well as @type.

Here´s an aexample of how the function would look like (no output so far):

function getLangData(type,lang,doc){

try{

if(doc.getElementsByAttribute("type",type,1).getLength()>0)

{

Application.print(type +", " +lang+";\n");

var string = String(type +", " +lang+";\n");

return string;

}

}

catch(e){Application.print(e)};

Greetings Daniel

[ClayHelberg]

Hi Daniel--

I have two thoughts about this:

1) Are you testing on xml:lang in order to do localized generated text? If so, Styler has a built-in mechanism for managing translations of generated text. Search for "managing translations of generated text" in the Help Center for information on this. If you can use this mechanism to handle the xml:lang piece of your problem, then you only need conditions for the type1, type2, type3 attributes, and you shouldn't have to worry about the large number of conditions you mentioned.

2) If you really want to go with the scripting route, I think the way to pass parameters to a function call would be by using AOM function calls and/or adding literal strings (derived from XPath subexpressions). For example, if you want to call your function as described above, you could try something like this:

_js:eval(concat("getLangData('",@type,"','",/*[@xml:lang],"', Application.activeDocument)"))

This will pass the value of the type attribute for the first parameter (using XPath to get the value and then passing it as a string to the JS call), and the xml:lang attribute from the document root element. It will then tell JS to use the Application.activeDocument property to get the current document object.

One thing to keep in mind is that scripts like this in stylesheets have the potential to significantly impact performance of publishing. A poorly-written script can bring your publishing process to a slow crawl. If you see publishing performance plummet after adding scripts, you may need to reconsider a different, more "native Styler" approach.

--Clay

[dthursfield]

Hi Clay,

I had already read the article "managing translations of generated text" before I posted my question here. I guess PTC assumes there are no multilingual documents created with AE.

The built-in mechanism only works with documents including one language. In my case the document includes severals languages, where in each language there is a place for the generated text. I think you can´t possibly manage that without either this load of conditions, or a script.

So I might just try the scripting route. I guess I just somehow got it wrong with the quotation marks in my function call delivering the parameters.

I will try out your 2nd suggestion and come back to you to tell you about my result.

Last I want to thank you for your quick replies.

Kind regards

Daniel

[ClayHelberg]

Hi Daniel--

I think you have missed something in your reading of the documentation for managing translated gentext in Styler. Styler can easily handle multi-lingual documents, inserting the correct localized text for each language based on the language attribute for the nearest ancestor element. For example, if you have translated your generated text strings into French and German, and you have something like this:

<note type="warning" xml:lang="de">Nicht storen</note>

<note type="warning" xml:lang="fr">Ne pas deranger</note>

Styler will insert the localized string "Vorsicht" for the first para and "Avertissement" for the second.

--Clay

[dthursfield]

Dear Clay,

as romissed I come back to this again. We completely changed our tactics in this case and are now creating a Ditaval-File during runtime depending on which languages are used in the document. So we now completely insert the various texts and just "hide" them during production. This seems to be the easiest way for our use case.

Thanks for all your help again.

Daniel