#192 xoopsUser->OnUpdate

[Mao]

In my opinion this can be useful when bridging the
Xoops framework to another script - that maybe someone
already run and don't want to port to Xoops - like a
forum or a shopping cart, for example.

Why not give to xoops the ability to achieve a job when
an user do something in the website?

I mean, something like this
class xoops_user_sync{

function on_login ($userid){
global $yourglobals
// Start your bridging code here

// end of your bridging code
}
function on_post_submit ($userid){
global $yourglobals
// Start your bridging code here

// end of your bridging code
}
}

Where this method are called when making various
actions in your xoops website.

A basic list of these methods (not a completed one,
probably):
- on_account_create -> when creating an account
- on_account_delete -> when deleting an account
- on_account_suspend -> when an user get banned or
something
- on_login -> when an user complete the login
- on_logout -> when an user logout from the website
- on_group_change -> when there is a group change
- on_new_item_submit -> when the user post a comment,
news, or something
- on_item_delete -> when an item submitted by the user
is deleted
- on_profile_change -> when something on the user
profile is changed (maybe with an array here)

banned,

[Skalpa Keo]

Logged In: YES
user_id=882380

Two points:
1) I agree this kind of things is highly needed, but not
only for 'users'. We need a generic 'events management'
system so specific actions can trigger some code somewhere,
and this without having to change the original class.
2) Whatever happens, if you have to write some "bridging
code" somewhere, then you're actually making a XOOPS "port"
;-). Now, I agree XOOPS should ease this kind of things, so
"porting" an application to a module would just be about
writing a dummy xoops_version.php file, and add a few little
bridging classes/scripts.
Anyway, to answer you more concretely: implementing such an
events system wouldn't be so long (just about adding some
kind of 'xoEvents' property to the components bundle info
file to define which events each object supports, then
having a class/methods on the side that modules could call
during installation so they register their own briging class
as an event handler for, say the "login" event of the "user"
class), so I'll try to check if that can be done during
february.
Am setting this tracker item to "remind" so I don't forget
about it.

skalpa.>
PS: Didnt answer you, but sure, don't hesitate to submit
anything. Also, you can follow what's being done by watching
the "tasks manager" here.