I haven't actually switched my forums over yet, but what I wanted was a way
to be able to keep the formatting of all my topics/comments consistent and
yet changeable while not sacrificing speedy performance.
If you have a separate subpage for each comment, you can edit/delete
individual comments easily, import them and display them in any format you
want. But with a big bunch of comments it can affect speed. Not to mention
huge numbers of files on the server. If you put each comment on the current
page, the page loads fast, but it's hard to keep the look consistent if you
ever decide to change the format of the comments.
So my idea is simply this--to create a single comment page for each forum
page (forum.timestamp.comments) in the form of an info file that looks like
this:
timestamp1: some comment | poster
timestamp2: another comment | poster2
etc
Then you import all that data into the main forum page and create the page
layout dynamically.
As an exercise in minimalism, the following two pages can generate a
complete (somewhat sparse) forum. I post it just to give an idea what I was
thinking...
Forum page:
[[?forum.+|New Post]]
[(search group=forum type=number)]
Footer page:
[if number {p2} && ! set {action}]
[(search query={p}.comments template='//Posted <(time {+field})> by
{+#2}<br>{+#1}<br>')]
[form]
[box comment cols=50 rows=8][box]
[submit]
[command id {id}]
[command passdata comment,id mode=stash field={now} page={p}.comments]
[form]
[if]
Obviously you could polish this up a lot...
The advantage of this approach is if you ever decide to change the forum
layout (say add a profile pic or some kind of rating system), you simply
change the template in the footer search function. The entire forum is
upgraded instantly. On my site, my forums have gone through several
revisions--and some topics have three or more slightly different kinds of
comment boxes on them. I'm in the process now of stripping out the actual
comments and making their format all the same.
You could further create an index page for the entire forum (forum.info)
that looks like the following and gets updated with every new post and/or
comment:
forum.timestamp: title | author | last commmenter | number of comments
etc
>From this you could design a very fast display of the forum topics with the
appropriate information--just by scanning one info page (forum.info).
And of course you could set up a text index for the forum pages that would
make the forum searchable. Set an indexing rule on site.index that looks
like this:
forum: mode=text type=number group=forum.*
If you do this before you create your first forum post, the forum should
stay indexed automatically. If you add it later, you use action.index to
reindex the forum area. To search your forum you do this:
[(search query=index.forum text='some words')]
Of course the problem is some hits might be on the comment page, but some
work around for that could be devised I'm sure.
Anyway, just some quick thoughts...
Cheers,
Dan
On Fri, Feb 7, 2014 at 4:16 AM, mz <[email protected]> wrote:
> Fantastic, thank you!
> If time allows, maybe you can do a rough sketch about how you organized
> the forum/comments data on your page for quick retrieval and display.
> I assume that you use info indexes.
> I am looking for ideas to organize hundreds of text chunks and small data
> bites which need to be ad-hoc combined and shown in different lists.
>
> Greetings, Martin
>
>
> Am Freitag, 7. Februar 2014 03:24:28 UTC+1 schrieb Dan:
>
>> Hi Everyone!
>>
>> Just wanted to put out a quick release with some nice fixes in place. In
>> particular the new indexing and querying are working quite a bit better.
>> Also, redid some work on the register action to make the new user
>> experience a bit better. The 4.xx series is finally starting to feel not
>> just stable, but almost polished...
>>
>> From the changelog:
>>
>> * Been very busy fixing various bugs throughout the code. I haven't
>> documented everything.
>> * Quite a bit of work on the indexing system, and some changes to the
>> query system as well. Need to update the docs when I have some time.
>> * Changed slightly how forms are handled. Could affect custom scripts
>> using the KEY, COMMAND, or INPUT form session values.
>> * Fixed a padding problem on the tables in the default style sheet
>> * Worked around a php bug affecting sites with a field name that is an
>> integer (ie: 2014).
>> * Added an abort conditional so you can tell if a form command fails, ie
>> [if abort register]...[if]
>> * Added the ability to tap into command output values directly by
>> [(source command=register)]
>> * Completely reworked the register action to do a better job reporting
>> results accurately.
>> * Made time function a bit smarter so can now do [(time %x)] or [(time
>> 1234567890)], or even [(time tomorrow)], and it knows what to do. If you
>> try [(time tomorrow %x)] the time must still come before the fmt.
>>
>> Cheers,
>> Dan
>>
>> P.S. I finally have everything just about working on my main production
>> site. Once that is upgraded at long last to 4.xx, BoltWire's rate of change
>> should slow considerably. That should be sometime early next week. :)
>>
> --
> You received this message because you are subscribed to the Google Groups
> "BoltWire" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/boltwire.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/boltwire.
For more options, visit https://groups.google.com/groups/opt_out.
