Skip to main content
N
naglists1-Visitor
1-Visitor
January 24, 2012
Question

are there limits on the number of allowed ACL variables or arrays?

  • January 24, 2012
  • 6 replies
  • 1350 views
Probably I'm just wiped after a long day, but I am processing six children
of an element with essentially the same code. Variables and arrays change
names following the names of the children. Child 5 fails. If I move child
5's code into the 1st position, it succeeds. Since all the time reading my
code for coding errors has eaten my day, I'm now going to quit. However,
tomorrow, if I don't see something Duh-Obvious when I get back to it ... my
question stands.

And what else am I forgetting to think about going down that same track ...
code that works/fails depending on its order?

--
Paul Nagai

    6 replies

    K
    KarlJohanKleist1-Visitor
    1-Visitor
    January 24, 2012

    Paul,


    I'm not aware of any limitation on the number of variables/arrays. Since you've been along so long, you probably already know that the length of a variable name must not be more than 100 characters, and that a variable name must contain letters, digits, and underscores only.


    There is a limitation in the ACL parser though, which can sometimes be surprising: A command argument or string token must not be longer than 4095 characters. (This limitation does not apply for expressions and function arguments.)


    - In what way does child 5 fail?


    K J (in a chilly Berlin).

    C
    ClayHelberg18-Opal
    18-Opal
    January 24, 2012
    Hi Paul--



    A few general things come to mind to check:



    1) Is there something unique about the fifth node you are
    processing? Is it the first node with child elements, or is it missing
    an attribute, or something like that that would explain the discrepancy?

    2) Is there some kind of state variable that should be reset for
    each node but isn't?

    3) In copying the code for each case, you changed the names of
    variables and arrays, but did you maybe forget to change the name of
    some minor variable, like a loop iterator or something like that?



    As Karl pointed out, it would be helpful to know a little more about
    what the code is trying to do, and how it fails on node #5.



    --Clay





    Clay Helberg

    Senior Consultant

    TerraXML


    N
    naglists1-VisitorAuthor
    1-Visitor
    January 24, 2012
    I appreciate the helpful avenues of thought. I have definitely run into
    something very weird, though.

    I am processing two sets of "rows". One is represented by something like
    this in my XML instance:

    <row>
    <item1>
    <item2>
    <item3>
    <item4>
    <item5>
    </row>

    The other set is in a XUI tab and corresponds to the XML instance but
    allows the author to edit the elements (and a few attributes) through a XUI
    GUI. (Or is it GUI XUI? 😉

    Anyhow, for some reason, based on XUI input (adding data to an empty
    textbox representative of contents of item5), my array of oids for <row>
    dies. If I reset the array before processing each item, however,
    "everything" is ok. (Technically, a second issue is now "allowed" to
    express, but I'm not very far down that road yet.)

    So I am now issuing:
    rows = oid_find_children(oid_root(), rowarr, "row");
    before processing each item. If I do not, rowarr[1] becomes invalid after
    processing item4. (The code for item4 is identical, save for naming, to
    item3 ... but item4 remains "intact.")

    This is almost as insane as my question re: variable/array limits (my
    red-light warning last night it was time to stop 😉 However, I have a
    sledge hammer fix that is allowing me to proceed. And so I go on.

    Weird, though.



    B
    bibach1-Visitor
    1-Visitor
    January 24, 2012
    Try throwing some debugging statements to dump out the OID values
    after each "refresh". The actual OIDs in the document may be changing
    due to changes made by your ACL code as you process each one. The
    OIDs in the array therefore become "stale" and invalid, necessitating
    the call to fetch the new values. Not that this will change how you
    address the problem, but at least you'd know for sure why you have to
    do it that way.

    -Brandon 🙂


    N
    naglists1-VisitorAuthor
    1-Visitor
    January 24, 2012
    Ha! Point, Brandon.

    This is indeed what is happening. I was just returning to this thread to
    ask how / when OIDs change. My re-get of the row oids solved the first part
    of my problem. The second, the one I'm now working, is, I think, a
    different variation on OIDs changing out from under me.

    My tab allows an author to open an individual element up for editing in a
    "pop-up" Edit Window. Before I open this window, I write any other changes
    the author may have made in the XUI tab. So far (and I have three or four
    panels that work like this), I have not had to add/delete elements, simply
    remove, insert, or overwrite their contents. This new tab works with a XML
    where I am replacing a child element. This, I think, is tipping over my
    OIDs.

    So, for a slightly less simplified example, I am manipulating:

    <item1><value>string content</value></item1>

    Sometimes there is no <value> tag (either before or after I write,
    depending).

    So, my current problem is that I pass an OID to a function that calls a
    writeall() function before opening the pop-up window for the element
    represented by my OID. Depending on the type of writing the writeall()
    function does, my OID may be invalid by the time I try to open it.

    Waaa.

    Any fancy tips for saving document locations (OIDs) when OIDs don't persist?

    On Tue, Jan 24, 2012 at 9:47 AM, Brandon Ibach <
    brandon.ibach@single-sourcing.com> wrote:

    > Try throwing some debugging statements to dump out the OID values
    > after each "refresh". The actual OIDs in the document may be changing
    > due to changes made by your ACL code as you process each one. The
    > OIDs in the array therefore become "stale" and invalid, necessitating
    > the call to fetch the new values. Not that this will change how you
    > address the problem, but at least you'd know for sure why you have to
    > do it that way.
    >
    > -Brandon 🙂
    >
    >
    >
    N
    naglists1-VisitorAuthor
    1-Visitor
    January 24, 2012
    contemplating "saving" my location with oid_treeloc(oid) and returning to
    it after I'm done writing. Not sure what my writes will do to the counts
    but presumably they would be predictable, if they do affect it. seems ugly.

    parent and grandparent oids change whenever oid changes (maybe the entire
    document is re-oid-ed?). Didn't test any further up that tree, though, so
    I'm not sure.

    Hmmm.

    Terms & ConditionsAccessibility statement