cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X

accessing composition request profiling from the FOSI on PE

naglists
1-Visitor

accessing composition request profiling from the FOSI on PE

Hi,
This may be a familiar topic as I have raised it a couple of times. The most
recent was in August, I think, as I was trying to include profiling
attributes and values in a FOSI's semantic table. Thanks to an off-list
suggestion from Brandon and an on-list one from Clay, I have managed to make
this work if composition is conducted locally. I have not been able to do it
on Publishing Engine yet. I'm hoping someone can stand on my shoulders and
see over the top.

To do this local by way of Print Composed you need three components
(presented in reverse order, processing-wise):
1) Your FOSI or, presumably, Styler code. Here is my FOSI attribute test:
<att>
<fillval attname="yourpackage::getprof" attloc="system-func"&lt;br"/>fillcat="savetext" fillchar="conrule">
<charsubset>
<savetext textid="gotprof.txt">
<usetext source="\asdf" \,gotprof.txt,!<newline="/>!"
placemnt="before"></usetext>
</charsubset>
</att>

Which references:
2) Your system-func code:
# the following function retrieves an environment variable stored
# by composepreprocesshook function and returns it to FOSI for formatting.
package yourpackage
function getprof() {
# response('in getprof: main env mytest = ' . main::ENV["MYPROF"]);
return main::ENV["MYPROF"]
}

Which calls the ENV variable saved by the composepreprocesshook:
3) composepreprocesshook add_hook and function to handle hook:

# this add_hook can go anywhere add_hooks are handled
add_hook("composepreprocesshook", "saveprof::saveprof");

# this package saves profiling info to be caught by system-func code in
yourpackage.acl
# which is in turn called by fosi to output based on profiling.
# need to figure out how to replicate this behavior on PE.
package saveprof

function saveprof(a,b,c,d[]) {
#response('a/docid = ' . a);
#response('b/outputtype = ' . b);
#response('c/userinitiatedornotboolean = ' . c);
#response('d[ "prof.logicalExpression" ] = ' . d[ "prof.logicalExpression"
]);

#the following could be as complicated as you want to make it.
#publishing the actual contents of d[ "prof.logicalExpression" ] may be
#possible but the content was upsetting FOSI. May have been an SGML paste
#option thingy.
if (index(d[ "prof.logicalExpression" ],"ProfileAttributeORProfileValue") >
0) {
myprofilingispresent = "yes"
} # end of if
else {
myprofilingispresent = "no"
} # end of else

main::ENV["MYPROF"] = $myprofilingispresent;
# response(main::ENV["MYPROF"]);
} # end of saveprof


OK OK OK Cool and all that.

BUT I need to do this ON Publishing Engine which is where all our production
formatting occurs.

I can reuse the FOSI fragment and the system-func without trouble. I can't
find an elegant way to access the profiling information on PE. I suspect I
could modify system ACLs (or less dramatically, override a function that
processes profiling information) to save to that ENV variable. However, I am
hoping someone knows of or can see a way to add my own code that simply
reads a variable or array or other structure in PE's memory to write out the
ENV.

So, on PE, audience.acl (located in ../PE/packages/tools/audience.acl), has
a function (create_profiled_vdoc_custom) that creates the PE version of d[
"prof.logicalExpression" ] on line 368 (in version 5.3 m110) using the
following code:

params["prof.logicalExpression"] = create_logical_string(audience, savedoc);

I am pretty sure if I issue this:
main::ENV["MYPROF"] = params["prof.logicalExpression"]

Immediately following line 368, my system-func and FOSI code will work. I
just, as I said before, am hoping not to override the function or copy the
ACL into my doctype or (heaven forbid) modify the system ACL directly.

Any thoughts?

Thanks, Brandon, Clay, and anyone else whom I have forgotten that
contributed to that last (or some earlier) conversation on this.

Code caveat: I have retyped some here in the e-mail to obscure corporate and
(independently) puerile variable names. No guarantee I did that perfectly or
consistently. That said, the Print Composed solution was actually working in
practice for me. Please test before deploying anywhere important!

--
Paul Nagai
12 REPLIES 12

Hi Paul-



I admit I didn't quite follow all the code you pasted or exactly what
you are trying to do (so feel free to correct me if I've misunderstood),
but I think maybe the composition framework hook might get you where you
want to go. It's a way to run custom code at various points during
composition. Check the documentation for details (Arbortext PE
Programmer's Guide->Arbortext Composition->The Composition
Framework->The Composition Framework Hook in the TOC, or just search for
"composition hook").



This is assuming you're using 5.4, I don't think the composition hooks
are available in earlier versions.



--Clay


Ah, OK.



Another thing that comes to mind would be to maybe embed the information
you need as a PI in the document (in the client) before sending it to
PE, rather than trying to store it in the system environment and then
read it back during composition.



--Clay


Thanks, Clay. I'm in 5.3, but I'll see if I can read-up on the composition
hook. Maybe I'll have to wait 'til we can upgrade to get it the way I'd like
it.

I hadn't thought of that. I had thought about intercepting the document
being sent to PE and modifying attributes in it according to the values
compsepreprocesshook captures.

I had just searched through the PDF for "composition hook" in the copy
of PE Programmer's Guide that I'd just downloaded. I didn't find
anything. The only thing returned on a search for "hook" was mention of
calling the preprocessing hook for the function compose_for_type(). Is
this what you were referring to?

This one was released at 5.4 F000, is there a newer version (or perhaps
the updates are in the help center?)

Hi Jason-



I checked the release notes, looks like the composition framework hook
wasn't added until 5.4 M030. Sorry about not being specific enough.



--Clay


That's cool, and it helped me out, I have the right one now.

Thanks again!

-J

> So, on PE, audience.acl (located in ../PE/packages/tools/audience.acl), has
> a function (create_profiled_vdoc_custom) that creates the PE version of d[
> "prof.logicalExpression" ] on line 368 (in version 5.3 m110) using the
> following code:
>
> params["prof.logicalExpression"] = create_logical_string(audience,
> savedoc);
>
> I am pretty sure if I issue this:
> main::ENV["MYPROF"] = params["prof.logicalExpression"]
>
> Immediately following line 368, my system-func and FOSI code will work. I
> just, as I said before, am hoping not to override the function or copy the
> ACL into my doctype or (heaven forbid) modify the system ACL directly.
>
For those keeping score at home ... this, it turns out, did NOT work. I was
unable to set / retrieve environment variables as expected (desperately
hoped). My testing got cut shorter than I would have liked, but I'm
wondering if it failed because various e3 processes are running under
different credentials in different environments.

--
Paul Nagai

Hi Paul-



Is there a particular reason you are trying to use an environment
variable for this? Would just a global ACL variable work (maybe in a
custom package to avoid potential name collisions)? What about adding a
PI or a namespaced attribute to the root element of the document?



--Clay


I actually tried a global acl var, too. No joy.

Intercepting the profiling and changing the document before submitting it to
PE is a reasonable, in the cold rational light of a programming day,
strategy, so there is probably a bit of bullheadedness here. It just seems
so crystal clear to me that the stylesheet should have access to the
profiling chosen at composition time by way of a system-func or some other
similar method. So I'm maybe a bit hellbent on getting there by that
strategy even if it means mucking about in the code.

I do have control over the DTD and we have been using elements to cue the
stylesheet to composition profiling for a long time so it isn't that I can't
get the end-result functionality I want ... I just can't get it the WAY I
want it.

[tantrum goes here]

Sigh. Back to work. On a Saturday. So that's how that goes 😉


Hi Paul,



With PE we have also had issues getting parameters passed in at composition
time. For this big customer project one of our developers ended up
implementing his own composition framework just to get around that problem.
Eg. his own version of f=convert J



Here's an idea then. When the profiling is being called, is there any way to
have the profiling information stored in the markup, then you can access it
that way? If there is no option in the profiling code, you could update the
Arbortext profiling code to leave a telltale. Or, go the low-tech approach.



Eg. in the original markup

<indicator type="profile1"/">

<indicator type="profile2"/">

<indicator type="profile3"/">



Once "profile2" is applied, the indicators for profile1/3 disappear. Nasty
workarounds are often the easiest. J



-G




Hey Gareth,

I admire the audacity of rewriting f=convert. But, uh, I'm not gonna go that
route. I already do the ugly (profile1, profile2, more or less as you
suggest) ... which is easy since I have control of the DTD. I just haven't
been able to give up looking for a back door.

I also haven't tried as you and others have suggested, modifying the XML
post-composition request, pre-delivery to PE. I'm still thinking about that
back door. I haven't fully formed an opinion whether a client-side content
tweak is "morally" better than cheating the DTD.

Ah well ... perhaps I should just try to embrace the if it ain't broke
philosophy.


Announcements

Top Tags