Wedge
Public area => The Pub => Features => Topic started by: Nao on October 13th, 2010, 10:23 AM
-
I'm a bit at a loss here.
In Noisen.com, boards are called boards, blogs are called blogs, and sites are called sites. Yay.
A site, in my mind, is like a blog, but without the traditional blog homepage. It would be more like a portal of sorts, allowing you to sort articles manually, rather than chronologically. Internally, it represents few changes really.
However, what happens is that all of these site types are actually just boards.
In the French version of Noisen, I decided to rename "sections" (which is the unlikely French translation for "boards") into "sites". Made more sense to me, especially when offering people the ability to create their own sites. "Create your own section" is quite lackluster... And yes, that pretty much implies that all boards are "sites" by default, and only become "boards" (forums) when specifying so. It doesn't matter at all... I think it's okay. If you want to create a website, you know that forums and blogs have a special layout which you can select, but sites, OTOH, are yours to imagine.
So, should I rename 'board' to 'site' in the code, when it's generic enough, and leave it to board when it's specifically meant as a board? (Which doesn't happen a lot...)
-
Unrelated, but I'll somehow turn this into my "nice discoveries with language files" topic while editing my files...
$txt['lang_locale'] = 'fr_FR.utf8';
That's in the French version. Uh oh. What's the .utf8 for? If you google that, you'll find out that apparently some servers don't support that, etc... I don't know if it's anything specific. Maybe it's French only...
Also, note for self: added strings for the Ignore Topics feature in Admin and Help files. (That's because the feature is already implemented on Noisen. I might as well add the language strings already.)
-
...Bump? Any opinions?
Also, I've decided that I won't be updating the French version of SMF anymore...
Not only because GravuTrad is more annoying than ever. <PRV> But also because I don't see why I should maintain two French translations, one for Wedge and one for SMF. Wedge will benefit my improvements. SMF can die (kindly.)
-
Well you can do it the Wedge way...moving SMF further away by renaming some things around here. There's nothing wrong with that. Section sounds fine for me. :)
-
Well, XenForo (boo hiss) bundles boards, redirection boards, categories and pages under a single parent area called Nodes, and each of those things as we know them are types of nodes, under which you have 'Forum', 'Link Forum', 'Page' and 'Category' (yes, the vB mentality strikes again :P)
Section is logical and means it's not necessarily tied to being a forum.
-
Post>Content
-
Well, XenForo (boo hiss) bundles boards, redirection boards, categories and pages under a single parent area called Nodes,
Might as well call them "items", then...and each of those things as we know them are types of nodes, under which you have 'Forum', 'Link Forum', 'Page' and 'Category' (yes, the vB mentality strikes again :P)
Section is logical and means it's not necessarily tied to being a forum.
What I meant is that Section is the word used in the French translation to stand for "Board". I find it silly, especially as the word "Section" is also used to represent "areas" in that translation... Uh.
I never liked "Sections", which is why I first started to use "Site" long ago. Of course, people may confuse a "site" with the "forum" it's hosted on. It lacks logic but as long as Wedge is a forum system, it's still a "forum site".
Anyway!
-
vB mentality? In what way?
Hmm, we almost need a new word.
Wedges! Call 'em wedges!
-
Ah ah!
Spaces? Places? And, again: Sites?
So in vB, Board > Forum? Strange indeed...
-
In vB, yup. To be fair, I think that's how UBB did it first, that the entire place was the bulletin board, and each forum was an area within it.
Spaces? Places? And, again: Sites?
-
Potato wedges :P
Who cares if that's food! haha
-
A funny thing...
A place, in French, can among others be translated as "un coin". Litterally a corner, like a speaker's corner.
A wedge, in French, is translated either as "une cale" or... "un coin". Homonyms FTW! In both cases I would translate the name to coin :P
-
Up
So, what do I use then...?
- Main website: Forum, all right?
- Below that, Categories (that one is fine...)
- Below that: Boards, or Wedges, or Places, or Spaces, or Corners?
Which are of either type:
- Blogs (that one's a given)
- Sites? Or Webzines? Or Magazines? Or "Custom"?
- Boards or Sub-forums or Topics or Agora or Piazza or something else?
-
Main site = forum works for me
Categories also works for me
The rest, it gets complicated.
I initially said 'wedges' more as a joke but in all seriousness, let's run with that a moment.
You create a new wedge, of type 'forum board', 'blog' or whatever. Pitch it to the user as dividing up the site into parts. A forum wedge (board), blog wedge (blog board), a link wedge (redirect board), or a content wedge (custom page; I like the idea of free format user pages somewhere in there)
-
The rest, it gets complicated.
I initially said 'wedges' more as a joke but in all seriousness, let's run with that a moment.
You create a new wedge, of type 'forum board', 'blog' or whatever. Pitch it to the user as dividing up the site into parts. A forum wedge (board), blog wedge (blog board), a link wedge (redirect board), or a content wedge (custom page; I like the idea of free format user pages somewhere in there)
And yes, use a 'wedge' as in 'a triangular section of a pie' is cool in that respect... But OTOH, it pretty much forces me to translate it to 'Section' in French, which is exactly what is being said right now :^^;:
Calling for other members to give their opinions on our many suggestions!
-
Today I realized that if we're talking about wedges as part of a greater ensemble, it means they're like "orange wedges", not "simple machine wedges".
Meaning, the French translation would be the same as for the orange -- a "tranche" (slice), or "quartier d'orange".
I like "quartier" because it ALSO means a "place" -- i.e. "quartier général"/"headquarters".
It can also mean a "neighborhood" or "area". Nice for a social network oriented website.
-
Bumping this while I play with the blog board stuff.
Boards can be defined in the table as blog/forum/site but looking back on this I have no idea what a 'site' board is meant to be... is it a redirect board?
-
Nah, it's... Well, the equivalent to a portal page?
Sites aren't implemented in Noisen so that's why it's confusing.
They were always intended as this: basically, same as a blog, but the index is different. Instead of having a list of blog posts, you have a more complex page that is built by the author, either through HTML in an editor (is it wise?), or through 'blocks' that they place wherever they want. For instance, set a blog post to be a headline or introduction, show a list of the 5 most popular posts or 5 most recent, or a random selection of them, either in blog index format or just the link or something, and most importantly, actual text contents that should be used to 'link' the blocks between them. I had envisioned actually setting up a hidden topic for each 'site', where only the first post would be used, and would represent the main page, with the user being able to use various new bbc tags to show the list of post -- things like [posts type=blog limit=5 sort=random]... See what I mean?
'course I never implemented any of that.
-
Portal pages are managed entirely separately, and don't hijack the boards table for anything; often they have 'page=xyz' in the URL.
I do see what you mean *nods* but that's heading towards article territory, which isn't a bad thing at all. Just that really we're talking about reusing topics rather than boards for that ultimately (it's a use for floating topics rather than boards, IMHO)
-
Portal pages are managed entirely separately, and don't hijack the boards table for anything; often they have 'page=xyz' in the URL.
I mean, I always keep the search engine in mind when I add content. To me, the messages table is sacred -- WordPress doesn't allow searching on blog posts, comments and pages at the same time... That's one advantage it won't get anytime soon :PI do see what you mean *nods* but that's heading towards article territory, which isn't a bad thing at all.
Well, now I want DeiDeo to be my next (and first) site-type thingy. (Y'know, that website I've been thinking of for a couple of years, where I'll post fun/interesting plagiarism examples in the geek culture.)Just that really we're talking about reusing topics rather than boards for that ultimately (it's a use for floating topics rather than boards, IMHO)
-
WordPress doesn't allow searching on blog posts, comments and pages at the same time... That's one advantage it won't get anytime soon
Yeah, but that's not how we're going to do things... Isn't it?
Technically, I wanted FoxProg to be a site-type thing.
Well, now I want DeiDeo to be my next (and first) site-type thingy. (Y'know, that website I've been thinking of for a couple of years, where I'll post fun/interesting plagiarism examples in the geek culture.)
-
Asking for opinions. (Hey, this topic references floating topics... Hush hush :P)
-
Forum/Community
Category/Zone
Board/Place/Space
- Blog
- Site/domain
- Sub-forum/room/corner
Meh, just randomness that comes to mind
-
Wedge as in forum, etc. Slice as in wedge part? Possibly also peice. So wedge, slice, peice?
-
Grr... learn to spell! Remember the old rule, I before E except after C
-
Remember the old rule, I before E except after C
-
Pichu, Pikachu, Raichu.
-
Remember the old rule, I before E except after C
Unless my movie-watching days were useless, the entire "ei" is pronounced like the French "a", as opposed to the English one.
-
That doesn't work for "height" :niark:
-
Meh englizh suxkz :P
-
Not as much as French grammar! (Or Japanese, for that matter...)
-
French is nothing compare to japanese or RTL languages.
-
For instance, set a blog post to be a headline or introduction, show a list of the 5 most popular posts or 5 most recent, or a random selection of them, either in blog index format or just the link or something, and most importantly, actual text contents that should be used to 'link' the blocks between them.
I am running up against this problem every time I want to do a little customization on a portal page block. I like to keep using already-working code like ssi_recentPosts, when possible, but if I use $modsettings['disable_tags'], then what gets disabled stays disabled for the rest of the page. I cannot re-enable them when the block has finished its work.
Have you made any changes to parse_bbc to make it possible to disable, and then re-enable tags?
-
You know you can do that in SMF already, right?
Last parameter to parse_bbc is an array of tags that should be considered for that parse only.
-
Yeah, but if I want to call existing code (like ssi_recentPosts), I can't get to the parse_bbc call.
-
You'd have the same situation in Wedge, and for the same reason. You can't do it without editing the calling code.
-
Solving parse_bbc problems is a bear.
So -- add some parameters in SSI.php to either do what I want it to do or tell it I'll parse my own bbc.
-
Either way you still have the fundamentally same problem to solve ;)
It's something I've put a little thought into, but not a lot because it's really something that really wouldn't normally be needed to be changed.
-
If you ever start to want a very content-rich portal page, with several blocks doing different things, you might see parse_bbc differently.
Or you might not get hung up on the same things that us less-experienced coders break our teeth on.
-
Well, if you're going down the road of building your own blocks, you're invariably not using SSI's inbuilt functions anyway so you have direct access to the parse_bbc call... so I guess I'm still not seeing the need right now...
-
I'd rather string together existing code than write a bunch of new code, just to do a conceptually simple customization of a SimplePortal block that now uses ssi_recentPosts because that did what the designers wanted it to do.
Thanks for letting me know where you stand vis-a-vis parse_bbc. I hates it -- parse_bbc.
-
Unfortunately what is 'conceptually simple' usually isn't in practicality.
IOW, parse_bbc can already do exactly what you want, out of the box, in SMF 2 and has done for a long time. What you're asking for isn't a change to parse_bbc, but a change of how the SSI functions work, which is a totally different concept.
-
I understand what you are saying. I just think differently than you do.
Probably because you have more and better coding experience.
-
When it comes to giving the ability to build custom pages, I'm trying to think of something that's not done in the WP3 fashion (i.e. letting admins create "MyCustomThing.custom-page-suffix.php"), mainly because of the MVC conflicts, but it's hard really. Why am I talking about that anyway?
parse_bbc() is, it's well known, the most cpu-intensive function in SMF/Wedge. There's not much we can do about it (apart from micro-optimizing, which isn't easy at all here). I tend to avoid SSI functions because they usually don't do things in the most optimal way for me -- namely, if they parse tags for a field I'm never going to show anyway, it isn't cool. But there isn't any solution ready for use right now. Maybe portal authors could share their thoughts about this...
But all in all, it's not something I feel I'm ready to tackle right now. My priority is on integrating the Media area anyway.
-
bbc versioning.
I am given to understand, from some of [Unknown]'s posts, that a significant part of the complexity/resource-hogginess of parse_bbc is to support "backwards compatibility". I can't quite follow how parse_bbc picks the correct version of a given tag. And I don't know what all other stuff is in there for "backwards compatibility"
Declare all "old" posts to belong to "old parse_bbc" and let "old parse_bbc" parse them.
Force new posts to conform to "new bbc" usage, and use a "new parse_bbc" to parse them.
As the old posts recede into history, "old parse_bbc" will be called less and less often.
And "new parse_bbc" will be called more and more often, for a modest performance improvement.
Portal and AJAX chatbox authors have already found that drastically reducing the size of parse_tags can yield very large performance improvements.
-
It sort of is, but it's also a drastic oversimplification.
Let me go back to YaBBSE / SMF 1.0 for a moment. parse_bbc was a very different beast then, and it was based on regular expressions, which under some conditions could be an order of magnitude faster than the current incarnation.
At the same time, it's also possible to brutally hurt the server with specifically crafted posts that force the regular expression to be parsed the slowest possible way, which under the right conditions would be easily an order of magnitude slower than the current parse_bbc processing.
That's why Unknown gutted it and rewrote it for 1.1. (Maybe it was for 1.0 replacing YaBBSE's. I can't remember, but certainly at some point prior to 1.1 final it was moved from regexp based to the current incarnation.)
parse_bbc now is slow. But you can't tie it in knots and generate pathological-case processing; it won't run into log time most of the time, and even with the worst case it won't typically be worse than linear time.
So, with that in mind, consider then that you can throw anything at parse_bbc and it should work as intended.
Doing something with it structurally is something I've been pondering for a while, and I keep coming back to this sticking point of its style of regurgitation - it doesn't ever take the content and filter crap out, it starts from sanitised content and specifically enables it. There's no good way I can see of approaching that without compromising security somewhere, and so it becomes a judgement call as to how far is 'far enough'.
-
Darn. Sound like I'll be hating parse_bbc for a long time, then.
-
Unfortunately, yes, for now.
I do have some ideas on it, though - one of Karl's ideas was to be able to provide a 'scope' for the purposes of processing, and that could be used to indicate the type of parsing to do, which might be useful to implement sometime...
-
Thanks for trying all these ideas out, Nao and Arantor. Maybe the entire SMF community can profit from what you learn.
-
Re: parse_bbc performance.
- Maybe we should use the opportunity of a full import to do some sanitizing work on posts that weren't sanitized in the first place (e.g. posed through a non-complying mod, things like that.) That way, we could remove some of the legacy code from parse_bbc. Hopefully.
- For those who aren't in the private area and can't follow my little adventures... One of the features I added was a complex block replacement system that supports optional params. I'd crafted this beautiful regular expression that worked great. Then it crashed a few pages, so I rewrote it for performance (with inspiration from my 'goddess of all regex' and that really odd atomic grouping thing). It became extremely reactive and I couldn't get to crash it anywhere. Was satisfied with it. Only, I wasn't sure it wouldn't crash anywhere else (although my experience with the 'goddess' tends to confirm that it wouldn't...), and I was curious about something: performance of a complex but very optimized regex, against the use of pure non-regex PHP. So I started working on a small function that would do the same work as the regex.
Quite surprisingly, it only took me 20 minutes to get it working, it only took a few lines of code, and it was fucking fast. The final version is about 10% faster than the regex version, and the more blocks you replace, the faster it gets -- once you reach 300 blocks, it becomes a strain on Wedge in the regex version while the pure PHP version still keeps flying (about 5 times faster.)
This is only mean to explain that I used to think regexes were the ultimate solution for complex performance-aware searches/replacements. I'm not so sure about that anymore. Actually, I'm starting to wonder if I'm not going to turn this pure PHP version into a regular multi-purpose function with associated callbacks, that will happily handle any kinds of tags, be it HTML, BBC or Wedge block tags (<we:block>). Maybe then, we can start doing tests in parse_bbc and see if it can be done faster.
One of the things we should sanitize in posts is tag cases. I mean, I don't see why we should accept [Html] tags when it should be 'html', in lowercase. Case insensitivity is one of the things that regular expressions are great at, as Pete can confirm. My pure PHP version is case sensitive. Had I added support for case insensitivity (and I did at some point), it would have been twice slower. Which is okay when you have 300 blocks to deal with (it's still 2.5x faster than the regex version), but it becomes 80% slower than the regex version when using only a dozen blocks.
So... These are a few of the solutions I could offer to try.