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

    16-Pearl
    January 23, 2011
    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




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