I’ve been hanging out other forums where you can display code in a fancy way such as high-lighting keywords, brackets etc…
So shall we get something better for our forums?
Yea… that would be really nice. Pasted code looks always a bit… hmm… trashed? :>
However, generating good formatting takes a fair amout of cpu power… for a whole board at least.
Right now the board doesn’t have a lot of bottlenecks and I’m really glad that it’s that relyable, therefore I’m not sure if it’s really a good idea to change that. Maybe something half external, wich isn’t directly integrated?
Don’t know if the CPU power is really a problem, because most of the time users spend reading and not writing. And after all only a fraction of all forum posts contains code.
[quote]Don’t know if the CPU power is really a problem, because most of the time users spend reading and not writing. And after all only a fraction of all forum posts contains code.
[/quote]
Ah, but you under-estimate the gross incompetence of the majority of all forum-software authors. Really, 95% of it is rubbish, and burns performance.
E.g. last time I looked, it was normal for many of them to use 15 SQL queries to generate each page. Stupid, stupid, stupid.
OTOH, most boards just use a more powerful server when it gets slow, and it’s such a commodity market it’s barely worth anyone writing a really good one - and there’s so many many features that users want these days that it’s potentially a mammoth task to do it in-house, so we (nearly) all put up with it :).
Are you sure this forum is database driven? I think YaBB uses text files. But hey, this means 0 SQL queries instead of 15. ;D
15 queries ain’t that much. Last year i wrote a “small” forum application and it takes 5 queries at first time run to display the index page. 3 queries are used to gazer user and board informationen and check with security settings.
the rest two are needed to gazer all boards and the navigationbar.
But back to topic, in thus big board applications, 15 queries might be less…but the more horrible is the code.
I looked at a php board and the layout templates. They are really huge, mine only contains of 1000 line html code 
With some lesser functions ;D
The colored parsing might be moderated, even with some regular expressions. Give it a try.
[quote]15 queries ain’t that much.
[/quote]
15 is approximately 14 too many. Usually, each query has a large constant overhead (compared to e.g. fetching a few strings), and so 15 queries to fetch X amount of data can easily be 10 times slower than 1 query to fetch exactly the same data.
Sure, shoehorning into a single query sometimes makes hard-to-read SQL statements - but not normally for something as simple as a forum - and so you might perhaps aim for 2 or 3 queries instead. But definitely not double-digits. Unless you’ve profiled and are sure there’s no penalty (unlikely when using free databases…)
[quote]Are you sure this forum is database driven? I think YaBB uses text files. But hey, this means 0 SQL queries instead of 15. ;D
[/quote]
Even worse :P. I know that all the others use DBs (PhpBB, Invision, Discus, Gossamer, etc), and I thought YaBB did too; guess I must have assumed rather than checked?
2-3 Queries? Might be possible if its a really simple forum.
q1: get user rights
q2: read boards/threads/posts/user (inner joins)
q3: additional read for the navigation
Most stuff that forums end up going to double-digit queries for falls into two categories:
-
They aren’t confident enough to do complex joins, or are afraid of maintaining them (they can look quite scary to newbies), and so go for doing something in many queries that could have been done just as well in one
-
Stuff that should not be pulled directly from the DB, e.g “number of registered users”. It’s more than sufficient for this stuff to be cached in-memory and updated every hour; there’s no good reason for putting it into a query and adding unnecessary load on the DB. No-one really needs to know to the millisecond how many users are registered on the board ;D. Ditto any generally static navigation - it should be read from DB on startup, then cached.
Of course, as previously noted, if you have server-power to spare, you don’t care. If you can afford serious horsepower, you don’t care.
how will you cache the navigation?
I don’t know any sql command for that. Only a view might fit that.
Else it might be cached directly in the application, this way i haven’t thought yet.
@serverpower: hmm, i don’t use lame mysql. MS SQL and Oracle are really powerfull DBS.
@large queries: they should be also readable…
<cfquery datasource="#Application.boardSettings.DSN#" name="qGetBoards">
SELECT DISTINCT
B1.ID, B1.Name, B1.Description, B1.bCat, Count(*) -1 AS Level, B1.Threads, B1.Posts, B1.lastUser,B1.Lft, B1.Rgt,
B1.lastDate, B1.lastUser, B1.lastThread, B1.lastPost, Floor((B1.Rgt - B1.Lft - 1) / 2) AS Childs, B1.bActive,
T.Name AS ThreadName, T.ID AS ThreadID, U.Name AS UserName, U.ID AS UserID, (B1.Lft + B1.Rgt) % 2 AS LevelDiff
FROM <cfif Arguments.BoardID NEQ 1>BB_Boards B3, </cfif>BB_Boards B2,
BB_Boards B1 LEFT OUTER JOIN BB_User U ON B1.lastUser = U.ID
LEFT OUTER JOIN BB_Threads T ON B1.lastThread = T.ID
WHERE B1.Lft BETWEEN B2.Lft AND B2.Rgt
<cfif Arguments.BoardID NEQ 1>
AND B1.Lft BETWEEN B3.Lft AND B3.Rgt
AND B3.ID = <cfqueryparam cfsqltype="CF_SQL_INTEGER" value="#Arguments.BoardID#">
</cfif>
GROUP BY B1.ID, B1.Name, B1.Description, B1.bCat, B1.Lft, B1.Threads, B1.Posts,
B1.lastDate, B1.lastUser, B1.lastThread, B1.lastPost, B1.Rgt, B1.bActive,
T.Name, T.ID, U.Name, U.ID
ORDER BY B1.Lft
</cfquery>
that was my small query to gain everything important on the show board page.
[quote]how will you cache the navigation?
I don’t know any sql command for that. Only a view might fit that.
Else it might be cached directly in the application, this way i haven’t thought yet.
[/quote]
I was thinking of in-application caching, which was silly because of course most boards don’t HAVE an application - they are simply PHP direct to a DB. So, application-level caching moves from being “trivial” to being “mildly tricky”. At the very least, you could periodically output information into a file (with access to the crontab, it’s trivial; otherwise, you might have to again get cunning in order to simulate scheduled tasks) and then include that file in PHP pages…
SQL is never particularly readable; it’s one of the most unreadable languages I’ve ever seen 
(fine for toy examples, but any “real” query to a real DB tends to be impenetrable without extensive GUI support for formatting the query so that it becomes readable). For instance, debugging inner joins is always agonising if you have to do it on the unformatted plain text raw SQL query :(.
Php did not have an application. But Coldfusion did. The difference is that Coldfusion does cost some money And it is written in Java since Version 6 
Java Cool Dude. Those other forums are at gamedev, you have been reported and we know who you REALY are now…
[quote]Java Cool Dude. Those other forums are at gamedev, you have been reported and we know who you REALY are now…
[/quote]
Does i have to understand this?
confused
oO(might be a lack of my english knowledge)
So, as I understand it, the forum software would accept a post with a markup something like:
bunch of codethen parse the Java code simplistically (can’t know about context of code after all) and produced marked up output to store as the actual post. Of course, I’ve assumed a language specific markup. I’m not to sure how generic the parser/marker could be so that it decently handled php, sql, java etc. generically.
:-/
[quote]I’m not to sure how generic the parser/marker could be so that it decently handled php, sql, java etc. generically.
[/quote]
Best to write a generic core, and implement a plugin system that would load the correct syntax-colouring system based on the content.
FWIW, I believe the GameDev forums have something like this in place already.
Note that as this site is almost entirely based around Java technology, the benefits of such a system are much diminished. On a fragment-by-fragment basis, http://www.showsrc.com/ is handy. Also, if you’re posting links to Java source files, consider bouncing the links through showsrc as well.