Probably an incredibly elementary question, but...
484 views
Skip to first unread message
AWS_Zine
Aug 15, 2008, 12:28:26 PM8/15/08
to XMPie Interest Group
The company I work for just recently (last week) purchased XMPie,
which we will be mostly using in conjunction with PrintSmith to set up
online storefronts for certain clients so that they can log on to our
site and place orders for various items. We will, at least at first,
be using this mostly as a way for clients to order business cards.
Some will be static, and some will have form fields for variable
data. (All of you seem much, much more advance than me, so I'm sure
you already know all of this. I just figured I would try to fill in
as many blanks as possible just in case.) Anyway, I'm really green as
far as all of this variable data stuff is concerned. I just had my 2
hour XMPie training webinar yesterday, and have probably been using
XMPie for a grand total of 6 hours. But we have one client who orders
big lots of business cards on a weekly basis, all of which contain
almost entirely variable data. I have created a file in InDesign and
have written some really basic rules to display "office: " in front of
the office phone number if there is one present and other things of
that nature, and some slightly more advanced (in my opinion) rules for
governing the overall layout of the text on the card to keep the line
spacing and other such things as uniform as possible when chunks of
data are missing and etc. However, there is still something I just
can't seem to figure out, and it is in regards to the formatting of
the phone numbers on the card. Now when they send us orders the phone
number is generally entered on the order forms as xxx-xxx-xxxx.
However, on the cards they are printed as (xxx) xxx-xxxx. Thus far
I've been going in and setting up each card as it comes, and changing
the formatting of the phone numbers manually. So my question
(finally) is whether or not there is a way to automate the
reformatting of the phone number using XMPie and InDesign, or if we
are just going to have to ask them to change the way in which they
enter their orders? I'm sorry if this question is very basic or
whatever, but I'm a graphic designer, and as I said, I am very much a
novice as far as variable data and the general "programming" end of
things is concerned. So please be gentle. And thank you very much
for your time, patience, and help if you are able to offer any.
-AWS
which we will be mostly using in conjunction with PrintSmith to set up
online storefronts for certain clients so that they can log on to our
site and place orders for various items. We will, at least at first,
be using this mostly as a way for clients to order business cards.
Some will be static, and some will have form fields for variable
data. (All of you seem much, much more advance than me, so I'm sure
you already know all of this. I just figured I would try to fill in
as many blanks as possible just in case.) Anyway, I'm really green as
far as all of this variable data stuff is concerned. I just had my 2
hour XMPie training webinar yesterday, and have probably been using
XMPie for a grand total of 6 hours. But we have one client who orders
big lots of business cards on a weekly basis, all of which contain
almost entirely variable data. I have created a file in InDesign and
have written some really basic rules to display "office: " in front of
the office phone number if there is one present and other things of
that nature, and some slightly more advanced (in my opinion) rules for
governing the overall layout of the text on the card to keep the line
spacing and other such things as uniform as possible when chunks of
data are missing and etc. However, there is still something I just
can't seem to figure out, and it is in regards to the formatting of
the phone numbers on the card. Now when they send us orders the phone
number is generally entered on the order forms as xxx-xxx-xxxx.
However, on the cards they are printed as (xxx) xxx-xxxx. Thus far
I've been going in and setting up each card as it comes, and changing
the formatting of the phone numbers manually. So my question
(finally) is whether or not there is a way to automate the
reformatting of the phone number using XMPie and InDesign, or if we
are just going to have to ask them to change the way in which they
enter their orders? I'm sorry if this question is very basic or
whatever, but I'm a graphic designer, and as I said, I am very much a
novice as far as variable data and the general "programming" end of
things is concerned. So please be gentle. And thank you very much
for your time, patience, and help if you are able to offer any.
-AWS
Bill
Aug 15, 2008, 1:02:14 PM8/15/08
to XMPie Interest Group
> So my question
> (finally) is whether or not there is a way to automate the
> reformatting of the phone number using XMPie and InDesign, or if we
> are just going to have to ask them to change the way in which they
> enter their orders?
As far as I understand it, the RegExp available in uStore Admin only
> (finally) is whether or not there is a way to automate the
> reformatting of the phone number using XMPie and InDesign, or if we
> are just going to have to ask them to change the way in which they
> enter their orders?
allow you to control the way the users will type in their variable
data in uStore. They cannot help you "reformat" the data typed in.
To reformat them, I suggest you to use uPlan, where you would defined
Dial-in variables (which will further be used in the uStore Admin
Customization Wizards), when the text ADORs rules defined in the plan
and used in InDesign (uCreate Print) would reformat the Dial-in
variables, either directly or through a custom Function.
The rule formula would look like
"(" & SubString( @{Var_Phone}, 0, 3 ) & ") " &
SubString( @{Var_Phone}, 4, 8)
> I just had my 2
> hour XMPie training webinar yesterday, and have probably been using
> XMPie for a grand total of 6 hours.
on-site XMPie training lasts about 5 days (one day for uCreate Print,
one day for uPlan, one day for uProduce Print, two days for uStore
Print).
AWS_Zine
Aug 15, 2008, 2:25:29 PM8/15/08
to XMPie Interest Group
Wow. Yeah, I was just looking through the appendix in the user guide
and was thinking that SubString would be the way to go. Thank you so
much for your help, I really appreciate it. It now does everything
that I want/need it to do.
I live in the U.S. How about you? I'm not really sure why our
training was so short. I talked to a friend of mine who was just
recently trained on XMPie and she said that her training took 3 days.
Maybe the fact that we went through efi/PrintSmith rather than going
directly through XMPie made the difference? I'm not really sure.
Either way, I definitely wish our training was more thorough.
Anyway, thanks again!
and was thinking that SubString would be the way to go. Thank you so
much for your help, I really appreciate it. It now does everything
that I want/need it to do.
I live in the U.S. How about you? I'm not really sure why our
training was so short. I talked to a friend of mine who was just
recently trained on XMPie and she said that her training took 3 days.
Maybe the fact that we went through efi/PrintSmith rather than going
directly through XMPie made the difference? I'm not really sure.
Either way, I definitely wish our training was more thorough.
Anyway, thanks again!
Barak Danin (XMPie)
Aug 17, 2008, 6:33:38 AM8/17/08
to XMPie Interest Group
In order for this to fully work, I would add one more thing.
As Bill had mentioned, the uStore regular expression will allow you to
limit what the user can enter in the phone field.
In order for the SubString function to work properly, the phone number
must adhere precisely to the format you specified:
xxx-xxx-xxxx.
If someone entered, for example:
123 -456-7890
The result of the SubString function above would be:
(123) -45 -7890
Which is obviously not you want. So in the Customization Wizard Setup
in uStore, when editing the phone number Dial, check the "Regular
Expression" and choose the US Phone Number preset ("\d{3}-\d{3}-
\d{4}"). This will ensure that phone numbers are entered in the
expected format, and then the SubString function calls will work as
expected.
As Bill had mentioned, the uStore regular expression will allow you to
limit what the user can enter in the phone field.
In order for the SubString function to work properly, the phone number
must adhere precisely to the format you specified:
xxx-xxx-xxxx.
If someone entered, for example:
123 -456-7890
The result of the SubString function above would be:
(123) -45 -7890
Which is obviously not you want. So in the Customization Wizard Setup
in uStore, when editing the phone number Dial, check the "Regular
Expression" and choose the US Phone Number preset ("\d{3}-\d{3}-
\d{4}"). This will ensure that phone numbers are entered in the
expected format, and then the SubString function calls will work as
expected.
Jeffrey A. Stewart
Aug 17, 2008, 11:32:04 AM8/17/08
to xmpie...@googlegroups.com
Regular expressions are an excellent solution to formatting problems... but some have a difficult time understanding them. Another way is more of a brute force. Barak, you are correct about substring, but the way I would attack is with string replace.
For phone number you can remove, or replace with blanks, all non numeric characters. This leaves just the numbers like 1234567890. Then use the format function to add back the non numeric characters you desite.
As for additional training, this groups is a good resource. Another very good resource is the XMPie User Group. It only costs a few hundred dollars a year to participate. With it you get a forum to ask these types of questions to other active XMPie user. Take a look at www.xmpieusers.org is you have not already.
________________________________
For phone number you can remove, or replace with blanks, all non numeric characters. This leaves just the numbers like 1234567890. Then use the format function to add back the non numeric characters you desite.
As for additional training, this groups is a good resource. Another very good resource is the XMPie User Group. It only costs a few hundred dollars a year to participate. With it you get a forum to ask these types of questions to other active XMPie user. Take a look at www.xmpieusers.org is you have not already.
________________________________
Tim Perrett
Aug 17, 2008, 11:45:32 AM8/17/08
to xmpie...@googlegroups.com
Hey Jeff
> Regular expressions are an excellent solution to formatting
> problems... but some have a difficult time understanding them.
> Another way is more of a brute force. Barak, you are correct about
> substring, but the way I would attack is with string replace.
IMHO, using the regex is a much more elegant solution. Using regex
will also be better performance wise due to the way PCRE expressions
are handled. They might be a little min bending initially, but they
are well with the learning curve.
> <winmail.dat>
Jeffrey A. Stewart
Aug 17, 2008, 12:00:18 PM8/17/08
to xmpie...@googlegroups.com
Tim,
Yup, I love elegance. Sometimes elegence and perfection gets in the way of just do it. I am just trying to provide an alternative. There are always more than one way to skin a cat!
One thing I teach my developers is the art of getting something working and then refining and refactoring. With a team approach, offering different ways to solve a problems allows us to end up with elegant, high performance solutions. But we do work for hire and job one is making it work. If I have a developer who is not experienced with regex, then he is going to waste a lot of time and money figuring it out (which we do too!). Another developer with that experience can offer the suggestion during code reviews. We refactor the solution and cross-train the junior developer.
So my point abour brute force is that it is often the easier quickest solution... and sometimes better to code maintainability down the road!
Jeff
________________________________
Yup, I love elegance. Sometimes elegence and perfection gets in the way of just do it. I am just trying to provide an alternative. There are always more than one way to skin a cat!
One thing I teach my developers is the art of getting something working and then refining and refactoring. With a team approach, offering different ways to solve a problems allows us to end up with elegant, high performance solutions. But we do work for hire and job one is making it work. If I have a developer who is not experienced with regex, then he is going to waste a lot of time and money figuring it out (which we do too!). Another developer with that experience can offer the suggestion during code reviews. We refactor the solution and cross-train the junior developer.
So my point abour brute force is that it is often the easier quickest solution... and sometimes better to code maintainability down the road!
Jeff
________________________________
Barak Danin (XMPie)
Aug 18, 2008, 2:38:39 AM8/18/08
to XMPie Interest Group
Hi Jeff,
I agree that reg-ex can be difficult, and for newbie who's not a
programmer it can be a substantial obstacle, however in this case, US
phone number, there's a preset that matches AWS's requirements. So he
doesn't need to know anything about regex, only select the preset.
I thought about string replace too, it's much more user-friendly as it
will accept any input and automatically correct it. However to remove
all non-numeric characters you would need JavaScript, as you will need
to scan the string character by character and remove anything that is
not a number; this is a much more mind-bending solution for a non-
programmer. The QLingo way to solve it AFAIK would be a lot of
FindAndReplace calls, with all possible invalid characters, that is
all non-numeric characters - not really a viable option. If you can
think of another way of doing this with QLingo, I'd love to learn!
Barak
> winmail.dat
> 11KViewDownload
I agree that reg-ex can be difficult, and for newbie who's not a
programmer it can be a substantial obstacle, however in this case, US
phone number, there's a preset that matches AWS's requirements. So he
doesn't need to know anything about regex, only select the preset.
I thought about string replace too, it's much more user-friendly as it
will accept any input and automatically correct it. However to remove
all non-numeric characters you would need JavaScript, as you will need
to scan the string character by character and remove anything that is
not a number; this is a much more mind-bending solution for a non-
programmer. The QLingo way to solve it AFAIK would be a lot of
FindAndReplace calls, with all possible invalid characters, that is
all non-numeric characters - not really a viable option. If you can
think of another way of doing this with QLingo, I'd love to learn!
Barak
> 11KViewDownload
Bill
Aug 18, 2008, 3:29:17 AM8/18/08
to XMPie Interest Group
On Aug 18, 8:38 am, "Barak Danin (XMPie)" <barak.da...@xmpie.com>
wrote:
> you would need JavaScript
A VBScrit custom function (also available in uPlan) with a "For" loop
should also work; this language is certainly known by much more people
than Javascript (mostly newbie programers) .
wrote:
> you would need JavaScript
A VBScrit custom function (also available in uPlan) with a "For" loop
should also work; this language is certainly known by much more people
than Javascript (mostly newbie programers) .
Tim Perrett
Aug 19, 2008, 4:10:49 AM8/19/08
to XMPie Interest Group
> this language is certainly known by much more people
> than Javascript (mostly newbie programers) .
I would strongly disagree with you on that - out of interest, have you
> than Javascript (mostly newbie programers) .
any stats on this?
Remember VB is only supported on windows; whilst Javascript is cross-
platform and used on the web extensively... Id suggest there are
vastly more Javascript programmers out there than VB ones. Windows
developers need to know Javascript, but unix developers don't need to
know VB.
Cheers
Tim
Bill
Aug 19, 2008, 6:03:25 AM8/19/08
to XMPie Interest Group
> I would strongly disagree with you on that - out of interest, have you
> any stats on this?
My stats:
> any stats on this?
* 83% of our PersonalEffect customers use uPlan on Windows XP or
Vista.
* 86% of our uDirect Pro or uDirect Premier customers use uPlan on
Windows XP or Vista.
* 100% of our XMPie customers (whether they are Windows or Mac-based,
Desktop or PersonalEffect) who developed home-made functions in uPlan
did it with VBScript.
Jeffrey Stewart
Aug 19, 2008, 9:09:40 AM8/19/08
to XMPie Interest Group
That is a curious stat. Do your customers also do web development? Or
are they mostly desktop (VBScript is most used as for desktop tool
extensions) developers?
While we certianly have folks that use VBScript for certain tasks,
like Photoshop and InDesign scripts, they all prefer JavaScript
syntax. It is extremely popular in the web development and Flash
development sectors.
One note on both VBScript and JavaScript for uPlan, it can be pretty
painful. Since there is not a built in debugger or syntax checker in
uPlan for these languages, it can take considerable trial and error to
get something to work properly. If anyone knows of a standalone
debugger for JavaScript, let me know!
are they mostly desktop (VBScript is most used as for desktop tool
extensions) developers?
While we certianly have folks that use VBScript for certain tasks,
like Photoshop and InDesign scripts, they all prefer JavaScript
syntax. It is extremely popular in the web development and Flash
development sectors.
One note on both VBScript and JavaScript for uPlan, it can be pretty
painful. Since there is not a built in debugger or syntax checker in
uPlan for these languages, it can take considerable trial and error to
get something to work properly. If anyone knows of a standalone
debugger for JavaScript, let me know!
Bill
Aug 19, 2008, 3:14:06 PM8/19/08
to XMPie Interest Group
> That is a curious stat.
* you will certainly not be surprised that 100% of our Desktop
customers do *not* do web dev.
* 75% of our PersonalEffect customers do Web development or have a Web
activity.
Tim Perrett
Aug 19, 2008, 3:19:34 PM8/19/08
to XMPie Interest Group
Jeff, you could use firebug, but the problem is that the xmpie
implementation of JavaScript is not ECMA-262 compliant, so it kind of
makes the debugger useless to as it wont tell you whats right and
wrong in terms of uPlan...
Also, I agree with Jeff that it really is a curious stat and that
indeed, VB is very legacy these days; to that end, most people appear
to prefer JavaScript (thats the case in EMEA anyway)
implementation of JavaScript is not ECMA-262 compliant, so it kind of
makes the debugger useless to as it wont tell you whats right and
wrong in terms of uPlan...
Also, I agree with Jeff that it really is a curious stat and that
indeed, VB is very legacy these days; to that end, most people appear
to prefer JavaScript (thats the case in EMEA anyway)
Reply all
Reply to author
Forward
0 new messages