Hi COOKs,

I have a question that I hope one of you more experienced devs might be able to help with...

SCENARIO
I'm writing a shopping cart extension for 2 types of customer, STANDARD & TRADE. I was writing in customer types and customers tables when I realised that a more efficient way of doing this would be to go down the Profile plugin route. So, in short, I am following the profile plugin standards to integrate signup, profile view, admin edit and so on. I need to be able to have a registration page that allows users signing up to select whether they are registering for a REGULAR or TRADE account...

Here's where I've got to:

FIELDS I've added all of the standard fields you'd expect in a shopping cart extension to pre-populate carts with billing and shipping addresses.

CONFIG
I've added 2 usergroup type options;
customer & trader so that the admin of the component can specify their custom usergroup for each type of user.

ISSUE
How can I present the 2 configured usergroup options that have been set, I.E the TRADER/CUSTOMER in a combobox field for user registration so that I can save the user into the relevant group?

Many thanks in advance for any pointers on this!!!

Gez

I do not know a lot about user extension for the moment. Must check it out...

But, I know about pluging dev, and I suggest yout to populate these fields from a new user plugin that catch the user update event.

After the save of the user, catch the informations and treat them.

Cannot say much more now. I've got to go now, seen you soon.

Thanks for the response!

I'm OK with all of the save/update parts...

It's just populating a combo field with 2 parameters set in the plugin's config: customer group (the group to put customers in) & traders (the group to put traders in) so that the options are;Thanks,

Gez

Let me know when you can load a xml form outside of the classical way. I may try the same for filters.

Hi @admin,

What do you mean "outside of the classical way"?

Thanks,

Gez

Are you in a form ? Generated with Cook ? Then forget my comment...

In a classic form, generated with cook :
The type must be 'ckcombo', because Cook is overriding every single field.

You example is perfect to illustrate :
you can pass the dynamic list trough dynamic field initialization. I mean, this is better to my point of view. Separate the view from the datas.

You've choosed a combo, and you want ti fill it with a list coming from the view file (displayXxxx() function)

1. Prepare your list in the view
2. Send this list to the concerned field to complet its initialization.

This technic is used everywhere in forms for lists. (FK, combos, radios, ...)
See in your form template file.

Aha, I get what you mean...

No, sorry, it's a profile plugin to extend the users table - I'm practically using exactly the profile plugin that is included in joomla for all intents and purposes.

I have added 2 configuration parameters that use the usergroup (combo that pre-populates with usergroups) - 1 parameter for admins of the plugin to select the usergroup associated with their Customers and another to select the usergroup for their |Trade Customers.

So, for example, in the plugin, the admin could specify the following CONFIG;

1. customer_group -> registered
2. trade_group -> editor

Then, when users register, I have a field called customertype which I'd like to be a combo presenting the user with 2 options from those specified in the plugin's config:

1. Regular Customer -> registered
2. Trade Customer -> editor

Does that make sense?

I suppose that the easiest way to achieve it is to go ahead and just create the 2 options:

<option value="1">Regular Customer</option>
<option value="2">Trade Customer</option>

Then programmatically get the usergroup id from the config parameter right? The only thing I don't like is the hard-coding of it... If I were to ever add another (3rd) store user level, I'd have to go back in and add it manually...

Anyway, I hope this clarifies it...

Many thanks again for looking at this!!!

Gez

Well, you can harcode some, if you do not have any others values in future, let's hard code, and use a language string of course, but tat's not the point of your example.

You're right! I'll just hardcode it as it's only a couple of values, not likely to grow to a list of 100 or anything crazy so this will work fine.

I'd always avoided looking at writing a custom profile plugin but, it really is the way to go - no need to build all those extra component-specific join tables to users. Because cook is awesome and gives us a hook right into the users table, grabbing a few extra fields made available by a profile plugin will be simple!

BOOM!

Thanks Again!!!

If I understand, you prefer not to extend user table, but to create a bridge to a Cook generated table ?

I think the best was if cook could do it by itself and doing it in the best proper way.

What is Joomla proposing about that ? Do you know all the possibilities ? Because I don't know for the moment. Still a lot to learn as you can see.

I was definitely going to go that way originally but, I only want to store extra info for users such as shipping address, billing address and what kind of user they are - trade or regular customer... As I said, my original idea was to create customer types, customers and customers contacttables in which to add all of the billing & shipping info would go.

However, after taking a look at the profile plugin route, it seems easier almost... Less work at least + I can keep all of the authentication stuff completely in the standard user object as opposed to having to grab, set and check a whole bunch of stuff based on my component's tables. Following the profile plugin route is definitely best because I can add all that stuff to the users really easily in the form of a plugin, capture it all at singnup, check it all at login, have the user update it easily in their profiles etc, etc. I can then package the plugin with the component.

G

Learning is the fun of it all! I live to learn and will have to die to stop.

audibleid wrote: Excellent !

And lease share you findings when it will work. More easy then to integrate here one day.

No probs! Will definitely share it ....

Can I be cheeky? I've been working on how best to integrate paypal into my component. Pretty sure I'm going to go down a plugin route and have posted my thoughts here... Would love to hear what you think whenever you get time. I'm not worried about the PayPal IPN as I have that working/logging to a file as a test including checking for price jacking and all that jazz... Just wondering whether I'm on the right track with how best to present it in my component.

Many thanks,

Gez