Re: [Phpgroupware-developers] registration app and choice of personal_info template

[Jim Foster]

Jason:

Thank you for your advice. I will be revisiting this issue today.

There is one other issue I need to address, perhaps you or someone else
following this thread could give me some clues as to how to handle it.

My client is in the business of online education for the medical imaging
professional (Radiography, Mammography, MRI, CT, Ultrasound, etc).  Study
material is available in a variety of formats which is sold online. As a new
customer moves through the process of a purchase, at some point his/her
name/address will be required. Thought is to allow the user to register at
the appropriate time while in the middle of a purchase, then, instead of
going to the welcome screen after a successful registration, redirect the
user to the next page in the purchase process. This way, the registration
process just becomes a little detour off the road in the purchase process.
For example: if a registered and logged-in user's purchase flow looks like
this:

        Purchase Area -> Place Order -> Confirm Order -> Order Success

then a new (not yet registered) user's flow would look like this:

        Purchase Area -> Place Order -> Registration Process -> Confirm
Order -> Order Success

So the question is, is it possible to establish a session for the user
following his/her registration, followed by a redirect to the page desired
(Confirm Order in the example above)? Looking at the code it seems that it
should be able to be done in boreg.step4. Since I still rate myself as
"novice" with the registration code, I thought it prudent to seek out word
from those much more knowledgeable about the code, itself.

Any advice would be most appreciated.

Jim


----- Original Message -----
From: "Jason Wies" <address@hidden>
To: <address@hidden>
Sent: Tuesday, December 11, 2001 8:00 PM
Subject: Re: [Phpgroupware-developers] registration app and choice of
personal_info template


> Hopefully this is what you were getting at by "international".
>
> I would suggest making a single form that works for both US and
international users.  This is very possible.  Suggestions include:
>
> * 5 spaces per phone number part, ie:
> XXXXX-XXXXX-XXXXX-XXXXX
> * Free form postal code
> Can include alphanumeric and whitespace
> * Use UN country, region, and city codes available at:
> http://www.unece.org/cefact/download/downmain.htm
>
> The UN codes are based on ISO 3166, but go much deeper.  They include all
countries and a very large number of cities (32,000+).  Regions are only
available for 14 or so countries, which is the only thing stoping it from
being "the" electronic geography reference, as far as I know.
>
> I would go so far as to recommend using them for all of phpGroupWare.  Not
having regions for all countries is a bit of a pain, but not too much to
overcome technically.
>
> You can implement the geography "drill down" on the registration form with
JavaScript onSelect, and a <NOSCRIPT> button, or add more steps.
>
> Jason Wies aka Zone
> address@hidden
>
> On Sat, Dec 08, 2001 at 04:14:30AM -0700, Jim Foster wrote:
> > Hello all!
> >
> > This is a question regarding the registration application.
> >
> > I am using it for a client's site that is composed of both general
public areas and areas that require registration in order to access those
areas. Works like a charm! (Thanks go to Jason for helping me get started
with it).
> >
> > Now the request from my client is to allow for internationalization on
the registration form. In my opinion, an international form mixed in with
one for the US is a real mess. Best approach is to fork either national or
international. My thought is to put radio buttons for national /
international on the opening page that asks for a login name, and for the
registration app to pull up a personal_info_national.tpl --OR-- a
personal_info_international.tpl in uireg.step2, depending, of course,  on
the user's radio button select.
> >
> > Question: Is the registration app architecture such as to allow for such
choice without a massive code rewrite? or must I consider other, less
elegant options?
> >
> > Thanks much in advance!
> >
> > Jim
>
> _______________________________________________
> Phpgroupware-developers mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/phpgroupware-developers
>