Jump to content

Recommended Posts

Posted

Hello everyone,

I'm creating a large scale application which will be used by thousands of people. Part of of the application requires storing temporary information about user's activities. For example, if user comments on certain topic, notification of same should be given to OP and people following the topic.

I thought I'd create a subpage with a repeater field having few fields like user id, timestamp & notification status, read/unread (I just don't see why using page table is better in this case, if someone can enlighten me, that'd be great.).

But I've read that every repeater item is same as new page, so I'm really confused whether I should just start keeping temporary pages or use a page with repeater field.

But for every topic, there can be hundreds of notifications, which I think will be a problematic situation in future. So I am looking for any kind of temporary storage that will not included creating pages.

Writing logs to file could be done but i'm not sure how good solution is that and how reliable it'll be.

I'd really like a good conversation with someone who understands PW, so I'm here.

Thank you all.

Posted

Some quick comments.

Repeaters / PageTable seem like far too much overhead. 

Have you looked at the new comments system on the dev branch?

You mentioned temporary storage — do the topics only exist for a short time?

Posted

Thanks for your reply renobird.

You mentioned temporary storage — do the topics only exist for a short time?

No, topics are permanent unless owner of the topic deletes it. The temp pages are for notifications which I want to give to the owner of the topic if someone comments or does any of other activities like adding post to favourites etc.

So basically, it's like facebook's notifications. Consider you post a photo & people are comments & liking the picture, how am I to give you notifications? I've to store all this comments/liking activity somewhere right? I've figured out a way to store comments & likes, it's just the notifications of it, which is a temporary thing, that I've to figure out.

It can be done by creating temp notification pages and add them to a notifications page array field of the post and then just check the notification status and show user the unread pages as notifications. But this way I'm wasting hell lot of page IDs. Which would be an inefficient thing to do, right?

So that's where my question comes from, how do I manage temporary storage? May be PW should provide temp pages other than usual pages with all the same features.

Sorry for the long story. :)

Posted

Ah, Seems like the least overhead would be to create a separate table for those. The lookups would be quick, even if each topic has hundreds of notifications.

Posted

I'd perhaps use WireCache for something like this, depending on how you need to retrieve these items later on.

The most obvious method would be to key it by the user who will receive the notifications - so you would create a simple array structure with the important information for the notifications, and store it using a cache name like "notifications-1142" for user ID 1142. This should make it quick to retrieve. You can then pull this out, show it, update it by modifying the notifications array, and putting it back in the cache.

Other than that - a simple module as an interface to a custom simple database table would be more than suitable.

  • Like 2
Posted

It's a little hard to tell exactly how you want these notifications to work but i think the relatively new System Notifications module could be a good fit. For now it is only available on the dev branch: https://github.com/ryancramerdesign/ProcessWire/tree/dev/wire/modules/System/SystemNotifications

But in the soon to be released 2.6 it will be included i think. There isn't any formal docs yet but you can study the code and read a little bit about it here: https://processwire.com/blog/posts/processwire-2.5.3-master-2.5.4-dev/#whats-new-on-the-dev-branch

Posted (edited)

You could have a pagefield "notifications" in the users template, and create the notifications as pages connected to the topic (not one per user, just one per notification, that could be used for many users), than you would link the user to the notification, and delete it from the pagefield as soon as it is presented to him.

Does this make sense?

PS: I know you asked how to not create pages, but I think this way would at least make them much less, and easier to delete when not needed.

--

A little pseudo-code for the above:

foreach ($user->notifications as $not) {
    echo $not->body; // show the notification
$page->of(false);
    $user->notifications->remove($not); // remove it from the list
    if ( !$pages->get("template=user,notifications={$not}") ) $not->delete(); // if there are no more users to be notified, delete the page
}
$page->save("notifications"); //save the field with the notifications removed
Edited by diogo
Added the pseudo-code
  • Like 2
Posted

Hi diogo,

I was thinking about the notifications that PW's admin theme uses. I guess you are talking about the same thing, ain't you?

I will try your suggestion on a staging pw installation. Yesterday I gave up and wrote sql queries (which I absolutely hate to do) to store all the activity in a table called activity. Then once they are shown to user, I change the activity status to read from unread.

Since it's a different table, I don't have to worry about wasting page ids.

Thank you all for your inputs.

Posted

Uh no, diogo was talking about something different than the admin notifications. That's actually what i was talking about. PW has notices (core/notices.php) and the more advanced SystemNotifications, available in dev but uninstalled by default.

Posted

Uh no, diogo was talking about something different than the admin notifications. That's actually what i was talking about. PW has notices (core/notices.php) and the more advanced SystemNotifications, available in dev but uninstalled by default.

Oh right, I found it. 

Does this make sense?

foreach ($user->notifications as $not) {
    echo $not->body; // show the notification
$page->of(false);
    $user->notifications->remove($not); // remove it from the list
    if ( !$pages->get("template=user,notifications={$not}") ) $not->delete(); // if there are no more users to be notified, delete the page
}
$page->save("notifications"); //save the field with the notifications removed

It makes a lot of sense now.

Posted

Sorry, ya, that's more a frontend thing, but you could interact with the notifications system using the same method, of course.

  • 2 months later...
Posted

I implemented the SystemNotifications module on my front end, but only on the user account settings page for now to test things out..At the moment it seems to work quiet nice :)

$notices = $user->notifications;

then for example

$avatarErrorMsg = $notices->error("Your error message");
$avatarErrorMsg->expires = 30; // or however you like, doesn't even need to self expire
$notices->save(); // while writing this I'm not exactly sure if necessary
foreach($notices as $n)
{
    if($n->is("warning")) $messageClass = 'warning';
    if($n->is("error")) $messageClass = 'error';
    if($n->is("message")) $messageClass = 'success';
    $content .= "<div class='alert alert-$messageClass closable'>$n->title <i class='fa fa-close'></i></div>";
}
  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...