quote:
Would this use PHP or something like Ajax?
Ajax is client-side, and relies on javascript (that's what the j stands for) to dynamically render (or re-render) sections of the page. It's reliance on javascript makes me reluctant to use it. RPoL still works without javascript, albiet with slightly reduced functionality. If we used Ajax then I'd probably have to create a completely separate site (fetching the same data) for the simpler hand-held devices, and that's not something I can do alone. I want to improve the rendering for such devices, but a separate site is too much work for one person.
Ajax, being client-side, still requires something server-side to render the page in the first place; something like ASP, PHP, Perl or ColdFusion.
So your question doesn't actually make sense with the "or" there, it'd make more sense as an "and".
But the answer to your question is that section of RPoL is still in Perl, so it'd be in that. Ajax, due to the fact I ruled out using javascript a dozen or so messages ago, wouldn't be used.
Anyhoo, wandering way too much off topic here.
quote:
PMs are exactly like the threads we're talking about, is there anyway to indicate how many messages are marked as UNREAD?
Alas PMs aren't the same as the game threads. Similar, yes, but not exactly like. While I'm opening the index for game threads and looking through them it's not much extra overhead to fetch information on the threads in the other grouping-mechanism. To grab how many private threads you have unread would require me to list every private thread you've got and compare them against your read/unread data; that doesn't have any real overhead when we're listing your PMs, we're already listing them, but to go through the PM list for each player every time they're on the front game screen is too much.
I think we're worrying too much about the polish without concern for the core functionality.
We've had a few alternate thread-grouping-mechanisms suggested, but everyone seems to be fixated on the tabbing mechanism. Don't get me wrong, it's a great idea, but is there a better way to do it? If we're going to go to all the effort of radically changing the way threads are grouped, shouldn't we make sure it's the best way?
With that in mind I'm going to continue to use "grouping-mechanism" instead of "tabs" until we can agree on the best grouping mechanism!
quote:
Also - how will it interact with Thread Groups? If a tab has only Groups that a player isn't part of, will they not see the tab at all? (I'm going with "tab" because it's shorter than "subsection")
Good question. A grouping-mechanism would be a way of doing exactly that, of grouping threads together. Groups, as we currently use them, are a way of limiting who has access to the thread. They do different things - Notices work fine with groups, and notices are a way of grouping threads together. Imagine notices were on a different tab already, that's how it'd work. There's nothing stopping a notice being only for group xx at the moment, that's how it'd work going forward.
One.. possibly large.. problem I've thought of is in the way the new message indicator works. It compares the date of the last thread you can see compared with the
most recent thread you have read. That's how the NMI on the front screen (and stickylist) works.
Once you go into the game and are listing the threads it can do a more thorough investigation, and does that by comparing the cookies you have (plus the database record of the
most recent thread you have read) to give individual read/unread indicators on each thread.
Now the simple and most efficient way to check threads within our other grouping-mechanisms would be to compare the newest thread post in each of those tabs and compare it to
the most recent thread you have read.
However if you go into a game and there's new threads in five grouping-mechanisms, once you've read one of the threads in one of the grouping-mechanisms,
the most recent thread you have read might now be greater than some or all of the newest threads in the other grouping-mechanisms, so the NMI indicators that were on for them would now be off, without you having read them.
In a nutshell -- once you read a thread in one of the grouping-mechanisms, the NMI indicator on the other grouping-mechanisms might turn off (will turn off if the thread you've read is newer than the most recent thread in each respective grouping-mechanism).