The future of FluxBB

Frank H · 2009-01-28 17:23:12

briann wrote:

oh, i forgot to ask.
[if it has already been asked or stated, sorry, but i don't intend to read pages full of long posts just to find a simple answer]
can i convert from 1.3 to 1.4?
P:

Try reading the first post at least

Line 6: "There will be the option to upgrade from versions 1.2 and 1.3 to 1.4"

Anatoly · 2009-01-30 08:37:03

Smartys wrote:

I don't think 2.0 is going to be finished in several years: I would be surprised if it took more than one year to write. I think once 1.4 is tested and released, planning for 2.0 can start in earnest. I think there are more people "on the team" working to plan and develop the software than ever before. I think having a clear roadmap beforehand will lead to better written software that is finished more quickly.

Smartys wrote:

It is a release [1.4] meant to fill a void that formed when all the development efforts focused around 1.3, while 1.2 was left neglected for no good reason.

Agree.
Smarty's 1.4 is a necessary step after 1.2 before the development process may go further in a right way.

qie · 2009-01-30 08:39:35

Anatoly would you plz check my topic? I'm sorry off topic.

Last edited by qie (2009-01-30 09:17:42)

Anatoly · 2009-01-30 08:44:24

qie wrote:

Anatoly would you plz

Stay on topic, please.
You are welcome to write to anatoly@punbb.org looking for my personal support.

paulrobert_a · 2009-02-01 10:14:37

Probably a stupid suggestion, but why don't you just rename 1.3 to 2.0 alpha 0 or 1?

Lu · 2009-02-01 12:32:26

paulrobert_a wrote:

Probably a stupid suggestion, but why don't you just rename 1.3 to 2.0 alpha 0 or 1?

Because (as I understand it) some things, most importantly the extension system, would be completely re-written.

qie · 2009-02-01 12:34:14

paulrobert_a wrote:

Probably a stupid suggestion, but why don't you just rename 1.3 to 2.0 alpha 0 or 1?

rename anyhow,but as now it seems the develop team have not got a clear outline for Fluxbb 2.0

Connor · 2009-02-03 15:04:14

paulrobert_a wrote:

Probably a stupid suggestion, but why don't you just rename 1.3 to 2.0 alpha 0 or 1?

Because 2.0 will not be simply a continuation of the 1.3 development.

SuperMAG · 2009-02-03 15:09:12

Connor wrote:

paulrobert_a wrote:
Probably a stupid suggestion, but why don't you just rename 1.3 to 2.0 alpha 0 or 1?
Because 2.0 will not be simply a continuation of the 1.3 development.

how's that. i thought you people will tweak 1.3.
or are you people planning to start from beginning.

elbekko · 2009-02-03 15:11:17

Yes, 2.0 will be started from scratch. But that's all the detail we have about it for now.

Pedro · 2009-02-03 22:56:16

elbekko wrote:

Yes, 2.0 will be started from scratch. But that's all the detail we have about it for now.

I can't find the quote now, but one of you guys said somewhere in one of these discussions about fluxbb 2.0 that it use most of the code base and the extension system would be changed at the most.

In that case, I am afraid I will also abandon this ship I'm already finding out solutions/alternatives for what I wanted to do with punbb 1.3.

I still maintain my opinion that 1.3 is too valuable to simply be trashed and that this recent focus on 1.2 (whatever you want to call it) is a too old fashioned way of looking at things, making fluxbb give a turn in its philosophy and becoming more like other forums. I am talking about a stiff code base in which modifications are wiped out through upgrades, that should be a thing of the past IMO.

You guys have been very helpful and determined all the time, I have zero to complain about (I wouldn't have the authority either), I guess this is just the point where fluxbb follows a path which is incompatible with my needs as a user. That's all.

I'll hang on a bit in these forums and follow some activity at SVN, just out of pure curiosity, just for a while, don't know for how long.
Good luck. Maybe in the futures I'll find 2.0 useful.

The only recommendation I make is to make something about the userbase size, its going down to very dangerous levels. I think it's important, even if only for motivation purposes.

elbekko · 2009-02-04 00:26:29

2.0 will go back to being extensible, the 1.3 approach just wasn't very viable, and be glad we saw that now (during development) and not when alot of people were using it in production and whining about it here.
And 1.3 is still available, with the major issues fixed.

Rich Pedley · 2009-02-04 10:19:12

One thing that is certain about 2.0 is that all current extension for 1.3 will not work with it.

Pedro · 2009-02-04 22:35:03

elbekko wrote:

2.0 will go back to being extensible, the 1.3 approach just wasn't very viable, and be glad we saw that now (during development) and not when alot of people were using it in production and whining about it here.
And 1.3 is still available, with the major issues fixed.

I think i might have asked this before but I am not sure I got an answer. What were the major issues with the extension system that made it not so viable? Which alternatives are there and how are they more viable?

Not being ironic nor sarcastic, just a bit surprised.

elbekko · 2009-02-04 23:26:32

The extension system just wasn't meant to do what the community now expects from it. It was meant to provide simple extra functionality (like a custom announcement box, adding extra permissions to certain forums, ...), not replace whole page blocks (like with polls).
Right now we're still looking into alternatives, and we're sure as hell open to suggestions

Paul · 2009-02-05 01:34:35

In theory what would work is taking the blocks of html which actually hold content as opposed to structural markup and generating them with a function or class. For example you would have a function which creates form fields. You first create an array which holds the information about each field e.g. whether its a test or select, langauge file entry for the label etc. You then loop through the array calling the field creator function which creates the markup for each form field. That means all the extension would have to do is add an item to the array. The form field and its markup would be automatically generated by the creator function. If the extension wants to remove functionality from a form it can simply remove the array element or elements which creates the fields that provide that functionality.

Where it gets more complicated is when you don't want to simply add fields to an existing form but rather you want to create a whole new form. In that case you would need stock templates for all the different board elements. The extension would then include the template at the appropriate point in the page.

In simple terms, the extension would first create the skeleton of a form from a template and then tell the foreach loop in the form what array to use to create the fields.

The end result is that extensions don't have to concern themselves with markup at all. It also solves the problem with css since all standard markup items will be catered for in the existing stylesheets. It does however mean that all the markup has to not only be modular but totally consistent. It won't be possible to style one form differently from another just because it looks better. It should however be possible to skin the forum because there is no reason why at least the templates for the structural skeletons couldn't be style specific.

The whole trick is to look at markup as falling into two groups. The first group being the inner markup such as form fields, lists of data, menu lists etc. The second group being structual markup which basically provides a skeleton for a page or part of a page.

What I have no idea about is what the performance hit is for a system like that.

P.S. Thats just my ill thought out musings, not a statement of how its going to be.

Pedro · 2009-02-05 08:57:57

elbekko wrote:

The extension system just wasn't meant to do what the community now expects from it. It was meant to provide simple extra functionality (like a custom announcement box, adding extra permissions to certain forums, ...), not replace whole page blocks (like with polls).
Right now we're still looking into alternatives, and we're sure as hell open to suggestions

There's so much you guys can do about that besides moving ALL the HTML to templates. Those who still want to jam a whole page into a hook will always be able to do it. It can be considered bad a bad practice or not recommended for most of the situations, that's all... I guess.

I can't think of a simpler way to replace hooks' power that is simpler than hooks. It's becoming a current practice more and more in web based applications.

So, after your call for suggestions, this is the question that poped up in my mind:
Would the problem be solved if the extension developers would have the possibility to create or change templates? I mean, those entire page blocks would be moved out from the 'extension core'.

In theory what would work is taking the blocks of html which actually hold content as opposed to structural markup and generating them with a function or class. For example you would have a function which creates form fields. You first create an array which holds the information about each field e.g. whether its a test or select, langauge file entry for the label etc. You then loop through the array calling the field creator function which creates the markup for each form field. That means all the extension would have to do is add an item to the array. The form field and its markup would be automatically generated by the creator function. If the extension wants to remove functionality from a form it can simply remove the array element or elements which creates the fields that provide that functionality.

That already exists and is used in a quite large extent by most of the web frameworks out there. It's usually called an 'HTML helper' or 'HTML class'... or something similar. It also allows insertions of extra HTML attributes, which can be very practical in an extensible software.

What I have no idea about is what the performance hit is for a system like that.

Not me either to be honest.
More and heavier templates will for sure have its performance price, the same for large amounts of hooked code. But if I should give my opinion in here I would say that giving hand of those would be putting a speed/performance obsession in front of the natural needs of the average user.
With great power comes great responsibility ( just kidding )
I do mean it in some extent though, in the sense that the extension developer will always be able to make extensions that affect performance in a serious way.

My belief is that if you don't abuse of database access and don't ship monster HTML pages with the default punbb package you can still call it very lightweight.

Rich Pedley · 2009-02-05 09:32:47

I'm almost certainly going to be in the minority but...

I hate form builders - really really hate them. I've had to remove form builder from places in the past because of poor usage and implementation. However, I have also used some very good ones - but usually they don't try and do everything.

Be wary of too many templates, phpBB went that way...

Last edited by Rich Pedley (2009-02-05 09:33:13)

markc · 2009-02-05 13:37:16

I hope this is the right place and you guys don't mind some misc thoughts. I've been hacking on PunBB for a few weeks to reduce it down to a core that could be embedded within another web application. I just discovered FluxBB and notice the 1.2.12 tarball is about 2/3s the size of punBB 1.3.2 and indeed viewforum.php and viewtopic.php are delightfully free of get_hook().

My main approach to modifying any PHP app is to encapsulate all code in functions that return strings instead of in place echo statements that then require ob_start() to control. I just use $buf .= 'string' instead of echo's, then return $buf at the end of a function, then append that returned data to some global-like variable that finally gets echo'd once... in other words, I aim towards having a single echo statement for the whole application and never use the '<?php echo $somevar ?>' method.

Another key point is that I get all links to go through index.php as a "front controller" so that instead of going to "viewtopic.php?id=1" I make links like "?m=topic&id=1" and then include viewtopic.php from index.php instead of going to viewtopic.php directly. In the case of punBB I moved it's index.php to viewindex.php and created a new and simpler index.php controller. This approach enables multihosting off a singlecode base because all the code (once converted to this format) can be put in an off-web include dir and only index.php, config.php, the cache dir and css/js/img need to be in the on-web area. Then 100's or even 1000's of vhost sites can be run off the same core code but with their own database and style. Any future bugfixes and enhanced features only need to be applied to the single core codebase for all instances to take advantage of.

The next thing I aim for is just like Paul was outlining above, I gather all data first (from SQL or cache) and hold the data in arrays then call html_functions($ary) that have no logic other than to interpolate the incoming array strings into the mostly html string that then gets returned. This sets it up so the codebase can be separated into a quasi-MVC pattern without all the OOP craziness. Having a single front controller alone provides a lot of flexibility... add separated "model" and "view" functions seriously aids anyone hacking on the code to the point that "hooks" are not really needed because the codebase is so simple and natural that anyone can add what they want directly to the codebase instead of relying of some bizarre hook system. Ultra simple paraphrased example...

$gbuf = '';
$data = array('MyBBS', 'lib/css/my.css');
$gbuf .= include 'view'.$_GET['m'].'.php';
$gbuf .= '<p>Copyright 2009 Blah</p>';
echo html_page($gbuf, $data);

function html_page($g, $d)
{
  return '<html>
  <head>
    <title>'.$d[0].'</title>
    <link type="text/css" href="'.$d[1].'" />
  </head>
  <body>
    <h1>'.$d[0].'</h1>'.$g.'
  </body>
</html>
';
}

Vasco · 2009-02-05 22:40:54

Good luck~ Can't wait for 1.4 and 2.0! I'll might try and help FluxBB in it's development. If I only had more free time...

briann · 2009-02-06 04:46:50

okay, with 1.4 and 2.0 coming out, which one will be the better one?

i mean, if 2.0 will still allow modifications, that means it will be way more flexible [modifications wise] than 1.4, right?

so what is the point of 1.4?
why not just keep working on a better 1.2 [which i believe you guys are already] and stick with that.

to me, i think 1.4 will be useless, unless, what, it's going to be some awesome ass forum without mods?

Meow · 2009-02-06 05:06:49

1.4 is almost done.

ScottyDoo · 2009-02-06 07:08:09

briann wrote:

why not just keep working on a better 1.2 [which i believe you guys are already] and stick with that.

That's exactly what 1.4 is. So they are already doing what your suggesting.

qie · 2009-02-06 13:47:47

Meow wrote:

1.4 is almost done.

really ...wula~~~ I like 1.4 I got my forum prepared for it

Pedro · 2009-02-06 21:27:34

Markc, an MVC design doesn't have to make use of an object oriented approach.
What you are doing is quickly throwing down you template system and in fact separate the view from the rest. Break the reast into data access logic and 'core logic' and there you go, your application follows the MVC design pattern.

Now, that is cool. But what I am most worried about is that ATM there is no solution on the table to make fluxbb fully extensible other than going and hack the source code manually. The code might be very simple and easy to follow, but have you thought about the fact that you need to do it every single time you update the core?
Come on... am I the only one that thinks a fully extensible core is a must have?

elbekko wrote:

The extension system just wasn't meant to do what the community now expects from it. It was meant to provide simple extra functionality (like a custom announcement box, adding extra permissions to certain forums, ...), not replace whole page blocks (like with polls).
Right now we're still looking into alternatives, and we're sure as hell open to suggestions

You mean, hooks in general are not the way to go, or is it necessary something in addition to hooks?
Hooks are becoming quite common in other projects out there.
Would a flexible template system help in here, in the way that would leave big HTML bloks away from the hooks?

I guess another option would be a full OOP approach where an entry point before the load of any class would allow extension developers to override (or extend) any class before any object is loaded.
Of course, this requires a ground up rewrite and a new architecture.

(sorry, that was some broken english)

Forums

#101 2009-01-28 17:23:12

Re: The future of FluxBB

#102 2009-01-30 08:37:03

Re: The future of FluxBB

#103 2009-01-30 08:39:35

Re: The future of FluxBB

#104 2009-01-30 08:44:24

Re: The future of FluxBB

#105 2009-02-01 10:14:37

Re: The future of FluxBB

#106 2009-02-01 12:32:26

Re: The future of FluxBB

#107 2009-02-01 12:34:14

Re: The future of FluxBB

#108 2009-02-03 15:04:14

Re: The future of FluxBB

#109 2009-02-03 15:09:12

Re: The future of FluxBB

#110 2009-02-03 15:11:17

Re: The future of FluxBB

#111 2009-02-03 22:56:16

Re: The future of FluxBB

#112 2009-02-04 00:26:29

Re: The future of FluxBB

#113 2009-02-04 10:19:12

Re: The future of FluxBB

#114 2009-02-04 22:35:03

Re: The future of FluxBB

#115 2009-02-04 23:26:32

Re: The future of FluxBB

#116 2009-02-05 01:34:35

Re: The future of FluxBB

#117 2009-02-05 08:57:57

Re: The future of FluxBB

#118 2009-02-05 09:32:47

Re: The future of FluxBB

#119 2009-02-05 13:37:16

Re: The future of FluxBB

#120 2009-02-05 22:40:54

Re: The future of FluxBB

#121 2009-02-06 04:46:50

Re: The future of FluxBB

#122 2009-02-06 05:06:49

Re: The future of FluxBB

#123 2009-02-06 07:08:09

Re: The future of FluxBB

#124 2009-02-06 13:47:47

Re: The future of FluxBB

#125 2009-02-06 21:27:34

Re: The future of FluxBB

Board footer