Skip to main content ↑ ↓
Topic: [ADDON] Articles (Read 18232 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

[ADDON] Articles

In the last couple of days I decided to start with something that should be simpler (or at least the first step) of a blog: an articles system.

What do I have at the moment?
The goal is as usual: maximum re-use.
For that reason I decided to use a board (in a category) that shouldn't appear anywhere.
Shouldn't because in fact it's not that easy, in order to remove it from most of the places I added another hook to getBoardTree, but don't know if it is something we want... no idea, really if it is good or not.
Then I also use the hook integrate_user_info to add an "AND != " in query_see_board and query_wanna_see_board. Though I have to tune that one because I would the articles to be searchable, so...still WIP.

In order to show the list of articles I user the MessageIndex controller with just minor adjustments afterwards.
I just added a sub_template because I need to change the way the list is displayed.

Same goes for Display.

One issue tough here: in order to be able to "re-map" message index and display I have two options:
1) str_replace all the urls from the buffer adding an action,
2) add a couple of hooks like these:
Code: [Select]
			// ?board=b message index
			elseif (empty($topic))
			{
				$message_index = array();
				call_integration_hook('integrate_message_index', array(&$message_index));
				$this->_file_name = isset($message_index['file']) ? $message_index['file'] : CONTROLLERDIR . '/MessageIndex.controller.php';
				$this->_controller_name = isset($message_index['controller']) ? $message_index['controller'] : 'MessageIndex_Controller';
				$this->_function_name = isset($message_index['function']) ? $message_index['function'] : 'action_messageindex';
			}
			// board=b;topic=t topic display
			else
			{
				$display = array();
				call_integration_hook('integrate_topic_display', array(&$display));
				$this->_file_name = isset($display['file']) ? $display['file'] : CONTROLLERDIR . '/Display.controller.php';
				$this->_controller_name = isset($display['controller']) ? $display['controller'] : 'Display_Controller';
				$this->_function_name = isset($display['function']) ? $display['function'] : 'action_display';
			}

...guess what? I tend to prefer the second one... O:-)

That said, I realised the hooks I added _before and _after in the dispatcher are useless...there are too many that use action_index and I'm doomed... lol
Add the controller too would fix the issue, though it would create names quite ugly. :(
Probably better remove them...

While reusing display I had to use another trick: in order to show the "article" (i.e. the first message) and x comments equivalent to the number of messages per page set for the rest of the forum, I had to increase by one the number of messages per page and then discard the first...not nice, but it was the only solution. Dunno if it is worth change Display_Controller in order to be able to by-pass that issue, but I'm not even sure how it could be by-passed...

I think I'll push the changes to the hooks soonish, for comments, then I'll go on with the rest.
Bugs creator.
Features destroyer.
Template killer.

Re: [ADDON] Articles

Reply #1 –

Suggestion: extend the boards table to include a type column, which can be used to exclude entire boards easily ;)

Re: [ADDON] Articles

Reply #2 –

That would be the easy way! :P

I'm trying to push the system as it is mostly for fun and to have an idea of how far it can be pushed without breaking badly. lol

 emanuele likes experimenting. O:-)
Bugs creator.
Features destroyer.
Template killer.

Re: [ADDON] Articles

Reply #3 –

I thought about making an article / page system a while ago... (Never started developement, just a litte bit of brainstorming)

I'd extend the topics table with a column "topic_type" in order to identify the type of content.
1 = normal -> default topic layout
2 = blog -> blog layout
3 = static page (blog layout, but marked locked,'cause I don't like comments on static pages )
..
You could load various DisplayTemplate layouts depending on the type... the boads table could additionaly be extended with a "default_topic_type" column, thus you can "force" blog topics depending on the board the topic was started in...
Thorsten "TE" Eurich
------------------------

Re: [ADDON] Articles

Reply #4 –

This is something I've worked ab it with..in my experience adding the type to topics can quickly get confusing, since blog posts AND normal posts share boards. I started with that in ViennaBBS but I opted to use rather a "boardtype" value in Protendo, so entire boards is one "type".

I did set a topics "type" too..but thats for custom actions wanting to use topics as "comments", linking them togheter that way. So far I think admin should just tend to where these "comments" topics reside, so I am not locking them to entire boards.

But for different topic types(articles, blogs even galleries for my part) work better as board-based I think.

Re: [ADDON] Articles

Reply #5 –

There are some issues with using too many boards, though, namely that {query_see_board} becomes a surprisingly large overhead if you're not careful. It's not bad on < 100 boards but it soon escalates when you start using other things as boards too.

Not to mention managing all the types of boards when you're getting into the realms of potentially allowing other users to create boards as well (without having access to the full boards management area), e.g. giving users a blog board each if they want, you need to be able to let them create it but only in the place(s) you want them in and not to be able to mess with anyone else's board(s). It's a complex task, doubly so if you want per board permissions to function for those...

Re: [ADDON] Articles

Reply #6 –

I am not looking to be a blog like that, it will be a blog only in the sense of presentation, that is, all other things are maintained as before. Full freedom for admin to set it up as they wish. If they want blog setup automatically I see that as a mod rather.

In that sense my added fields are only checked when fetching boards, and even have a switch to be ignored in boardindex if they choose. it will still follow through, so the template can make use of it and render the non-forum boards different if they like. For the custom actions fetching topics, they do it in a blog way mostly, that is: latest topics like a blogroll and only fetching the board names as "categories". It will be a large list of course, if they have many boards, so I am working to have some ways to solve the presentation of that. But the big query of boardindex is the same, minus the check of boardtype, and not at all when entering blog/gallery/etc areas.

Re: [ADDON] Articles

Reply #7 –

That's the thing, though... it's not just board index where this stuff is a problem. It's everywhere you have query_see_board which is in many places, not just the board index. It just so happens that the board index is the place you generally hit the pain first and foremost. But you hit it with any page load to any board, any topic, or any page where the URL contains either board= or topic= (e.g. action=dlattach)

The reason it's a pain point is because of what it contains, which is to say a WHERE clause consisting of b.id_board IN (1,2,3,4,5,6,7,8,9,10) for every single board you can currently see. Which means it's going to be optimised by MySQL into, effectively WHERE b.id_board = 1 OR b.id_board = 2 OR b.id_board = 3 etc. which means sequential tests on each row of the boards table that you're touching. (Which means, incidentally, the level limit clause is even MORE important on the board index than we might otherwise have thought.)

Too many boards, regardless of anything else, is a bottleneck.

Re: [ADDON] Articles

Reply #8 –

Quote from: emanuele – ...guess what? I tend to prefer the second one... O:-)
Yes, those could/should be added. It makes sense.

QuoteThat said, I realised the hooks I added _before and _after in the dispatcher are useless...there are too many that use action_index and I'm doomed... lol
Add the controller too would fix the issue, though it would create names quite ugly. :(
Probably better remove them...
I'm missing the issue here. Could you give some example of ugly names?

QuoteWhile reusing display I had to use another trick: in order to show the "article" (i.e. the first message) and x comments equivalent to the number of messages per page set for the rest of the forum, I had to increase by one the number of messages per page and then discard the first...not nice, but it was the only solution. Dunno if it is worth change Display_Controller in order to be able to by-pass that issue, but I'm not even sure how it could be by-passed...
Counter-question: does it need to have the same number of comments as the messages per page? There are as many as messages per page total, aren't they?
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: [ADDON] Articles

Reply #9 –

Quote from: TestMonkey – Yes, those could/should be added. It makes sense.
Luckily I wrote them... lol

Quote from: TestMonkey – I'm missing the issue here. Could you give some example of ugly names?
At the moment no issue, though the two hooks I added:
Code: [Select]
$hook = substr($this->_function_name, -1) == 2 ? substr($this->_function_name, 0, -1) : $this->_function_name;
call_integration_hook('integrate_' . $hook . '_before');
[...]
call_integration_hook('integrate_' . $hook . '_after');
The way they are now are not specific enough, for example they would hook for any action_index irrespective of the controller.
But, if we add the controller to the hook name, dunno, something like:
Code: [Select]
$hook = $this->_controller_name . '_' . substr($this->_function_name, -1) == 2 ? substr($this->_function_name, 0, -1) : $this->_function_name;
The resulting hooks would be very long, like:
Code: [Select]
integrate_boardindex_control_action_index_before
integrate_boardindex_control_action_index_after
etc.
They seem ugly.
 emanuele doesn't like names too long...
But if you say they are okay I'm fine with it.
Quote from: TestMonkey – Counter-question: does it need to have the same number of comments as the messages per page? There are as many as messages per page total, aren't they?
I think so...
The article is one thing, then there are the comments that should be always the same number on each page.
More tidy IMO.
Bugs creator.
Features destroyer.
Template killer.

Re: [ADDON] Articles

Reply #10 –

Ah, ok, on the last.

Quote
Quote from: TestMonkey – I'm missing the issue here. Could you give some example of ugly names?
At the moment no issue, though the two hooks I added:
Code: [Select]
$hook = substr($this->_function_name, -1) == 2 ? substr($this->_function_name, 0, -1) : $this->_function_name;
call_integration_hook('integrate_' . $hook . '_before');
[...]
call_integration_hook('integrate_' . $hook . '_after');
The way they are now are not specific enough, for example they would hook for any action_index irrespective of the controller.
But, if we add the controller to the hook name, dunno, something like:
Code: [Select]
$hook = $this->_controller_name . '_' . substr($this->_function_name, -1) == 2 ? substr($this->_function_name, 0, -1) : $this->_function_name;
The resulting hooks would be very long, like:
Code: [Select]
integrate_boardindex_control_action_index_before
integrate_boardindex_control_action_index_after
etc.
They seem ugly.
 emanuele doesn't like names too long...
But if you say they are okay I'm fine with it.

Option 1)
Strip 'integrate_' -> the [not-yet-existent] hooks class can do this and it was in the back of my mind. (the class would handle integrate_ of course, for seamless compatibility.)
[perhaps] Strip 'controller' in these two hooks -> all controllers are '_controller' and only them have action methods...

Option 2)
How about: override pre_dispatch() and use it, instead of a hook _before?
In the past and/or on some of my local repos, I've added a post_dispatch() as well. I didn't see a real need/use for Elk yet, so I left it out.
Would they be useful for the cases you see? The dispatcher would execute them, before and after any action in that controller.
The best moment for testing your PR is right after you merge it. Can't miss with that one.