<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title type="html"><![CDATA[FluxBB.org Forums - The future of FluxBB]]></title>
	<link rel="self" href="http://fluxbb.org/forums/feed/atom/topic/2384/"/>
	<updated>2009-03-04T10:13:34Z</updated>
	<generator>FluxBB</generator>
	<id>http://fluxbb.org/forums/topic/2384/the-future-of-fluxbb/</id>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/21668/#p21668"/>
			<content type="html"><![CDATA[[url=http://markosullivan.ca/blog/?p=522]Some considerations of the developer of another forum software about the development and release of a new version.[/url]

JFYI.]]></content>
			<author>
				<name><![CDATA[fmimoso]]></name>
				<uri>http://fluxbb.org/forums/user/136/</uri>
			</author>
			<updated>2009-03-04T10:13:34Z</updated>
			<id>http://fluxbb.org/forums/post/21668/#p21668</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20999/#p20999"/>
			<content type="html"><![CDATA[[quote=Pedro][quote]I spent over half a day getting sidetracked last time I used that method of having a quick dig around[/quote]
That thing you did is called 'Learning' ;)[/quote]

It usually isn't anything one could call learning. I always end up looking at something totally unrelated and useless. God knows how I end up on those tangents. :D


[quote=Pedro]
Anyways... to put it short, every data access stuff would be inside [b]M[/b]odels, the presentation logic would be defined in the [b]V[/b]iews, and the [b]C[/b]ontrollers would be sort of like the engine that puts everything together. That's what MVC is in a nutshell.

It's not a fancy way of programming, it concerns mostly, the way the source code is organized.

This might not be of the interest of punbb. After all punbb is a web bulletin board software and that should be it's main goal. But I strongly believe this can be of great value in the future.
This would make it a lot easier to use pretty much any type of data storage. Flatfiles, googledatastorage, a distributed hashtable, etc.[/quote]

I was thinking along the right tracks, it would appear. Personally, I've never yet been able to see the real use for those other than having a common, familiar base that you can use on completely different projects. I suppose, however, if the templating system is indeed going to be a feature of 2.0 that some form of framework along those lines will be necessary rather than merely a consideration?]]></content>
			<author>
				<name><![CDATA[MattF]]></name>
				<uri>http://fluxbb.org/forums/user/14/</uri>
			</author>
			<updated>2009-01-29T19:47:17Z</updated>
			<id>http://fluxbb.org/forums/post/20999/#p20999</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20992/#p20992"/>
			<content type="html"><![CDATA[[quote]I spent over half a day getting sidetracked last time I used that method of having a quick dig around[/quote]
That thing you did is called 'Learning' ;)

Anyways... to put it short, every data access stuff would be inside [b]M[/b]odels, the presentation logic would be defined in the [b]V[/b]iews, and the [b]C[/b]ontrollers would be sort of like the engine that puts everything together. That's what MVC is in a nutshell.

It's not a fancy way of programming, it concerns mostly, the way the source code is organized.

This might not be of the interest of punbb. After all punbb is a web bulletin board software and that should be it's main goal. But I strongly believe this can be of great value in the future.
This would make it a lot easier to use pretty much any type of data storage. Flatfiles, googledatastorage, a distributed hashtable, etc.

I would like to hear more opinions on this.]]></content>
			<author>
				<name><![CDATA[Pedro]]></name>
				<uri>http://fluxbb.org/forums/user/101/</uri>
			</author>
			<updated>2009-01-29T17:15:41Z</updated>
			<id>http://fluxbb.org/forums/post/20992/#p20992</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20982/#p20982"/>
			<content type="html"><![CDATA[[quote=Pedro]Well.. any application built on top of one of many php MVC frameworks out there.
To be honest I can't point one PHP project that follows a strict MVC design, but I don't know the source code ha of many applications, specially when it comes to newer applications that poped up after the MVC hysteria.[/quote]

No worries. :) I just wondered if there might be one, (or more), specifically, that had a reputation for being clean and compact, both from the use and code points of view.

[quote=Pedro]google -> php mvc[/quote]

I try to avoid doing that if possible. I spent over half a day getting sidetracked last time I used that method of having a quick dig around. :D Those damned internet search engines. :D]]></content>
			<author>
				<name><![CDATA[MattF]]></name>
				<uri>http://fluxbb.org/forums/user/14/</uri>
			</author>
			<updated>2009-01-29T00:47:36Z</updated>
			<id>http://fluxbb.org/forums/post/20982/#p20982</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20981/#p20981"/>
			<content type="html"><![CDATA[Well.. any application built on top of one of many php MVC frameworks out there.
To be honest I can't point one PHP project that follows a strict MVC design, but I don't know the source code ha of many applications, specially when it comes to newer applications that poped up after the MVC hysteria.

Sorr I cannot be so specific... google -> php mvc]]></content>
			<author>
				<name><![CDATA[Pedro]]></name>
				<uri>http://fluxbb.org/forums/user/101/</uri>
			</author>
			<updated>2009-01-29T00:42:58Z</updated>
			<id>http://fluxbb.org/forums/post/20981/#p20981</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20980/#p20980"/>
			<content type="html"><![CDATA[[quote=Pedro]Flux could go all the way to an MVC design. Fluxbb code is easy to follow and tidy, but i think it could get even tidier, and one wouldn't need to sort among database queries, output generation and business logic to find a specific spot.
I strongly encourage that, it doesn't require really much code rewrite, it's more a matter of sorting the existing code in a specific way.[/quote]

Any good examples of the MVC type design you're referring to? Just out of personal curiosity. :) All implementations/variants I've seen so far appear, (from my perspective), more awkward with regards to implementing alterations. That may just be due to me not having seen a tidy implementation yet, however. :P]]></content>
			<author>
				<name><![CDATA[MattF]]></name>
				<uri>http://fluxbb.org/forums/user/14/</uri>
			</author>
			<updated>2009-01-28T23:37:47Z</updated>
			<id>http://fluxbb.org/forums/post/20980/#p20980</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20942/#p20942"/>
			<content type="html"><![CDATA[I am not sure this has been discussed before or not...
The views will be isolated finally. What about the 'models'?

Flux could go all the way to an MVC design. Fluxbb code is easy to follow and tidy, but i think it could get even tidier, and one wouldn't need to sort among database queries, output generation and business logic to find a specific spot.
I strongly encourage that, it doesn't require really much code rewrite, it's more a matter of sorting the existing code in a specific way.]]></content>
			<author>
				<name><![CDATA[Pedro]]></name>
				<uri>http://fluxbb.org/forums/user/101/</uri>
			</author>
			<updated>2009-01-28T02:27:11Z</updated>
			<id>http://fluxbb.org/forums/post/20942/#p20942</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20888/#p20888"/>
			<content type="html"><![CDATA[Yes]]></content>
			<author>
				<name><![CDATA[Smartys]]></name>
				<uri>http://fluxbb.org/forums/user/2/</uri>
			</author>
			<updated>2009-01-27T02:40:05Z</updated>
			<id>http://fluxbb.org/forums/post/20888/#p20888</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20887/#p20887"/>
			<content type="html"><![CDATA[so does utf-8 support or not support make any difference?]]></content>
			<author>
				<name><![CDATA[qie]]></name>
				<uri>http://fluxbb.org/forums/user/361/</uri>
			</author>
			<updated>2009-01-27T02:39:28Z</updated>
			<id>http://fluxbb.org/forums/post/20887/#p20887</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20245/#p20245"/>
			<content type="html"><![CDATA[Pedro: Don't be sorry and don't let me stop the discussion. It IS an interesting approach to flexibility and extensibility and is definitely worthy of being discussed, especially considering the development of 2.0. :)

Maybe move it to its own topic?]]></content>
			<author>
				<name><![CDATA[Smartys]]></name>
				<uri>http://fluxbb.org/forums/user/2/</uri>
			</author>
			<updated>2009-01-14T03:04:43Z</updated>
			<id>http://fluxbb.org/forums/post/20245/#p20245</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20239/#p20239"/>
			<content type="html"><![CDATA[Yes, one could write fluxbb entirely like that. Not the most practical/usable/realistic approach, but it would for sure be a cool proof of concept. :) Sort of just jamming with limits of the technology :D

I too, if I should be honest, don't look at this as a must-have. In fact is not even something I would strongly recommend for fluxbb. I just thought it was worth the discussion, that's all. I mean, the extension system hasn't been really tested, one cannot tell for sure what will be its most restrictive characteristics without getting feedback from a reasonably large user base. Who knows if or when this, or whatever other feature, will be necessary?

I can think of some situations where this could be useful, but they're really few. A hosted service for example, could take some advantage of this. What I had in mind was absolutely _not_ slaping a sexy statement on the feature list.

The performance issue you mentioned is for sure the Achiles' heel of this model. If I should think about it more carefully, I would agree with you after all, It would not fit so well in a software that aims to be fast and lightweight rather than having all those features that 1 out of 1000 users need.

Sorry then, it got impressed by a practical implementation of a rather cool concept. :)]]></content>
			<author>
				<name><![CDATA[Pedro]]></name>
				<uri>http://fluxbb.org/forums/user/101/</uri>
			</author>
			<updated>2009-01-14T02:32:51Z</updated>
			<id>http://fluxbb.org/forums/post/20239/#p20239</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20234/#p20234"/>
			<content type="html"><![CDATA[Pedro: That looks like database normalization taken to the extreme. They say that everything in the software is considered to be the same, the only difference are some metadata attributes. I don't see how it helps conflicts between plugins (what I assume you mean by compatibility) and I don't see the advantage for admins, since you need to have CREATE TABLE privileges in order to install the software. You could rewrite FluxBB that way. Users are the same as forums, after all, except for the fact that they're not similar in any way except in that they can both be considered objects. :P

Seriously though, I see the advantage if you want to slap a line in your feature list that says "easily and infinitely extensible." However, that's not the best way to be extensible. It may make your plugin development more accessible (since people don't need to know SQL) but your performance is going to be much worse because you're sticking everything in the same table and relying on joins on unidexed columns.]]></content>
			<author>
				<name><![CDATA[Smartys]]></name>
				<uri>http://fluxbb.org/forums/user/2/</uri>
			</author>
			<updated>2009-01-14T01:34:33Z</updated>
			<id>http://fluxbb.org/forums/post/20234/#p20234</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20232/#p20232"/>
			<content type="html"><![CDATA[As I was reading about this cool software called [url=http://elgg.org]elgg[/url]. I came across this concept that might be something to thing about for fluxbb 2.0.

A generic datatype that can be be inherited and therefore allowing the extension developer to create data entities without touching the physical database structure. This is not a critical feature, but it sounds really neat and I believe it could add multiple advantages.
It would prevent compatibility break downs with other extensions like backup related stuff. It would also improve the deployment of many extension if for some reason the admin has limited access to the database.

It is perfectly possible to implement such a feature without changing the current extension system.  In fact this can be done as an extension itself.

Any thoughts about this?

For more details, please refer to:
[url]http://docs.elgg.org/wiki/Getting_Started_With_Development[/url]]]></content>
			<author>
				<name><![CDATA[Pedro]]></name>
				<uri>http://fluxbb.org/forums/user/101/</uri>
			</author>
			<updated>2009-01-14T00:41:05Z</updated>
			<id>http://fluxbb.org/forums/post/20232/#p20232</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20095/#p20095"/>
			<content type="html"><![CDATA[Because 1.4 is the development of 1.2, not of 1.3. 1.3 will be developed to 2.0. Because that will take some time, 1.4 will first be released with the most important features ("URL rewriting" is not one of the most important ones).]]></content>
			<author>
				<name><![CDATA[Franz]]></name>
				<uri>http://fluxbb.org/forums/user/157/</uri>
			</author>
			<updated>2009-01-12T16:23:04Z</updated>
			<id>http://fluxbb.org/forums/post/20095/#p20095</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Re: The future of FluxBB]]></title>
			<link rel="alternate" href="http://fluxbb.org/forums/post/20094/#p20094"/>
			<content type="html"><![CDATA[Why have you abandoned the idea of "rewritting url" in 1.4 while it was in the 1.3?]]></content>
			<author>
				<name><![CDATA[Actuboard.com]]></name>
				<uri>http://fluxbb.org/forums/user/2677/</uri>
			</author>
			<updated>2009-01-12T16:20:39Z</updated>
			<id>http://fluxbb.org/forums/post/20094/#p20094</id>
		</entry>
</feed>
