Wedge

I get the feeling that whatever you do, I'm going to end up rewriting it (or you are) because one of the things I want to do is introduce truly AJAXive posting,[1] which means fetching a single post entry with menus etc. and injecting it into the page. If we have the ability to pull one, pulling more is simply a change to the function. But that's going to have to wait until I get back. This C# is still kicking my arse.[2]

1.	Quick reply doesn't have to leave the page, in other words. It's been done for SMF, other platforms do it natively too. I see no reason why we shouldn't be able to.
2.	I mean, I'm using a third party component, and I took it to the author's site with an explanation of what I'm doing and his reply started, "Er... what?" because what I was doing was that messed up. Made perfect sense to me at the time, though he's right and I changed what I was doing.

Ajax quick reply is easy. I can write it if you want.
Problem is the same when it comes to adding plugin data though... other than that, it's just the same as doing infinite scrolling with one post.

One major issue is if someone else posted in the meantime. But then you can always do a hard redirect to the post page then...

If there are posts in the meantime, we can check that when saving the draft and offer to fetch them then and fetch them AJAXively. It works extremely well for XenForo...

The thing is, using iframes and whatnot is really not the best way when you're dealing with individual posts.

Yes, but you may not 'notice' the new posts, though... In general, you'd want to be informed that there have been more posts.
Also, don't forget that if you have 15 posts on a page, and you post a quick reply, you'll get the post on the same page, so if you're copying the URL of the page to show a friend, they may not see the post you were pointing to, because it's really on the next page, etc...

Short summary about infinite scrolling: I thought I had the 'perfect' UX for this, and implemented it. I was quite happy with it. Then I did some further research, and noticed that another forum software (Discourse) bragged about having infinite scrolling, but it seems like it only does it for topic lists, not for topic pages, so they took the easy way out, I'd say... Unfortunately, from my countless experiences, and observation of other non-forum implementations, I can only say one thing: infinite scrolling is only possible if you have one of these two implementations: either an app setup using a customized JS framework like Backbone.js (which would force a forum system to rewrite its JS entirely), or a setup where you know *beforehand* what the contents of the post will be, and you can control it... Because if you can control it, then you can easily get away with incremental rewrites of your JS to apply to the new posts, and you're good. It is doable for Wedge, *even* for video embeds, but this is where the limitation is: we have no way to know what plugins will do to posts, and while it's unrealistic to expect many plugins to apply JS to a post (and if they do, the author might be aware of things to do to update for the infinite scroll's new posts), and thus it might break at any point, which is not good... :-/

So, two possible solutions, I'd say...

- Rewrite the current JS more thoroughly, to 'ensure' everything will work fine, and expect plugin authors to be aware of this.
- Give up on Ajax loading of new posts, and instead turn my infinite scroller into a generic helper function. This is my fallback idea, and it makes sense: detect 'Previous' and 'Next' links, and if the mouse wheel shows intent to go to Prev/Next, automatically follow these links, which would be applicable to *any* page with a pageindex, such as the topic lists, topic pages, member lists, etc...

I don't really see myself do *both*, but it's also doable, I guess...
To begin with -- what do you think of this fallback solution, is it any good to you..?I tried iframes as content holders... And I gave up. It sucks, in so many ways. Then I tried iframes as temporary content holders, until I can move their contents to the main page, and destroy the iframe. Problem is: while the events get copied properly, the event's targets stay in the iframe. e.g., if you click 'Delete' on a post, the confirm box shows up in the iframe, not in the main page...
That was a real bummer, for me...

Still, I'm counting on your insights, maybe you're less lost than I am, eh.. ;)

When doing the callback for saving drafts, check if there's been new posts and if so, prompt the user just above the quick reply area, i.e. somewhere they'd probably notice while typing.

The fallback solution is a nice fallback but I can't immediately think of a reason why we can't do something more elegant. As a rule, I wouldn't be too worried about plugin authors doing totally crazy stuff. As long as they can extend the menus (which they would normally define in the first page load so it's always 'defined'), it should normally be sufficient. Plugin authors can suggest changes we can make - but ultimately they need to accommodate the code we make. It just means we generally need to write it once and get it right and they will just deal with it.

I don't have any ideas right now, but it's something I'm willing to look at when I get back.

Why would plugins be a problem? Theoretical guessing?

Okay, let's just say... You wrote a plugin that adds a bbcode. And that bbcode is related to a feature offered by an external service, and thus implements a script (add_js_file) that's located on another server. It's an example among plenty possible. It's very likely that it will break, in these conditions...

Unless I can get to do the iframe version, and then move the code, including events and scripts (and not re-running them), to the parent page, after it's finished loading. So far, I wasn't able to prevent alerts from being shown in the iframe, so...

Hook something?

Which is a classic example of what I already mentioned, actually.

If you're using that bbcode to add to the editor, you're going to have done that on the first page already because the editor will already have been loaded for quick reply (or not at all if QR is off, but then you don't need it for the other load either)

If you're using that bbcode to add to the page itself, trying to defer like that is going to likely get you into a mess anyway for all kinds of fun and exciting reasons. I have actually done this in the past and it's a complete pain in the arse to do correctly, though it is possible.[1]

Anyway. You're preparing a payload for the user. Use XML, contain the post contents in XML + CDATA tags (one per post? one for the lot? I dunno) and also include a block for scripts that page should be loading. Then you can dynamically check which ones are already loaded and exclude them and just add script tags at that point for the ones that need it. Same sort of deal with style sheets really.

I still don't really like the idea of having an iframe. There is one scenario we will need to deal with - SMF for reasons I have never entirely understood, does not play properly inside an iframe, the session can get messed up. We will need to investigate and figure that out.

1.	Game Memorial does it, incidentally, since the image embedding via lightbox in articles is actually a bbcode I added, which only runs if the bbcode is used.

How do you use IS on iOS? I noticed somewhere in this or anther  thread that you said it worked on mobile.

Just swipe to the bottom of the page, then again a few times when you reach it...

Doesn't seem to load the next page here on iOS 6.1.3 and safari... Edited to add tried weaving and wireless