Hi Nicola,
Thanks for the information. Your rule is complicated, and I still can't
fully reproduce your issue where two different jobs give you different
results from the same code (since I'm just copying-and-pasting it
myself), but I think I can still help based on what you've given me.
If you really are using exactly the same rule syntax with the same data,
then you should get the same results, all other things being equal, even
in different jobs. But clearly all other things are not equal, because
you're not getting the same result.
So the question is, what's different about those two jobs that could
affect the result of this rule? The process of answering this question
is called debugging. One way to do this is to try to reduce the logic
to the simplest form which reproduces the problem. If your logic is
overly complex in the first place, it will make isolating problems that
much more difficult. If nothing else, every line of code is a potential
bug, so sometimes simply reducing or refactoring it to something simpler
or clearer will make the problem go away.
In this case, you have a lot of extra code which is redundant or
unnecessary. So let's start by removing some of the deadwood in the
code and cutting this rule down to something more manageable.
Obviously you don't really need 24 lines of code declaring variables
with the same value, formatStyle01, formatStyle02, etc. So that can all
be reduced to a single declaration. You also don't need the
patternEndExt and patternStart1 variables, which aren't used anywhere in
the rule (or in the original phone number formatting sample, for that
matter), so those declarations can be removed.
Now, once you've done that, there should be a way to factor down the 24
corresponding if/else statements blocks, all of which test for very
similar patterns. Since you've already delved into regular expressions
a bit to modify the patterns, I'll take you a little deeper down the
rabbit hole. I can assure you that it's not too much more difficult to
take all of those patterns and reduce them to a single regular
expression. Some of your patterns are duplicates anyway (pattern01 and
pattern05 are the same, for example, as are 15 and 19), and there may be
some combinations you're not accounting for.
If I understand correctly, you're basically trying to match any sequence
of one to four letters or digits, followed by any number of non-letters
or non-digits, followed in turn by one to four digits. So there are
actually sixteen (four times four) possible combinations. But the
beauty of JavaScript is that this can all be done with a single regular
expression:
/^(\w{1,4})[^\w]+(\d{1,4})$/
(Where {1,4} means, "match from 1 to 4 occurrences of the preceding
character", the preceding character in this case being a meta-character
specification, either \w to match any alphanumeric character [letter or
digit] or \d to match any decimal digit [0-9]. I can fully explain the
rest in detail if you want.)
However, you can generalize this to match any number (i.e. one or more)
of letters or digits, like so:
/^(\w+)[^\w]+(\d+)$/
(Where the + symbol means, "match 1 or more occurrences of the preceding
character".)
Note that I've also changed the * (match zero of more times) to + (match
one or more times) to avoid a problem where you can erroneously get an
extra hyphen in the wrong place if the initial value is something like
"ABC123". (At least I presume this would be an error, although I may
not fully understand the requirement in this case. Either way, with a
single regular expression, you can modify the logic to handle this case
in one place.)
So, by reducing the regular expression thusly, along with a little bit
of whitespace editing, rearranging, and some tweaks to the formatting,
the entire rule can be reduced to this:
var number01 = Trim(Field("BuildingRoomNumber"));
if (number01 == "")
return "";
var pattern01 = /^(\w+)[^\w]+(\d+)$/;
if (number01.match(pattern01))
formattednumber = number01.replace(pattern01, "$1-$2");
//else Print("no match for " + number01);
return ', Building ' + formattednumber;
Now, if this code continues to give you different results in different
jobs, we can take the next step, which is to introduce some debugging
code. One of the best ways to do this is to add some calls to the Print
function to write information to your composition log (.msg) file.
These can be commented out once the code is debugged. (You can see
where I have a commented-out debugging line above.) However, I suspect
that the problem will fix itself once the code is simplified. (If
nothing else, it will all fit on your screen without having to scroll
around.)
Furthermore, you don't actually need to use the String.match function to
test an expression before calling String.replace to modify the string;
if there's no match, then the String.replace function will just return
the original string, unmodified. So, if you don't care about any
special handling for the case where you don't find a match, then the
rule can be simplified even further, like so:
var number01 = Trim(Field("BuildingRoomNumber"));
if (number01 == "")
return "";
var pattern01 = /^(\w+)[^\w]+(\d+)$/;
return ', Building ' + number01.replace(pattern01, "$1-$2");
Note that I've also removed the global function (formatNumber) from the
rule; I have a suspicion that the root cause of the problem where you
get different results in different jobs may be due to another rule
defining a global function with the same name. Using functions is a
good way to break up the logic of your rules and even to reduce multiple
lines of code; however, the problem is that functions have global scope
by default, and if you have another rule that's defining a global
function with the same name, they could conflict with each other. You
could declare the function a bit differently to make its scope be local
to the rule instead of global. In any case, though, simplifying the
rule to remove the global removes any potential problem in this regard.
(Of course the phone number formatting example itself could be
simplified, and if it had been more succinct, you might not have ended
up copying-and-pasting all those "if" statements, which may have avoided
all this trouble in the first place. The more lines of code, the more
potential for mistakes. And believe me, I make plenty of mistakes, so I
try to help myself, and the next poor guy who has to work with my code,
by keeping things as simple and clear as possible. Well, at least in
code, if not in email prose.)
But there's even more room for code reduction here. If you don't care
about prefixing the result with the string ", Building ", then the
entire rule can be reduced to a single line (well, a couple of lines
with the line-wrapping in the email forum, but a single statement
nevertheless), like so:
return Field("BuildingRoomNumber").replace(
/^(\w+)[^\w]+(\d+)$/, "$1-$2");
Note that the Trim function is unnecessary here, since the regular
expression is explicitly only matching non-whitespace characters at the
beginning and end of the string (with the initial ^ and the ending $).
You could use the result of this rule in another rule which prepends the
other text, or, depending on how you're using the result in the job, you
could simply use the "Suppress if containing empty variables" feature in
the Paragraph Formatting dialog.
If you want more information on regular expressions, here it is, right
from the horse's mouth:
<http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Regular_
Expressions>
Or, to avoid the URL wrapping in the forum:
http://tinyurl.com/m2qnf
For anyone still reading this, thanks, and yes, regular expressions are
a very advanced topic, but they're also extremely powerful and
efficient. Even though it may seem like gibberish, a good regular
expression can replace dozens, or even hundreds, of lines of code doing
various kinds of string comparisons, manipulations, and iterations. And
each one of those lines of code could have bugs in it, so by using a
regular expression, you're putting all the complexity in one place,
which makes isolating and fixing any potential problems, or even just
modifying the logic, much easier. Plus, JavaScript is optimized to
handle regular expressions very efficiently, that is, it processes them
much faster than the equivalent logic without them; so I wouldn't be
surprised if the job runs faster with the more succinct code.
Thanks,
Dan
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
FusionPro 5.0 Now Available!
Variable text on a curve and soft drop-shadows for variable text
LIMITED TIME upgrade offer of $299 per license for current customers:
http://fusionpro.printable.com/store/upgrade
New licenses available for $599 each at:
http://fusionpro.printable.com/store/
All FusionPro 5.0 customers to receive FusionPro 5.1 with
Adobe Acrobat 8 and InDesign CS3 support when released for FREE.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--
Users of FusionPro Desktop have unlimited free email support. Contact Printable
Support at [EMAIL PROTECTED]
--
View FusionPro Knowledge Base, FusionPro Samples at
www.printable.com/vdp/desktop.htm
--
You are currently subscribed to fusionpro as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
--
--
Note: All e-mail sent to or from this address will be received or otherwise
recorded by the e-mail recipients of this forum. It is subject to archival,
monitoring or review by, and/or disclosure to someone other than the recipient.
Our privacy policy is posted on www.printplanet.com
--
