Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dragooon
31
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 28th, 2013, 02:43 PM »
I'm replying in random order, too much stuff. If I miss something let me know.
Quote
- Hmm, I just realized how silly my question was... Doing $this->getName() was enough, uh. Now, if I could understand why getData and getObject are defined in Class-Notification, rather than Class-Notifier..? Shouldn't notifiers be allowed to tamper with these, in the first place..?
The plugin handling notifier sends the data anyway, so notifier doesn't need to really tamper once the notification is issued. Plus you can't change ID of the object in any case, since that's fixed for a notification.
Quote
I have no idea what you're suggesting, but I'm open to anything you have to offer...? Can you elaborate, then..?
I'm suggesting what you've been saying, implement a new column called object_type and add that to the classes. Basically, that way likes can be for thought, post, media, media_comment etc. and similarly mentions can be for thought, post etc. without having multiple notifiers.
Quote
Just... Don't keep moving your mouse wheel more than a couple of times after you reach the end of the page..?
Very hard to do on a trackpad :P
Quote
I changed Class-Notifier's to remove the abstract keyword, but I need to access the current notifier's name, so how do I do it..?
Wait, what? Why? That's an abstract class, I'm fairly sure it'll cause a fatal error if you just remove the abstract keyword...even if it doesn't have any abstract function it'll always be an abstract class. It's not supposed to be created as an instance.
Quote
All in all, there's not much to be done in a notifier, and if you're writing a notification for a thought, I'd even dare to say, it's the same: you'd want to have the 'default' code in a parent object, and the actual notifiers would just need to trust it, is all.
If code can be standardised, go for it. However we can always leave them if a notifier needs to do something. getProfile also handles profile configuration fields (which I actually use for some of my notifiers), so it's useful for that but can have a default implementation I guess.
Quote
The issue, though, might be to create a new parent object for thought notifications, or media notifications, and I don't know how best to do that, especially, hmm, if we can't determine first-hand what type the notification is, can we...?
No point, really. There will be slight differences which need to be handled on a per notifier basis, I think it's best to abstract things into notifier and type and let notifier handle everything instead of standardising too much stuff.
32
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 25th, 2013, 10:04 AM »
Okay, how can I disable infinite scrolling? It's annoying when trying to quick reply.

Oh what the hell, the idea of object type just hit me. One can have likes_post, likes_thought or simply likes with post, thought, media_comment etc. and mentions with different object type. You mind if I do this?
33
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 25th, 2013, 07:56 AM »
Not replying to all, kinda stuck IRL but will reply to a couple of points
Quote
It's a bit fucked up... First of all, the notifiers aren't auto-loading, they're explicitly loaded and invoked in the initializer, and a hook is used to allow for other notifiers to plug into it. Seriously..? :-/
How else do I figure out what all notifiers are available?
Quote
Why is weNotif called that way (Wedge standard is "wefirstletters", all lowercase), and why is it an object to begin with?
You renamed it weNotif, it was WeNotif :P. It's an object because I wuv objects, seriously, it's just a personal preference.
Quote
This way, I can easily do a notification for a thought, with 'Likes likes thought' for instance... Likes.php could then get the 'thought' request, and if it doesn't support it, make a request to something, so that it autoloads it... From a plugin, for instance. But I'm not a specialist of object management, so... It's a bit over my skill level, I guess.
In the process you end up making Notifiers an if/else maze since they will be acting like two notifiers in one (really, likes_thought and likes_post will have almost nothing in common), they're better served as independent notifiers. And I was passing notifier objects because of type strictness and all (less headache and more clean stuff).
Quote
Also, I modified your template to ensure that the periodical e-mail doesn't use any HTML, which it did in your version, hmmm... Who cares, this e-mail has yet to be sent to anyone, anyway... :P
You know right that sendmail function is perfectly capable of handling HTML content, you just need to set the $send_html flag to true? Periodical e-mail already does that and when I received my periodical from localhost it was displaying it fine. Yeah though I wasn't too sure it did any good (the HTML formatting)
34
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 22nd, 2013, 06:13 PM »
Quote
Because that's what most notifications will be about... This is a forum, right..?
I want it to be impartial, plus you got a huge freaking gallery inside the forum so I'd doubt that it's just a forum :P.
Quote
Perhaps because I imposed this one upon you... ;)
And it was a good idea, and it should be extensible. Maybe a crazy plugin author gets a good idea and implements something else for their notifier, it doesn't hurt to keep that option open.
Quote
First of all, the different files are still fuzzy even to me. Class-Notification.php and Notifications.php are too much alike in their naming. I've come to learn that basically, Notifications.php should have been called Subs-Notification(s).php, since it's a helper class, but having the action handler within it makes little sense. This is probably why support for class::method wasn't added until recently to Wedge's action router, and it was added specifically for your code... Not a biggie, but it makes one wonder whether this was well thought out..? Maybe it should not be a class at all in the first place...
Notifications.php is the "controller" here, it handles the notifications logic. If you have a better name go ahead, but I've thought a lot about my code and to me it makes perfect sense.
Quote
Also, maybe Notification::issue shouldn't be a method. Maybe it should be issue_notification(...), and this redirects to your Notification object, or something... Notification::issue implies that the notif object is loaded, which shouldn't be needed, at least not at all times. I don't know. Maybe it should, but it's just strange to me.
Hm, maybe. Notification::issue kind of made sense to me since Notification class is sort of the "model" for doing the DB interactions with individual Notification rows. Although it can be made different, not sure.
Quote
Notifiers are stored in the database with a plural in the name. A single notifications should be sorted as a 'like' or 'mention', not as a 'likes' or 'mentions'...
I read it like this notifier handles "likes" so it gets the name "likes", although this is a completely arbitrary issue since no one really reads the DB for grammar.
Quote
I have a hard time understanding why id_object gets its own database field. I mean, is that only for a case where you'd want to mark all notifications from a single topic as read once you read that topic..? But (1) there's no way to be sure the user has read the entire topic anyway, (2) I don't even think the code is currently checking unread notifications for a topic being read. Or is it..?
Why shouldn't id_object be a field? It is the object for which the notification is issued, and has a bunch of uses including multiple handling as @Arantor said. Anything stored in data field is mostly (almost purely) for presentation purposes only. As far as key goes...I forgot :P.

And in my world, there is no "object type". There is the notifications core, and then there are notifiers who do whatever they want. I don't want to abstract it further.
35
Off-topic / Re: YAQT (yet another quote thread)
« on June 21st, 2013, 06:19 PM »
Quote from Arantor on June 21st, 2013, 06:15 PM
Of course, one methodology of nailing that is simply to strip nesting of quotes so that when you quote a post you're only quoting that one post so you wouldn't get crazy amounts of notifications. So that when a post is quoted, only that post's owner gets notified.
That's what I'm doing ATM.
36
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 20th, 2013, 07:08 PM »
Quote from Nao on June 20th, 2013, 06:20 PM
The problem is that I often find myself stuck in object hell...

Example: want to have getPreview() return whatever the notifier wants, but have it return topic stuff by default. Moved code from Notifications.php to Class-Notifier.php, with no special treatment... And, I don't even know if it's the correct target. I suppose it is, but sure..? Nope.

Also, I really think it's best to store the object type in its own field in the database, rather than in the data field. Makes it easier to avoid duplicate entries... And to me, it's better than creating multiple notifier names, one for each object type... Urgh!
Why would you want to have it return topic stuff by default? The thing is, I don't want to pre-define a lot of behaviour, mostly because then authors don't touch and the experience becomes bad again. Plus I don't want to add pre-defined behaviour for "special" object types, that goes against my model. I want it to be absolutely "core", in the sense it should be as unassuming as possible. I'm assuming a few cases (mostly such as getIcon in which it returns the avatar) because they are more or less global and can apply to all. That is why in my view getObjectType is absolutely redundent and not a good idea. I don't think having multiple notifiers is a bad thing, mostly because it gives every notifier an equal chance to implement the same experience for themselves and we don't define anything for them (any notifier that is in the core can't do anything more or less than any other notifier that might be a plugin)
37
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 20th, 2013, 06:09 PM »
Quote from Nao on June 19th, 2013, 06:05 PM
Quote from Dragooon on June 19th, 2013, 08:25 AM
Quote
No. They can't disable likes notifs for topics, while keeping likes notifs for media items... See what I mean?
They will be able to. Since the notifier for topics will never be same as the notifier for media items, it'll be a different notifier. Like there are different notifier for quotes and mentions. getObjectType is more or less redundant with individual notifier, the whole idea is to implement different notifiers for different individual items.
Why don't notifier (plugins) inherit from the Notifications class rather than Notifier, anyway..?
Because they are Notifiers not Notifications :P, it's sort of subjective I guess. That made most sense to me.
Quote from Nao on June 19th, 2013, 06:08 PM
Quote from Dragooon on June 19th, 2013, 01:27 PM
This seems better suited for my generic button controls idea. Basically I wanted notifiers to be able to add their own control buttons which can do whatever they want, that way they can have more control on a per-notifier basis instead of we determining their behaviour.
Hmmm... That, I could possibly do, I guess... I'll have a look. That would also, I guess, solve some of our problems...

Basically, we'd need to move the preview action to another function in the Notifier object, is that it..?
I'm not sure, I was thinking of a new function returning an array of buttons which are then embedded.
38
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 19th, 2013, 01:27 PM »
Quote
2/ More options in notifications. This is quite simple, here... When you preview a message, you'll get a new line below it, with several links: "Mark as unread", "In context", and "First unread". "First unread" is only valid for topics, which is why I needed to implement (1), so whatever. It leads you to the first unread post in the related topic, or at least it tells you that there are unread posts *before* the notification's, allowing you to catch up with them, instead of losing the unread count when going to the notif post in context. I don't know if I'm clear enough, uh...? Just wanna know what you guys think about these...
This seems better suited for my generic button controls idea. Basically I wanted notifiers to be able to add their own control buttons which can do whatever they want, that way they can have more control on a per-notifier basis instead of we determining their behaviour.

Do whatever the hell you want with emails, I can use all the help I can get there. I have no idea how to simplify those :P
39
Features / Re: More useless nonsense
« on June 19th, 2013, 11:15 AM »
Kill it with fire!
40
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 19th, 2013, 08:25 AM »
Quote
No. They can't disable likes notifs for topics, while keeping likes notifs for media items... See what I mean?
They will be able to. Since the notifier for topics will never be same as the notifier for media items, it'll be a different notifier. Like there are different notifier for quotes and mentions. getObjectType is more or less redundant with individual notifier, the whole idea is to implement different notifiers for different individual items.
41
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 18th, 2013, 06:14 PM »
Quote from Nao on June 18th, 2013, 06:08 PM
Using getName() for object type, implies that for instance, users can disable notifications for topics but not for media items, things like that...
It sounds like UI nightmare, to me. It should just be 'likes', and then have a getObjectType method, which returns 'topic' by default.

It really makes more sense to store the object type. I'll assume it's stored in the data field, in the meantime, until we agree on something...
What you're trying to do sounds like a coding nightmare. Users can disable individual notifiers, and they can already do that. Not sure how it can be further simplified without complicating the coding process.
42
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 18th, 2013, 05:02 PM »
No no no, technically it should be likes_post and likes_thought. Like when it returns "mentions" it is assumed it's for a post since nothing else can be mentioned. Why would you want getObjectType though? Defining specific behaviour for specific types goes against the whole notifications idea.

I'll reply to the rest of it later tonight.
43
Plugins / [Plugin] Re: Notifications system (1.0)
« on June 18th, 2013, 04:23 PM »
@Nao: Long post is long, I'll answer the first point. "notifier" column is your type and it works fine with multiple types of notifiers. Basically, Notifier is your "type handler". It handles different types of objects, it already does what you're trying to do. Right now I'm not assuming jack, it's all handled on a per-notifier basis. Mentions is a "notifier" which issues Notifications of type mention, the core routes that back to the notifier and asks what to do (all the getText, getURL are for this). Similarly, Likes is also a notifier for specifically handling the notifications of "likes" type. For a plugin to implement a new type of notification, they create a new class derived from Notifier and add their own type. getType is already there as notifier is their type, so basically getNotifier is what you're looking for. If you want the string interpretaiton of a specific notifier,
$notification->getNotifier()->getName()
is what you want to do.

The difference between notifier and notification classes is:
Notification is a sort of helper class for handling individual rows of notifications in the DB, it doesn't do much except make our lives easier for storing new objects/reading existing ones.
Notifier is what actually handles the notifications, they interpret the data stored in the Notifications object and tell what should it's text, URL, preview etc. should be. Basically handle each type of notification's behavior. See the classes defined in the notifs directory, they tell different ways of handling different notifications.

If you're still unclear about how it all works and why it is the way it is, I can make a detailed documentation. Currently I'm out of home till late night so I can't do it right now.
44
Off-topic / Re: What type of programmer are you?
« on June 16th, 2013, 08:39 AM »
Quote from live627 on June 16th, 2013, 08:37 AM
Hallf-assed theoretical perfectionist.
So you're only perfect in theory?
45
Bug reports / Re: Periodic notifications don't seem to work
« on June 16th, 2013, 08:37 AM »
Okay, on a fresh Wedge installation periodical seems to be working. So it might be a problem just here.