Print

[sjordan]

Hello,

We're trying to roll our own community site and am considering CPG as the gallery piece of the puzzle. Think friendster.

I've downloaded cpg 1.4 and see there is room for up to 6 custom profile fields.

As I believe we'll have more than six profile fields and to allow for more in the future, I thought it best to try to make use of the bridging features of CPG and write our own member community app, then bridge it with CPG.

The question: With a custom app/script, (one with the flexibiliy of being built to best work within CPG's parameters) what is the best approach to linking a 3rd party membership database and CPG to maintain all the authentication and display features of CPG?

Thank you

[Joachim Müller]

The question: With a custom app/script, (one with the flexibiliy of being built to best work within CPG's parameters) what is the best approach to linking a 3rd party membership database and CPG to maintain all the authentication and display features of CPG?

Not sure what your question is. You already realized that you'd have to come up with a custom bridge file to accomplish what you're up to, so your question sounds to me like "what's the best way to drive a car?". Maybe this is just because English isn't my first language, so others might understand your question better. Anyway, I recommend adding more "flesh" to your question: what do you actually want to know?

[sjordan]

Gaugau,

Thank you for the reply. I'll try to add more flesh to the question.

More specifically, I am looking for documentation, stub files example, etc. as to best practice for doing bridging. Maybe something along the lines outlining the various tasks that need to be accomplished when bridging (ex. authentication, session management, synchronization, events and listeners, etc). This would allow a coder to code against a sort of blueprint.

In reading through some of the integrations, I see phrases like "some programs may require this" or "some apps can be trickier". As I am designing from scratch and have complete flexibility to avoid the pitfalls of bridging, in an ideal sense, what techniques work best when bridging CPG and a 3rd part script? As illustration, this might include things like:

1. we recommend OO programming

2. it's best when 3rd app and CPG share the same directory or database

3. it's best to use CPG's XYZ exposed API methods when accessing the database

4. when possible don't hack the code, use modules/addon like so<INSERT EXAMPLE> (makes upgrades easier)

5. integration seems to go most smoothly when <INSERT TIME SAVING TIP>

6. etc., etc., etc. ...

Stated another way (forgive me for blugeoning the point) I'm trying to code in the CPG philosophy so as to make things as smooth as possible. Surely with as advanced a team and project as this, there must exist coding style and guide.

Our goal at this stage is pretty simple, the only reason I see for coding a separate app is that CPG's profile/members account options are limited to six additional fields.

Thank you

PS. Your English is excellent (esp. not being your first language).

[Nibbler]

Surely hacking in some extra profile fields would be the easier option here, there are instructions posted on the board about how to do that.