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

[naglists]

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

[KarlJohanKleist]

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).

[ClayHelberg]

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

[naglists]

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.

[bibach]

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 🙂

[naglists]

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 🙂
>
>
>

[naglists]

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.