Better temperatures here today, so I figured I could get more work done on Wedge...
In terms of innovations, I'm not particularly fond of trying to figure out new ones, but I have to say it feels good to do things that I haven't seen done elsewhere, and I'm trying not to get stopped by 'reality', and do things my own way.
So, one of the things that have always bothered me, is merging of double-posts. It's a feature I've loved since day one (as you may remember from my stint on the 'Merge double posts' mod on sm.org, and generally adding the same feature in here by default), but that was in contradiction with another feature I wanted in: threaded view.
The trouble with threadles
Threaded view, as controversial it is, as 'outdated' it might be to some (and I'm not saying it isn't), implies that if you answer every single post in a thread, you'll end up with a lot of double posts, but if you start merging them, you'll end up with a long post that loses its association to the thread parents, and that is, if you'll forgive me, absolutely FUCKED UP.
I started considering doing a 'soft' merging of these posts, i.e.: the posts are not physically merged in the database, and instead they're only merged in the template if there are two or more posts by a same user in the same level.
Skeletons in the closet
Here's where it gets complicated. Ever since I introduced mini-skeletons for topic posts, it became harder to do anything like rendering only parts of a post. I made a modification to the skeleton class, where you could specifically ask it to render just a single layer from a skeleton, and I still have that code around (uncommitted), but it was getting too complex, even for me, and I wrote the whole damn thing... Essentially, it's too fragile.
I'm still considering doing it this way, though, because it's so 'clean'. But the code changes, alas, wouldn't be... So, this morning, I figured I'd try doing it with my favorite little hobby...
Ne vous déplaise, en dansant la Javanaise... ♫
And it worked. I wrote 10 lines of JavaScript, about 370 unminified bytes, and it does exactly what I wanted.
Actually, I even tested it on wedge.org, so you can get a feel of it...
http://wedge.org/pub/feats/6108/new-revs/2160/
As you can see, all of the double posts are now merged into one, and they all retain their respective action bars. Really, it's just all about removing the duplicate signature and user box areas.
It takes one to know one.
There are a few caveats to this technique, and I'm weary of committing my code, so here's the list of problems, and possible fixes, and I'd really, REALLY appreciate if you guys could share your feelings about this implementation, and whether it's worth it.
- Since it executes at render time, you can for a very short time see the unmodified posts. I've fixed this by putting the code into the script.js file, instead of topic.js, as it executes earlier, but it's not exactly a noticeable improvement, so I'll probably end up putting it back into topic.js later, and anyway, if you don't actually refresh the page, it's unlikely you'll notice the difference when simply browsing through pages, which is what you'll be doing most of the time, anyway.
- This doesn't fix postbg/postbg2 alternance. Well, I'll fix that one next... But, more importantly, because it's JS, it means that if you do alternances differently (or not at all) in your version, it'll be broken by my upcoming fix.
- Anchor links are broken. e.g., if you're in a soft-merged post, and you click the subject, you'll end up on the same page, but at the top, because it won't find the message ID, which was suppressed by JS. A possible fix would be to just move the message ID to the postheader for the corresponding soft-merged post, but it'll also break any code that accesses .root and then gets the message ID through this. Very, very bad idea either way... I need to fix this one, ASAP.
- I haven't tested all action menu options, maybe some will be broken, potentially by the change just above this one.
So... Thoughts, please..? Or just Likes :P
In terms of innovations, I'm not particularly fond of trying to figure out new ones, but I have to say it feels good to do things that I haven't seen done elsewhere, and I'm trying not to get stopped by 'reality', and do things my own way.
So, one of the things that have always bothered me, is merging of double-posts. It's a feature I've loved since day one (as you may remember from my stint on the 'Merge double posts' mod on sm.org, and generally adding the same feature in here by default), but that was in contradiction with another feature I wanted in: threaded view.
The trouble with threadles
Threaded view, as controversial it is, as 'outdated' it might be to some (and I'm not saying it isn't), implies that if you answer every single post in a thread, you'll end up with a lot of double posts, but if you start merging them, you'll end up with a long post that loses its association to the thread parents, and that is, if you'll forgive me, absolutely FUCKED UP.
I started considering doing a 'soft' merging of these posts, i.e.: the posts are not physically merged in the database, and instead they're only merged in the template if there are two or more posts by a same user in the same level.
Skeletons in the closet
Here's where it gets complicated. Ever since I introduced mini-skeletons for topic posts, it became harder to do anything like rendering only parts of a post. I made a modification to the skeleton class, where you could specifically ask it to render just a single layer from a skeleton, and I still have that code around (uncommitted), but it was getting too complex, even for me, and I wrote the whole damn thing... Essentially, it's too fragile.
I'm still considering doing it this way, though, because it's so 'clean'. But the code changes, alas, wouldn't be... So, this morning, I figured I'd try doing it with my favorite little hobby...
Ne vous déplaise, en dansant la Javanaise... ♫
And it worked. I wrote 10 lines of JavaScript, about 370 unminified bytes, and it does exactly what I wanted.
Actually, I even tested it on wedge.org, so you can get a feel of it...
http://wedge.org/pub/feats/6108/new-revs/2160/
As you can see, all of the double posts are now merged into one, and they all retain their respective action bars. Really, it's just all about removing the duplicate signature and user box areas.
It takes one to know one.
There are a few caveats to this technique, and I'm weary of committing my code, so here's the list of problems, and possible fixes, and I'd really, REALLY appreciate if you guys could share your feelings about this implementation, and whether it's worth it.
- Since it executes at render time, you can for a very short time see the unmodified posts. I've fixed this by putting the code into the script.js file, instead of topic.js, as it executes earlier, but it's not exactly a noticeable improvement, so I'll probably end up putting it back into topic.js later, and anyway, if you don't actually refresh the page, it's unlikely you'll notice the difference when simply browsing through pages, which is what you'll be doing most of the time, anyway.
- This doesn't fix postbg/postbg2 alternance. Well, I'll fix that one next... But, more importantly, because it's JS, it means that if you do alternances differently (or not at all) in your version, it'll be broken by my upcoming fix.
- Anchor links are broken. e.g., if you're in a soft-merged post, and you click the subject, you'll end up on the same page, but at the top, because it won't find the message ID, which was suppressed by JS. A possible fix would be to just move the message ID to the postheader for the corresponding soft-merged post, but it'll also break any code that accesses .root and then gets the message ID through this. Very, very bad idea either way... I need to fix this one, ASAP.
- I haven't tested all action menu options, maybe some will be broken, potentially by the change just above this one.
So... Thoughts, please..? Or just Likes :P