Hello Berdir, Hello Dave,

Google says here: 35 (weeks a year) = 0.67078777 . What means more than half a year. I took the weeks from the last commit on pmgrowl telling me that there is another idea for it needed maybe. Because I know that from my work how fast the to-do list explodes. (just joking a lil' bit)

I thought about my last comment in the issue queue of pmgrowl depending jGrowl plugin, where I asked around letting us all put the jGrowl plugin in sites/all/libraries as recommended in Drupal 7 for better libraries handling, caching and updates. Sadly no answer. Nice messages uses the same plugin (which I co-maintain), thats why. But thinking about it longer for a while now, it brought me to a complete other idea:

There are about 3,4,5 acceptable lightweight jQuery plugins out there handling message popups and I start to think about merging (and splitting another way around) our modules for a better manner and for more modular optimizing in the Drupal way of live. I am willing to maintain.

The idea behind is to merge your message addon module (pmgrowl) for private msg with our Nice messages module into one plus support for other plugins because it seems, the code must be very similar on the load of the plugin and the bridge to the js settings.

Then (just maybe) I would split it again up to the message providing module on one side, and the using module list providing module on the other side again.

So one module could be maintained easely to catch all possible plugins and its setting-adaptions for use in Drupal admin and make the user switch between them (like WYSIWYG bridge does for editors). And the other one will support bridging to several other modules which would like to have live info message support. Lets say, like system messages, private msg, forum, OG, comment subscription informer or any others.

I am still not sure if the second one is needed, or if the bridging one is enough (to leave some work for the using module developers). But I think this would empower the modern way of interaction on a website easely with the prevered popup plugin of choice centered in one module taking care of performance and script loads providing one API for other modules, instead of trying around with several barely maintained small modules, handling different popup situations with 6 new js-file loads in the header.

Let me know what do you think. Sincerely yours,
Digidog

Comments

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

This module does more than any other jqrowl plugin that I've seen so far.

It implements active polling to check for new messages without having to reload the site. Additionally, I would like to see integration with the node.js project which allows event-based notifications without the need for polling. Both of these things do not make much sense for drupal_set_message() messages, which are only triggered when you actually visit the site.

Additionally, we do display more than just a message, we display private messages including support for the author image, if enabled and reply/view links. This is done through a theme function. There is also a setting to choose if there should be a notification for each new message or just a single notification that there *are* messages.

To implement that active polling, we need to keep track of which messages we already sent to users.

I am not sure if I see the point on depending on another module when we still have to do all of this ourself. I think such a module would at least need to provide a well-working polling framework with support for js.module (to solve issues like #802128: messages/pmgrowl_json showing as page hits. And it would be even better if it also would provide integration with node.js. So, let's start with simple steps, like implementing #1254990: moving jGrowl to libraries for multiple use, so that our modules can be nice to each other, shall we? ;)

Also closing #474062: Merge with jgrowl module as duplicate.

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented

So, let's start with simple steps, like implementing #1254990: moving jGrowl to libraries for multiple use, so that our modules can be nice to each other, shall we? ;)

I absolutely agree :) Already done here with latest dev shot.

Back to the other points you mentioned I only agree partially. That the pmgrowl module has more tasks to handle is clear. It's because, it isn't for picking up a system message, it is for being an implementation of your awesome privat msg module, which - let me say - I really love.

But I only agree partially because all you describe above is part of the second module I mentioned. And I also mentioned/thought about that, if isn't it better to leave it by the developers of that modules. That's what you actually describe and prefer here above. But this doesn't hit the outsourcing API for jQuery popup messages, I talk about. I think I was describing the scenario the wrong way around. Merging is confusing here, especially because of all the tasks your module has to handle. The topic is more about outsourcing a jQuery popup bridge/ switch / API, whatever.

Then your calls to it would only be drupal_popup(); or something :-)

Thanks for your fast reply. It helped me to get things clear in mind. The mentionend bridge module could be done without having to merge anything. So I will try to start it and hope of your consultation to make it work with your fantastic modules and with the Nice message module for system messages.

I am not 100% sure about closing the last topic you mentioned above as duplicate. It has been started of somebody else, and I did hijack it a little bit on the end, professedly. The starting point was something else there, I think.

Best regards,Sincerely Digidog

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented
Title: Merging jGrowl modules and others to a jQuery popup plugin API (I am willing to maintain) » What about a jQuery popup plugin API for all modules needing popup calls
Priority: Major » Normal

Changed the title to become more specific if any possible further discussion.

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Hm.

Yes, you are probably right, however, remember that we can't call a drupal_popup() php function in our polling page callback. Because in there, we return notifications as JSON, and then they are directly added to jgrowl on the client side. So the only thing you could provide is a javascript function, which we can call in our polling script. And that would save us almost nothing compared to what we have now.

So that's why I thought a generic polling system (or as said, events through node.js) would be interesting. It would have to be optional, of course. There could be a hook where modules can say if they implement a polling callback/hook. And if there is at least a single module which provides this, the polling could be enabled.

The advantage is that multiple polling callbacks could be executed with a single callback, for example there could be integration with the notifications module which can send notifications for all kinds of events.

But we can start simple and you implement your basic bridge module, which makes sure that jgrowl.js is installed properly and provides both a php and a JS function to display messages through it. Then we can try to port this module to it and we'll quickly see what it brings us.

dqd’s picture

dqd
Location London | N.Y.C | Paris | Hamburg | Berlin
commented

So that's why I thought a generic polling system (or as said, events through node.js) would be interesting. ... The advantage is that multiple polling callbacks could be executed with a single callback, for example there could be integration with the notifications module which can send notifications for all kinds of events.

agree. let me know more when it goes on ...

But we can start simple and you implement your basic bridge module, which makes sure that jgrowl.js is installed properly and provides both a php and a JS function to display messages through it. Then we can try to port this module to it and we'll quickly see what it brings us.

Sounds not bad at all. Simple. But sounds more like a expansion of Nice messages than like a new thingy. Why installing 2 modules to have system messages popups and a bridge for other modules to do the same. I pin it on the To-Do @ project page.

Ups ... I see now, I already did it, a week ago ... funny ...

berdir’s picture

berdir
Primary language German
Location Switzerland
commented

Sounds not bad at all. Simple. But sounds more like a expansion of Nice messages than like a new thingy. Why installing 2 modules to have system messages popups and a bridge for other modules to do the same. I pin it on the To-Do @ project page.

Sure. I would however recommend making the display of system message optional, not all users might want this but still depend on the API for something else. While this could be a configuration setting, I think it would actually make sense to move this into a separate module (within the same project), which could then also serve as an example implementation of your API.

Another idea I just had. Your module could in fact just provide a nice_messages_add_message($message, $uid = NULL) API. Withing that function, multiple things could happen:
- If $uid is not set or the active user and this is a normal request, simply display that message. Like it happens now.
- If not, persist the message. On the next regular request of this user, display it as displayed above or, if a poll request comes in, return it.
- Forward the message to the user through node.js or another service, if configured.

The advantage of this would be the very simple fire-and-forget API. A module just needs to set a message and it will reach the user in some way or another. But it will also not be trivial to implement, especially the advanced stuff like polling/node.js.

But I'm just thinking out loud here, again, let's start with the basics.