Skip to main content
Topic: [ADDON] Tabular Categories (Read 4361 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

[ADDON] Tabular Categories

Inspired by a recent mod request (the usual annoying one :P) and by Yoshi's mod, I decided to give a try to the new layers I was working on.
And here it is: just a very simple mod that changes a bit the front page creating a "tabbed" interface with categories as tabs.

Let's say it's just something funny to demonstrate how easy it is to change the interface playing only with layers.

Tabular Categories v0.1.0

License
o This ElkArte Addon is subject to the terms of the BSD "3-clause" license. You can obtain a copy of the License at http://opensource.org/licenses/BSD-3-Clause

Features

  • You can select to show the tabs either above the categories or on one side.

Repository / Download



Change log

  • 0.0.1 - Initial release
  • 0.0.2 - Removed some logs left in place
  • 0.1.0 - Toggle of tabbed interface top/side
  • 0.1.1 - Fix of admin settings integration
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #1
Pics or it didn't happen :P

Re: [MOD] Tabular Categories

Reply #2



 emanuele was in a hurry (food was calling O:-))
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #3
Slick, very slick.

FWIW I've been thinking about this too, but not as discrete tabs like that, instead putting them directly on the main menu (and having the boards as part of the dropdown) but that's really complicated in terms of the crazy menu editor stuff I've been doing (representing a hierarchy in a table is hard work)

Re: [MOD] Tabular Categories

Reply #4
The theme reacts quite well, even with enough categories to create a second line it still looks good.
Ant did a very good job! :D
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #5
Nice :)

 TestMonkey notes that we need to rewrite and switch the definition and namespace. There are no changes yet, but that's just as yet.
The best moment for testing your PR is right after you merge it. Can't miss with that one.

Re: [MOD] Tabular Categories

Reply #6
Nice one, would be cool as a core feature (with an option  to enable and disable)  :D
Regarding the styling of the "category tabs": http://twitter.github.io/bootstrap/components.html#navs
I personally prefer "tabs" instead of "buttons" but that's just cosmetics ..
Thorsten "TE" Eurich
------------------------

Re: [MOD] Tabular Categories

Reply #7
Nice one, would be cool as a core feature (with an option  to enable and disable)  :D
Naaahhh....
It's just a js/css trick, it relies too much on the theme to have a certain structure and certain set of ids and classes.
I wouldn't have it as a core feature. At least not as it is.

Regarding the styling of the "category tabs": http://twitter.github.io/bootstrap/components.html#navs
I personally prefer "tabs" instead of "buttons" but that's just cosmetics ..
I'm not good with styling, I just copied the first thing was at hand. :P (And you may also notice the tables are missing some borders. ;))
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #8
(And you may also notice the tables are missing some borders. ;))
uups, bug in the theme? haven't noticed yet, which browser are you using?
Thorsten "TE" Eurich
------------------------

Re: [MOD] Tabular Categories

Reply #9
Nope, not a bug.
It's the way the tables are designed, the tr:first-child has:
Code: [Select]
border-top: medium none currentColor;
that ends up in a sort of no border.
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #10
Is a cool idea for a mod. You could add text-overflow to the css to stop long category names making huge tabs. That would make things a bit neater.
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: [MOD] Tabular Categories

Reply #11
Cool idea yes, but it kind defeat the purpose of having a theme in the first place. If the Boardindex.template of a theme doesn't show it as tabs, but a mod or a built-in function will - why have a Boardindex.template in the first place?

One thing is to inject template code from mods into layers - which the theme can't know about - , but taking over basically what the theme should do, is quite another. Not to mention bewildering..where do i go to change the appearance of how those tabs are laid out or even the position? Do I go to the theme..? No, to the source code then? But I should not change source code should i?..

And if the template code IS in the theme(better then) then its basically "doing it in the theme" anyway then, isn't it? You just set a core setting instead of a theme setting.

Re: [MOD] Tabular Categories

Reply #12
You'd approach it the same way the menu is handled: the tabs and their existence and *function* is dictated by the core but the presentation can be handled by the theme. Not seeing a problem here.

Re: [MOD] Tabular Categories

Reply #13
Please let's not start religious wars between "source" and "theme", I had my fair amount with Ant. :P

Let's have a quick look at the "source" file of the mod (at least a version without useless things that I forgot to remove :P):
Code: [Select]
<?php

function tabular_categories()
{
loadTemplate('TabularCategories');
Template_Layers::getInstance()->addEnd('tabular_categories');

loadCSSFile('TabularCategories.css');
}

So it simply:
* load the template
* inject the layer
* load the css file (why here? Because the "source" takes care to aggregate and minify it if needed)

This is exactly what the source should do, nothing more, nothing less. It instruct the template what to to.
And is no different from any other Elk file.
It doesn't do any check because the mod is simple and want to be just like that without multiple checks on admin and/or use settings (let's remember this is just a demo to show how to use a new function, not a fully fledged mod with options all over the place).

Then the template file:
Code: [Select]
<?php

function template_tabular_categories_above()
{
global $context, $scripturl;

$current_cat = current($context['categories']);
addInlineJavascript('
$(document).ready(function () {
var current_cat = ' . $current_cat['id'] . ';
if (window.location.hash)
current_cat = window.location.hash.substring(2);

$("#boardindex_table .header").hide();
$("#boardindex_table .divider").hide();
$("#boardindex_table .content").hide();
$("#category_" + current_cat + "_boards").fadeIn();
$("#tabcat_" + current_cat + "").addClass("active");

$("#tabular_cats li").click(function () {
$("#tabular_cats li").removeClass("active");
var id_cat = $(this).attr("id").split("_")[1];
$("#boardindex_table .content").hide();
$("#category_" + id_cat + "_boards").fadeIn();
$(this).addClass("active");
return false;
});
});', true);

echo '
<div id="tabular_cats" class="cat_bar">
<h3 class="catbg">
<ul>';
foreach ($context['categories'] as $category)
echo '
<li id="tabcat_', $category['id'], '"><a href="', $scripturl, '#c', $category['id'], '">', $category['name'], '</a></li>';
echo '
</ul>
</h3>
</div>';
}

It outputs the markup and the javascript needed. Nothing more, nothing less.
During a first approximation I put the javascript code in the subs file, but then I realised different themes may use different ids or classes, so I decided to move it to the theme and still take advantage of the addInlineJavascript function (that if needed will aggregate and minify the code if I remember correctly, but that anyway is always cleaner to use because with the second parameter set to "true" the code will be added at the end of the page all in one big chunk).

Cool idea yes, but it kind defeat the purpose of having a theme in the first place. If the Boardindex.template of a theme doesn't show it as tabs, but a mod or a built-in function will - why have a Boardindex.template in the first place?
No, it doesn't defeat at all the purpose of having a theme because the template can be changed for each and every theme installed and customised the way you want (including markup, javascript and css).

One thing is to inject template code from mods into layers - which the theme can't know about - , but taking over basically what the theme should do, is quite another. Not to mention bewildering..where do i go to change the appearance of how those tabs are laid out or even the position? Do I go to the theme..? No, to the source code then? But I should not change source code should i?..
You perfectly know that the difference between "theme" and "source" has always been a tiny line in Elk/SMF. I'm not saying this is the perfect final solution, I'm saying this is *a* possible improvement in comparison with the previous situation.

Now, debate if show the board index as tabs or as a list is a matter of the "theme" or of the "source" is totally academic. We all know that if a user wants tabs, he will not care if the theme has been designed to use tabs or not, he wants them no matter what.
Obviously if we introduce the thing as a core feature most likely all the themes will support the dual option without having to argue if it is good or bad, so this argument is sort of useless, sorry.

Additionally, since the mod uses a template function to style the tabs, what you need to do, is just to add your own TabularCategories.template.php file and a dummy function inside it:
Code: [Select]
function template_tabular_categories_above()
{
// This theme is *not* designed to use tabular categories, do *not* edit this function without my (the author) written permission and the sacrifice of a virgin.
}
just to stay on the safe side, the function is not even necessary.

And if the template code IS in the theme(better then) then its basically "doing it in the theme" anyway then, isn't it? You just set a core setting instead of a theme setting.
???

Obviously the "theming" is done in the theme.
And the "decision" to show something or not is done elsewhere.

If you think about it, this is not very different from what you have now, the only actual difference is that this approach is just another step to have a better separation between the "core" and the "addons" (with all the advantages this will bring, like easier upgrades, less troubles during installation of mods, mods will work out-of-the-box on themes installed *after* the mod has been installed and so on).
Bugs creator.
Features destroyer.
Template killer.

Re: [MOD] Tabular Categories

Reply #14
Well, for anyone making themes it will not spur them to create anything that changes more than index.template, since those edits or replacements won't matter anyway if the user wants things changed by mods. Isn't that what you are saying? The decision to use this subtemplate instead of that isn't done by the theme/theme setting..but by the source and the admin. So why should I bother making themes that cater for perhaps multiple "versions" of Boardindex.template? You might build in tabbed categories,then 2 mods come along that makes something different again...it would be pointless to rely on any other things than what the default theme offers.

It seems it won't be much different than SMF now, with hardly anything else than color variations of default theme. You see, my "war" isn't about mods and themes as such, but more about letting themes be what they can be. As long as boundaries are set like this, they never can be....I am *overly* dramatic here, I know, :D but think about it - as a theme creator, why would you try to play catch-all in this?