Wedge

You're talking about e-mails..?

- Color: that's logical, since you rewrote it to use classes for groups, instead of styles. The only way to fix, would be to have an alternate codepath where we do the old-school rewrite, but I don't know if it's worth it...

- We're still sending e-mails in text format, not HTML, so we still have <a ...> links, instead of text links.

- My local install has an alternative version, which at least fixes URLs to prevent them from being cut off (and, of course, goes through ob_sessrewrite in the e-mail parser). I have yet to commit it, because... Well, it's only worth it, if we're sending HTML...

No, I'm talking about the *preview* pulled via AJAX... it has the wrong link in it and no styling.

See attached, notice the link that my cursor is under still has a <URL> in it and the preview doesn't have the colour groups.

So, I'm back working a bit on notifications, here's what I'm trying to add...

1/ Object type: return the type of the notification's object, of course. Right now, we're always assuming this to be a topic, when it could very well be something else, like a thought. Here's where I'm having trouble:

* The database only has an id_object, but no type for it. Meaning, at this point, you really can't specify a type per-object, unless I forgot something else... Can you help on this, Dragooon? Or anyone else... I don't see any way, other than adding a database entry... It was built to support multiple types, right..? Otherwise, it'd have been called id_topic, not id_object...

* What's the difference between these..? (In Class-Notification)


To be specific, I don't know if my getType() method should relay to $this->notifier, or not. I also really don't know why there's a difference, in here... (?)
I guess I'm having trouble, mostly with what a notifier is, and why it's needed, as opposed to just having everything in the notification class... (?)

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...

3/ E-mail notifications. I'm working hard on this...

* The first thing I need to fix so hard, is the HTML e-mails. To solve this, I've decided to simply force plugin authors to add an extra language entry, so there's one for the popup notification, and one for the e-mail. That way, you can have a purely text e-mail, and still use HTML in the popup. I'm not comfortable with the various notification objects, so I'll just commit something a bit horrible, and I'm counting on you guys to offer shorter, better rewrites, as I'm only doing the bulk of it, and don't want to mess my mind with abstract stuff... ^^

* Second thing, I need to ensure that pretty URLs are applied to the message, but I can't go through ob_sessrewrite but it'll do other things, like cutting URLs. Two solutions: either I *do* go through ob_sessrewrite but with a special setting saying "Okay, this is for an e-mail, so don't screw up with it!", which is what is in my local code for now; or, I simply do it à la redirectexit(), which is call pretty URL transformation independently, and be done with it. I'm thinking I'll go with the second one, but I need to know if you guys agree, i.e. do you think there's something else to transform in e-mails..?

* Thirdly, I changed all %s and %d to {VARIABLE_NAMES}, like in EmailTemplates, which makes sense, since it has the same purpose. Plus, it's more self-explained... Don't really need an opinion on this, I'll do it this way anyway, from now on... ;) I also chose going with underscores, because e-mail templates use {VARIABLENAMES}, which I find less readable, but I can't bother to fix THESE now... Eh.

* And lastly, right now the mentions notification will show something like, "(link to user) mentioned you in (link to post)", while likes will show, "(user name) liked your post (post name)". The first has links, the second has raw text. Main advantage of the first one, you obviously can directly click on these links (which I don't like because of the "first unread" issue I discussed above), and also see the member type, since it has the associated class, which the likes notifications don't have. Of course, the first won't show correctly in e-mails, so I'm trying to determine which is best... (a) just let the HTML be as it is, with links and all, and turn them to pure text at notification e-mail sending time. It's easy enough to do, with just a simple strip_tags, and would save authors the hassle of providing two strongly different language strings. However, I was thinking, maybe I could go one step further, and instead of requiring two language strings, I could turn a regular link to Nao into "Nao (http://wedge.org/profile/Nao/)", right in the text. Thus, instead of having an e-mail string like "...mentioned you in {POST_TITLE}, which you can read here: {POST_URL}", we could have "...mentioned you in {POST}.", where {POST} is turned into a link in HTML, and when used for e-mails, into a simple text, "{POST_TITLE} ({POST_URL})"...
What do you think?

I know it's a lot, but I'm kind of stuck in all of these areas right now, and I don't know which direction to go, so any opinions, would be greatly appreciated... :)

Oh... Or, I could do a 'generic' string for e-mails, appended to any notifications:

Link to the user's profile:
{MEMBER_HREF}

Link to the post: (if this is a topic, of course...)
{POST_HREF}

I could add all of these links by analyzing the contents of the string. If it has {MEMBER} in it, strip the link, then add it at the bottom, etc...

@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, 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.

getName() would return 'likes'. This would assume that all likes are for posts (or thoughts), when they can be for either of them...
Thus, getType() (or getObjectType(), if you prefer), would return 'topic' or 'thought' (or 'media' or whatever, once I implement liking media items...), depending on the target.

See what I mean..?

Anyway, other than that, happy to receive any feedback from you on the other matters..?
Sorry about the long post. Someone has to take Pete's place when he's on vacation... :lol:

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.

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.

Sorry work so not read the latest messages,

Why don't notifier (plugins) inherit from the Notifications class rather than Notifier, anyway..?