How to put a specific topic into a box for a shoutbox plugin


(Joe Seyfried) #1

Hi all,

since my original request got a bit lost and I have done some research since, I will open a separate topic since this touches some fundamental stuff on how to extend and re-use Discourse components, I guess. What I want to do for my shoutbox plugin is put a topic (say, with a fixed ID 1243; I have the basics here already figured out) into a dropdown box like this:

…click the bullhorn icon and get this:

…for this, I have sucessfully re-defined the header.hbs where I put the icon, and have introduced a new template named, say, shoutbox.hbs. In this template, I have already copied the relevant excerpt of topic.hbs in order to fill it with the contents of topic 1234.

Now we’re approaching the area where I am stuck: no matter what I extend, model, view or controller, it seems I cannot simply inject the topic ID somewhere in order to fill the shoutbox.hbs template with data. I’m also not clear about the role of PostStream and whether or not I need to do something with it. Introducing an extension to the topic route is also not really clear to me, since the original code topic.js.es6 in discourse/routes extends right into an instance of that class - can I extend that or do I have to copy it?

And hints where to pull would be great. Extensive debugging was a cul de sac, too because the routes/topic.js.es6 seems to be the only non-Ember call on the stack, so I guess I should start there, but have got no clue on how to do that…

Has anyone built something for informal status updates - Chat?
(Jeff Atwood) #2

Can you offer some advice here @eviltrout?

(Kane York) #3

The route creates the model like this:

this.setupParams(Topic.create(_.omit(params, 'username_filters', 'filter')), queryParams);

Which doesn’t actually load any data from the server. Instead, it proceeds to have Ember render a loading spinner while the post-stream code loads the actual posts. topic.hbs, line 7: {{if postStream.loaded}}

The Topic/PostStream interactions are a hairy part of the JS code, rivaled mainly by the interactions between composer.js, composer.js.es6, and composer.js.es6.

(Joe Seyfried) #4

Ok, great. Sounds like all I have to do is invoke the setupParams? Where should I do that? Should I extend the route? I was under the impression that (normally), I don’t have to fiddle around with the route because I have the template loaded with all the options to extend model, view or controller as usual! But it seems like this isn’t enough here…

(Kane York) #5

Nope :confused:

I think you might be better off just implementing your own topic and post "view"s and controllers.

(Joe Seyfried) #6

Oh. :unamused: That bad? *looking in @eviltrout’s direction*?

So maybe I’m back at the iframe-approach in that case… :grimacing:

(Kane York) #7

Not quite. You can write your own Handlebars templates.

My point was that a typical topic view wouldn’t really fit in there.

(Joe Seyfried) #8

Ok - although it feels a bit odd:

You’re telling me: “go ahead and invent something round that turns and can be used for transportation”, while you have a perfect SUV sitting in your garage, on which I could apply a display: none to 3 of its wheels and the rest of the car?

I will give it a shot. I’m a bit concerned about (in)finite scrolling, and how to re-invent that. What my view should do while not displayed and so on…

But, maybe it’ll be fun, too. :wink:

(Robin Ward) #9

I am trying to understand the flow of data here. You only want a single topic in the shoutbox? Is it the same as the current topic the user is looking at or some kind of different topic you need to fetch?

Babble - A Chat Plugin [ARCHIVE]
(Joe Seyfried) #10

Yes, the plugin will create a special topic, unlist it, and make it accessible from the shoutbox icon. You can click this at any time, also when viewing a different topic, a category or whatever.

Nope, it is always the special shoutbox topic. The plugin will create this when it’s first launched:

Yes. The server side part of the plugin will create the topic and push the ID to the client.

(Robin Ward) #11

What are you showing in there? Just the topic title and link? Or some kind of special data about it? How often does that data need to refresh?

(Joe Seyfried) #12

It should look lile this (that’s my iframe version/mockup):

So basically, that’s the whole topic (with some removals UI-wise), and it should be live, like any Discourse topic view.

(Ani) #13

Are you trying to make a shout box?

(Joe Seyfried) #14


(Jacob Chapel) #15

@JSey I think you should do the work of creating your own Ember view and templates for this. Of course you can leverage much of what exists already, but having a custom view and templates gives you much more flexibility and you can fine tune it. Will also allow you to control more about it with configuration options either as a whole from the admin panel or even exposing options for users.

If I wasn’t so busy I’d take a look into the core pieces and point out what work would need to be done. (Mainly because I like to do that sort of stuff, it is fun to figure out how things are intended to work).

(Joe Seyfried) #16

I have a static view of the thing already working. My main concerns now are

  • endless scrolling and
  • live updates

of my view. I will try this one next: GitHub - eviltrout/ember-cloaking: Support for not rendering offscreen views in an Ember app for performance and see which of my problems remain intact. :smiley:

Thanks for the “almost” offer for help, @chapel. :wink:

(Robin Ward) #17

This is going to be really tricky to build! In particular leveraging the post stream and endless scrolling within a little pop up. Our scrolling code is related to a whole page, not a little frame, so I imagine you will have to edit a lot there.

I’d suggest starting with just the last few posts of a topic. The first obvious challenge is the data flow.

Typically in an ember application you fetch data when you visit a route, but yours is in a popup that can be visited at any page. In that case you will have to do something different.

I’d create a controller for your shoutbox. And once the shotbox is opened have it fetch the topic view and set it so it can be rendered. This is similar to how notifications work, although they put their data in “header” which seems wrong to me. It should be in the notification controller so the template points at it.

(Joe Seyfried) #18

Thanks for your input, Robin.

Since I kept banging into walls, I was afraid something might be substantially odd with my idea. Since you mention that Ember relies heavily on routes, I get the idea that maybe my idea of sticking the shoutbox into an iframe wasn’t the worst idea in the first place. Plus, I will have to create a detachable shoutbox view, too, since many people become so addicted to those things that they want it constantly open - which would boil down to open a new, pre-sized browser window with only the shoutbox view in it.

Now, a combination of the two approaches looks the most promising to me: create a controller and a specialized shoutbox view, route it via, say, and build the rest around that. What would you think of that approach?

(Robin Ward) #19

Sure, we have a standalone route for notifications too, although we have a much different UX for a full page version than for the pop up.

You will have an easier time building the full page, routable version, but having a controller for the little popup isn’t too hard either. You just have to load the data outside of a route, by a trigger when it opens.