There are problems with using community, and developing applications based on it.
Right now, there seems to be problems with authentication, and sessions, being properly handled, and recognized by the GLinks/GForum programs.
When you are dealing with applications that are updating system tables, and pulling data from a variety of sources, I'm not about to worry about what community is and isn't doing. It's been enough of a battle to figure out a system that will separate a logged in users profile data from the target data, and doing it in a manner that is secure, and can't be accidentally bypassed.
I've used the templates to provide a second test, to prevent bogus data.
*if* community gets stabilized, and formalized, and provides for remote logons it would be worth considering, but community is a half-finished product, and if you know me, it's the 1 and major gripe I've had with GT for the past 3 years. I feel community is the lynch pin of the entire system, but the promises never materialized, and *that* more than anything, has hurt an otherwise awesome product line.
The routines and profile system I've created, can be migrated to GComm fairly easily, since almost all the functionality is in the functon calls in the templates, it's a matter of changing the function call to use authcommuinty rather than Plugins.
*BUT* I *wouldn't* suggest doing it that way, if, and especially if, the GLinks program is your primary target.
You can access GForum data from within GLinks, and I'm sure GLinks data from within GForum.
*UNTIL* the protocols are set, and worked out between apps, things will change and that means a lot of back-work to fix up stuff that wasn't ready for prime time anyway.
The way profile.cgi works, is you probably can call it from anywhere, and if logged in via community, the system will recognize you as a Links user, even if called from within GForum.
For now, using Community to manage sessions and logons is the best course.
Andy has been writing add ons to run the ticket system and other things off of GComm, but we've hit some issues in the process along the way.
If GT puts the time in, to get it working, then most plugins that affect user data, and site layout, and even user status and stats, should probably go through community -- and GLinks/GForum should use those tables rather than their own.
It's a lot more complex than it seems, especially for complex applications. It would be really nice if COMMUNITY was actually INTEGRATED into the GLinks and GForum systems, rather than added on. If certain plugin hooks, and hooks within the system activated, and used GCOMM routines rather than the internal ones automatically.
For now, there are more good reasons NOT to develop for the current GComm, than there are to use it.
I keep hoping that will change.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
Right now, there seems to be problems with authentication, and sessions, being properly handled, and recognized by the GLinks/GForum programs.
When you are dealing with applications that are updating system tables, and pulling data from a variety of sources, I'm not about to worry about what community is and isn't doing. It's been enough of a battle to figure out a system that will separate a logged in users profile data from the target data, and doing it in a manner that is secure, and can't be accidentally bypassed.
I've used the templates to provide a second test, to prevent bogus data.
*if* community gets stabilized, and formalized, and provides for remote logons it would be worth considering, but community is a half-finished product, and if you know me, it's the 1 and major gripe I've had with GT for the past 3 years. I feel community is the lynch pin of the entire system, but the promises never materialized, and *that* more than anything, has hurt an otherwise awesome product line.
The routines and profile system I've created, can be migrated to GComm fairly easily, since almost all the functionality is in the functon calls in the templates, it's a matter of changing the function call to use authcommuinty rather than Plugins.
*BUT* I *wouldn't* suggest doing it that way, if, and especially if, the GLinks program is your primary target.
You can access GForum data from within GLinks, and I'm sure GLinks data from within GForum.
*UNTIL* the protocols are set, and worked out between apps, things will change and that means a lot of back-work to fix up stuff that wasn't ready for prime time anyway.
The way profile.cgi works, is you probably can call it from anywhere, and if logged in via community, the system will recognize you as a Links user, even if called from within GForum.
For now, using Community to manage sessions and logons is the best course.
Andy has been writing add ons to run the ticket system and other things off of GComm, but we've hit some issues in the process along the way.
If GT puts the time in, to get it working, then most plugins that affect user data, and site layout, and even user status and stats, should probably go through community -- and GLinks/GForum should use those tables rather than their own.
It's a lot more complex than it seems, especially for complex applications. It would be really nice if COMMUNITY was actually INTEGRATED into the GLinks and GForum systems, rather than added on. If certain plugin hooks, and hooks within the system activated, and used GCOMM routines rather than the internal ones automatically.
For now, there are more good reasons NOT to develop for the current GComm, than there are to use it.
I keep hoping that will change.
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
