Skip to main content
1-Visitor
January 19, 2011
Question

accessing composition request profiling from the FOSI on PE

  • January 19, 2011
  • 12 replies
  • 1852 views
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

    18-Opal
    January 19, 2011
    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


    18-Opal
    January 19, 2011
    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


    naglists1-VisitorAuthor
    1-Visitor
    January 19, 2011
    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.

    naglists1-VisitorAuthor
    1-Visitor
    January 19, 2011
    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.

    January 20, 2011
    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?)
    18-Opal
    January 20, 2011
    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


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

    Thanks again!

    -J
    naglists1-VisitorAuthor
    1-Visitor
    January 22, 2011
    > 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
    18-Opal
    January 22, 2011
    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


    naglists1-VisitorAuthor
    1-Visitor
    January 22, 2011
    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 😉