Vanilla Forums

With the logo being vanilla, and being the main application, that's sure that having the Garden name around is only causing understanding issues.

Being,"powered by vanilla", and all.

If vanilla becomes the framework, the forum part will need to be renamed.

@bean - not necessarily - we could keep the forum application named vanilla, I think. I considered renaming it to "forum" briefly - but that just seemed silly :)

Well, the conversation part (private messaging) is called conversations, maybe it, the forum part, can be renamed to discussions.

Because I think, otherwise, there will still be some confusion after renaming garden->vanilla.

@bean - you might be right. Food for thought, definitely.

Are you intending to release Garden as a proper framework or not?

As long as "Vanilla" remains a module of a greater framework there will be confusion as to what's what, in my opinion. So I agree with the naming changes @bean suggested.

I like calling the overall "Vanilla" and the forum app part "Discussions" for clarity's sake. That way you could essentially download Vanilla as your user framework and just disable "Discussions" if you're not using it as a forum. Makes sense to me, anyway.

Vanilla 2: More than just a forum. :)

^ What he said... Call the framework "Vanilla" and the forum application "Discussions". No confusion.

Okay, now I'm new to Vanilla - considering using it when the final v2 comes out.

Here's my opinion, nevertheless:
Having looked through various concepts and upgrades, I suggest the following. As most of you can see - things are starting to look like a social network. Go to your profile - it reminds me of Facebook. So, why not have the following: Garden as the framework, Vanilla as the platform, and then 'discussions', 'private conversations', 'image galleries' and so forth added to the platform... It seems like it's headed in that direction.

Do you think that might work? For all you know, Garden could become extremely popular among the masses.

@MichaelAnthony - I think that adds a layer of unnecessary confusion. From a marketing standpoint, adding "Garden" to the mix seems like a lot of extra effort with no real payoff. People are already familiar with the name Vanilla... Which is less confusing:
When you download the "Vanilla" framework, it comes setup as a forum with the "Discussions" application enabled.
-or-
When you download the "Garden" framework, it comes setup as a forum with the "Vanilla" application enabled. Huh?

@MBZ : I see - well at least that's cleared up now. But what are your thoughts of the small 'social networking' idea (that's slightly in place already)?

Thanks to everyone for chiming in here.

It sounds like everyone is more concerned with clarity than with any issues that developers who have branched the code might encounter when we make these changes. Is that correct? If so, I think we should probably just go ahead and do it. A little clarity can go a long way when you're dealing with code :)

Branched code issues? Bah. What's a little GitHub challenge between developers? ;) Clarity ftw.

@Mark @Todd

I like name Garden, and prefix Gdn_ ... I'm using Garden for developing applications for company where I'm working... and I like it. Dont want to change anything.

If you decide to rename, imho, "Vn" is more sympathetic than "vn"
http://vanillaforums.org/page/StandardsAndPractices

Actually, I dont understand the problem (probably my English is no so good) - change name, prefixes, etc. that "many people will understand correctly" what? Send these people to link http://vanillaforums.org/page/MissionStatement :p

So i assume there are no plans to have garden as a standalone framework then.

@minisweeper, @Immersion - We still want to release it as a framework, we're just considering calling the framework Vanilla.

To be honest - I quite like the idea of having Garden is the framework, off which apps can be developed off it. Vanilla is a great name for the forum software. If you were to make Vanilla the framework, then what would the forum software be called?

I´m slightly tending to Framework Vanilla > App Discussions, App Conversations, etc.
PRO: Vanilla is a nice name for a plain-vanilla framework and app names are clear as well.
CON: I liked the question I remember from the beginning: "What´s growing in your garden?" Also I do think there will always be people who misunderstand something ... even the difference between Vanilla and Discussions ;-)

Great work, you guys are doing here!

I think you should go through with this, I mean it confused me alot. Just make it Vanilla! Ftw! Vanilla: What sauce are you having?

However if the framework ever picks up (which to me almost seems like the more useful product, as i have really no need for a forum) then having it called vanilla will be a mess. "Im writing a script for vanilla that does x...the forum or the framework?", "Have you tried out vanilla...". I really love the naming of Garden and vanilla, however i think you should split them in a way. Like the new expression engine is built on codeigniter, there are no problems with peoples understanding. As if your on the expression engine site you know that your talking about the blog and if your on codeigniter then its the framework. Currently you have categories such as Vanilla 2 & Garden, which can confuse people.

Telling people i made this new application based on a forum script sounds very, well, hacky. Saying you built it off a framework that is also used to build Vanilla sounds a lot more stable.

I'm late in on this one... I think as you have already dropped the "Garden" brand it should be dropped from the codebase. I like what @bean suggested, and rename the Vanilla application to Discussions... Adds clarity IMO!

I also wouldnt worry too much about breaking changes at the moment - its not even had an "official" release yet so I guess people expect it.

@Mark, that's a great idea.
@bluecircle - dully noted and agreed.
Vanilla, vn_ -> Apps --> Discussions -> Conversations -> ?

Keep it "Vanilla" Mark! ;)

I agree with calling the framework Vanilla, but given that, surely this app should be called "Forums" and not "discussions". What are your URLs? vanillaforums.org and vanillaforums.com? Looks to me you'd need to change those to vanilladiscussions.org/.com - of course, if you are happy to change the URLs, then go ahead and call the app "Discussions" ;)

Also, even if you call it Discussions, you know people will call it "forum" anyway...

But c'mon... "Discussions" is just so much more web 2.0"ish" isn't it?!

I think the only thing here that would really confuse me, if I didn't know any better, was the difference between a discussion and a conversation.

@Roguefoxx that's yet another reason to use "Forums" ;)

While we are on the topic of cleaning up the code base. May I also suggest that we clean up some of the function names.

I was really surprised to see files such as this:

http://github.com/lussumo/Garden/blob/master/applications/vanilla/settings/hooks.php

The function names used in this file, are in direct violation of the coding standards and practices you guys set yourselves:

http://vanillaforums.org/page/StandardsAndPractices

Not to mention some of the functions lack PHPDoc comments.

@fredwu - Any class that implements Gdn_IPlugin uses underscores in method names as special characters that help the plugin manager identify when and how to execute that method. It's not a case of not following the standards, it is a case of the documentation not indentifying the exception to the rule. Thanks for noticing, though - I'll update the doc.

The whole reason for this discussion is to figure out inconsistencies and fix them. Vanilla 2 hasn't even been released yet, so if you find that things are incomplete (comments, documentation, even classes with @todo's), we are working on it. If you want to get involved and help out, please do!

Thanks for the response @Mark.

Actually, yes, I do intend to get involved and help out. :)

Awesome! I updated the standards document, btw :)

Is "Forums" too general? You know, like "SciFi"...

I like Discussions as much as anything, but then again, I liked the Garden/Vanilla combo.

Renaming the lussumo github account and the Garden repository might have a limited impact. It won't affect people who follow either the account or the repository; I don't think it will affect the forks*; people who track git://github.com/lussumo/Garden.git will just have to change a git setting entry:

cd /path/to/garden/repository/
git remote set-url origin git://github.com/vanillaforums/vanilla.git

or for repositories which have "origin" pointing to a fork, if the mainline repository was called "mainline", it would be:

git remote set-url mainline git://github.com/vanillaforums/vanilla.git

That's a small price.

About the prefix, it would be nice to have something similar for the JavaScript part, like:

var vanilla = window.vanilla = {};
vanilla.definition = function(definition, defaultVal, set) {
[...]
}

*Does someone know if renaming the mainline repository affect the name of the forks? I am guessing it doesn't

This is junk, why call it 'Discussions' not 'Forums'? The site is called VanillaForums.com/.org. (@Stash) is right.

@dinoboff - that's a really good idea for the js.

I totally agree with @Immersion comment above.

Ahem. I think there is another thing to take into account: http://www.drupalgardens.com

lol @spone - Well, I guess that's settled, then :)

garden just makes things confusing, vanilla as the framework, Apps as conversations, App Discussions, and im hoping for APP embeding media into discussions, but yeh anyway, well done for all the hard work.

I am firmly of that stance: Vanilla is a forum application. Call the framework what you will.

I don't understand how some reason that switching the names around would be *less* confusing. People everywhere know Vanilla to be forum software. How would changing its meaning be less confusing for the masses?

Garden has been marketed for some time now as being a framework. Heck, on the front page of the documentation it says, "What's growing in your garden?" (which is pretty catchy!)

I could comprehend changing the name of Garden, if you don't like it, since it's still in beta and has not been widely adopted. Perhaps spin "Garden" as having been the code name of the project.

It just doesn't make sense to change the meaning of a well-known piece of software.

"What's growing in your garden?" I love it! It sounds like decisions have already been made, but the Garden framework and Vanilla application made perfect sense to me. ;-) I've already played with the (name goes here) framework and it looks great. I'm really looking forward to the next releases.

Hi all,
I'm new to the community and I would like to share my opinion about Vanilla with you.

When I first read the documentation for the first time it was *unclear* what Garden was, but reading carefully throught the entire documentation helped me to figure out.
Naming the backing framework Garden is not a bad idea, also having Vanilla built on top of Garden is not an issue, but it should documented better.

I expected to find a *naming convention* discussion here, not a branding one :P

The big issue imho is with the APIs. Garden is certainly a good piece of software because it *does* what is was meant to do, and it does it well, but this can't mitigate the intrinsic flaws of Garden code:
1. There are no Unit Tests (that's not a major issue, although it would be a good indicator of robustness of the code)
2. There are public fields scattered all over (it's a cardinal sin :P)
3. The average cyclomatic complexity for each method is **5.04** (in a scale from 0 to 10. That's too much.)

I would never rely on code that is not well documented (docs and comments in code), unit tested, has object internal state exposed and has that much complexity (the higher the C. Complexity the higher are the number of bugs).

Hope to be helpful in some way, I really love this project.
Keep rockin

PS: I used Sebastian Bergmann's PHP Lines Of Code on library/core/ folder to determine the cyclomatic complexity, here it is the output: http://pastebin.com/f56f099f5

I'd suggest if there's any confusion between Garden and Vanilla it comes down to clarity in the UI -- When the admin section, aka Dashboard aka Powered by Vanilla is actually mostly Garden, then you shouldn't call it Vanilla! Alternatively, as seems to be the approach here, only programmers should know about the Garden distinction--to everyone else, it's just Vanilla, in the same way that everyone knows Firefox or Mozilla or Safari, but those in the know also understand Gecko or WebKit power each. Perhaps part of the problem is the "Powered by" statement itself--maybe it should say, "Vanilla, powered by Garden" instead. Or to refer to Garden solely as -- or as much as possible -- as "Garden Framework" or "the Garden engine". Whatever you do, don't change the names just to confuse me while I'm trying to learn it! ;-)

I agree that we should stick with Vanilla as far as the forums go, but .. and im new to vanilla... if garden will/is meant to handle managing content other than forum discussion like blog posting/articles/pages etc and the forums is going to be an extension of this along with other capabilities like gallery app so on and so forth, then vanilla forums should still be called vanilla. But garden would require a separate website and naming.

Is this the direction of the project? or is garden more or less just the platform for developers ? Is there a separation in the application as far as intention goes, what is the intention of garden?

this gives some info
http://vanillaforums.org/docs

Is Garden supposed to be used just inside of Lussumo development projects or to be released to the public and hope that people will adopt it for their applications?
In the latter case why one should consider using Garden rather than Symfony, Zend Framework, SolarPHP, Yii, CakePHP and any other better framework out there.
In other words, does Garden meet the minimun requirements a programmer expects from a framework (In terms of code abstraction, components dependency, unit tests, documentation, configurability, etc)?

Anyway I totally agree with what @Louis said, Garden shouldn't be mentioned to the end user, the example of Firefox/Safari and their rendering engines fits perfectly.

Ot: please don't turn Vanilla/Garden in a Wordpress clone =(

@Trashofmasters, as a framework and from my perspective as a developer used to other frameworks but having only just started playing with Vanilla a few days ago, I would suggest that Garden is well on its way to being a professional framework. It's maybe 40% there, and worth exploring right now as it grows. Unlike many frameworks that take a Rails approach for MVC conventions, Garden doesn't quite follow the MVC path and yet is all the easier to understand for it. @Mark's PHP5 coding impressed me back in 2005 when everyone was running PHP4, and it's only improved since. If I were to compare it to Rails, I'd suggest it's perhaps 2005 right now, well before Rails hit 1.0 and about the time iirc, it was still being developed primarily for BaseCamp--I'd say Vanilla is to Garden what BaseCamp was for Rails, it gave it a purpose to develop, but it's not much used outside that product yet. Oh and the lack of tests mentioned above is not the only problem with relying too much on Garden right now-- the code has yet to have an official release, which means things are still relatively in flux and it takes a brave, determined developer (or one with little to lose) to plant their app in Garden. But I think if you take a look at the source code & docs, you'll be surprised and intrigued.

Thanks for the illuminating reply @Louis, I see your point.
But for me, Garden can be easily defined almost well organized Spaghetti Code, put it as Lasagne Code.
Don't get me wrong, I looked the code thoroughly in the past week, debugged and profiled some parts of Vanilla.
I'm no software evangelist, but according to my humble knowledge I thought you'd like to have suggestions about how the code could be improved.

I really love Vanilla, but the expectations that you and the software itself have set are far from meet by the code.

The first thing I felt when reading Vanilla's code was that the developers were trying to put as much code as possible to make something work.

Furthermore when I started debugging I've noticed i) Dispatcher that instantiate pseudo-Database Abstraction Layers, ii) pseudo Events fired all over the place in a foolish manner, iii) object composition made the wrong way (the so much praised Magic Methods), iv) functions without namespaces, v) again the dispatcher holds a pseudo-registry that is passed to controllers, vi) controllers are full of public properties, vii) controllers that holds presentation layer state, viii) global variables, ix) boilerplate code, etc...

Now, it's okay to have _some_ breach of insulation between layers, but in this conditions I'd say that Garden/Vanilla2 code is Legacy even before the end of Beta state.

You could replace your view functions (e.g. Anchor) with View Helpers; use decoration or composition for enhancing controllers behavior at runtime, instead of relying on the current madness.

I would suggest that _maybe_ the best approach would be to rewrite the View and Controller and Dispatcher layers from scratch.
Don't think of MVC as the one used by say ZF. A perfectly working, testable and insulated MVC (actually a View, Front Controller, Action or Page Controllers and a Dispatcher) implementation can be written in less than 600 lines of code in about two hours.
Making it work with the current code will require a lot more tha two hours because the lack of abstraction and flexibility of the current code.
With a new Dispatcher and Page Controller in place, adding a new serious Plugin architecture would be a matter of minutes.

Hope you appreciate my 20 cents.

Thanks also for your reply, @Trashofmasters -- I must admit I haven't yet looked into much of the core code, but I've been impressed so far with the way permissions are done, the magic way themes can override views (which I'd first seen in Joomla), and how simple much of the code is, from an app development perspective. I'll admit that I dislike aspects, particularly the lack of useful comments in the source code, since magic only benefits those who know about it and understand it or what it should do.

But I would suggest that MVC itself isn't as suited for PHP, since there's already going to be a split between an HTML view, and additional JavaScript programming, and since HTTP is entirely session-less, a two-way model isn't necessarily useful. I think so far Garden has developed out of practical needs for reusable PHP code, and perhaps as something of an evolving experiment.

I've seen things here I don't often see elsewhere-- If Garden were much more insulated, as you suggest, would you then need to write more code as an app or plugin developer? Could there be more complexity involved in creating a theme that overrides views, etc.? And how might such a framework then be any different from CakePHP, or why not then use Rails? I suspect that while there are plenty of possible improvements to Garden, they shouldn't be made for their own sake but rather to correct for specific practical problems in the current implementation.

At a certain point, too, with PHP, I just assume I'm hacking away rather than building something "properly". After all, PHP started as nothing more than a quick template language with tons of functions. Even today, I'd rather write PHP without longer namespaces than have to refer to echo as System.out.print...

@Louis: your is a hard comment, as a non-English speaker I had to read carefully each sentence multiple times to ensure I got your point.
I'll reply in order, trying to follow your argument, starting from the second sentence.

ii) That left me perplexed. Maybe I just didn't fully understand what you meant.
Anyway I'd argue that Mvc doesn't have to do with Php. Indeed Mvc has found better applicability with web-oriented scripting languages rather than with the one is was meant for: Smalltalk. Hence saying that Mvc isn't suited for Php implies that it isn't suited for Ruby, Python, or any other language that may be used for web development. Furthermore HTTP statelessness doesn't have anything to do with Vanilla besides user authentication persistence =(

And I catch an implicit implication that Garden do is reusable.

iii) Theming Vanilla will never be that good because most parts of the HTML are written inside of Vanilla core files.
Are theme developers supposed to hack Vanilla internals to achieve the desired result? Don't confuse naïve implementations for simple ones.

That's just rambling speech, in fact insulation between layers will reduce the effort for refactoring, adding or enhancing current functionalities or even adding new ones at runtime (namely plugins), theming and finally code-reuse.

There's no comparison between Rails or CakePhp and Garden. Really.

iv) That wouldn't be the proper mindset for developing a wannabe "professional framework".

Yeah you're right, PHP began as a template language, hence PHP users should use it as a template language; just like Java was meant for powering tv-decoders so it's a madness to use it for developing serious business applications or frameworks.


Sorry for taking your back to reality but Garden/Vanilla code is really far from reusable and flawless. That's the very reason I decided to spend (but perhaps waste) three days debugging, profiling and reading Garden/Vanilla code hoping that sharing my humble opinion would be any help.

In conclusion, enjoy your Spaghetti.

Thanks for the feedback, everyone. We appreciate input of all flavours :)

@Mark: I see. And the fact that this discussion was un-sticked confirms that, doesn't it? =)

It's only a shame that some developers are that jealous about their code.

All this made me remember of: http://developer.pidgin.im/ticket/4986. lol

Bye

Dear @Trashofmasters,

Let's agree to disagree about PHP, I guess. You see it as a wonderful language equivalent to Ruby/Python, and I don't. You seem to expect all frameworks to strictly adhere to MVC, and I don't. That's fine-- there are plenty of other frameworks for MVC out there, thanks for checking out Vanilla and for the feedback. It made me really think about why I like Vanilla, in all its slightly buggy glory, and I've come to the conclusion that it's a framework unafraid of doing something differently on the off-chance it works better in PHP.

For while you speak of PHP being similar to Ruby/Python, it isn't-- People actually write web servers in Ruby/Python or even write shell scripts in those languages, Apache doesn't come preinstalled for Ruby/Python, and the way you refer to variables with dollar signs or have few namespaces for native functions all highlight how different PHP is from more academically-suited languages like Ruby, Python, or Java.

If you want true MVC, even in JS, might I recommend Google App Engine for Java/GWT or Python? You might have more fun or interest there as GAE can support 5 million hits/month for free, but doesn't support PHP. Great for academic explorations and writing Java EE code.

Thanks,

Louis.

@Mark, @Louis, thanks for taking the time to reply.

Although I totally agree with you about the fact that Php isn't suited for _academical_ purposes, I find rather pity excusing the lack of good design principles just because you underestimate the language. You shouldn't take yourself too seriously.

I understand that Vanilla is Open Source Free Software and it's being developed by brave developers who invest their time shipping something useful for the community, that's really deserving. But with the success gained by Vanilla undertaking maintainability, better development approaches and thus security, is risky for you and for the end user who will unconsciously install a bad piece of software.

Any remembrances of PhpNuke, or PhpBB 2?

So you obviously have the right to ignore my opinion but in any way you can't ignore the fact that your software will be used by others. That's a big responsibility you're not taking into account.

For the rest of your comment that's not the appropriate place to argue about other technologies. But IMHO perhaps Php wouldn't have been that bad if careless programmers programmed in another language.

And again: don't be jealous of the code you write. =)

Bye

@Mark can we have some confirmation on the naming front. I was going to purchase some domains for some vanilla side projects and garden framework however if the naming is going to change then i shall hold off. But it is stopping me doing much additional work to try and develop almost a business around vanilla.

@garymardell - We haven't made a final decision yet, but I know @Todd is leaning towards switching to the vn naming conventions and the dropping of "Garden" in the code. It's a large undertaking, so I don't know when we'll be able to get to it. But I know that Todd has used the vn naming convention on one of his new classes, so it has begun.

I kind of agree with @Trashofmasters. Theming is a bit haywire. I would like an appropriate View and Frontend Controller on Vanilla. I have to hack away at different functions to get some simple theming put in to my forums.

@dietbrisk - In Vanilla 2 all of the theming is done with views. The only functions employed were helper functions (which are themeable as well) and were necessary for speed optimizations.

@Mark, if we are swapping to Vn from Gdn, what will distinguish the framework from the forum? I don't want to use the wrong controller as a basis for my application, etc.

Why not swap out all visible references but leave the garden nomenclature under the hood for those in the know, again like web browsers do? After all, only developers need know that the Vanilla/Firefox chrome is different from the Garden/Gecko engine, or that XULRunner is used in some other app like Garden could be used. Most people still think Firefox, and only devs need know the difference.

As to the helper functions, I've wondered why not call it h() instead of Html? Of course, then I think of how Rails now does HTML sanitization by default when using <%= ... %> where before it required <%=h %> ...

@Louis - Good points. Nothing is set in stone yet, but I was thinking the forum application would be renamed to "forum" or "discussions".

I think the whole notion of renaming from GDN_ to vn came out of the realization that there were some classes which didn't follow the GDN_ nomenclature, and needed cleanup - so we thought, "While we're fixing these up, is there a better way to do things overall?"

@mark well, that's what i mean. the helper functions didn't make things very feasible. and if I wanted to port in variables into the helper function, I had to modify the helper function and modify the pages that called the helper function.

Vanilla uses smarty. I don't understand why the templates can't be stored in smarty templates, which the helper function calls...? How exactly do you use Smarty, and what for? because there's HTML and copy (text) in almost every php file.

as for the naming convention... it depends. Are you aiming on building and marketing a MVC? or a forum?

you could have Vanilla, and Vanilla forums is the default forum app. Or you can have separate a Garden framework page, and Vanilla forums as a show case of what you can build with Garden.

Ruby on Rails is a framework that came out as a necessity to build Base camp. But they're not exactly still connected to this day. RoR grew up to be its own thing. No reason Garden can't do the same. You will have to visually separate these entities and emphasize that Garden is more than just a forum engine.

@dietbrisk: Smarty was used on earlier "releases", you could find it last summer. Since then it has been replaced, I guess it's easier for php developpers to write php than Smarty templates. So when Mark changed things later on, he wrote php. Maybe it will be back with Smarty templates once he got time enough.

@dietbrisk - the helper functions can be themed as well. Just copy it into your theme's view folder just like a view and make the necessary changes. You may have to change the parameters passed in, and of course that means you also have to change the related views that call it. But it's all do-able and *much* faster than the inline code was.

@Mark, @Louis, @luc: What I understand from your comments is that you disdain any criticism against your God solution to a problem. Refusing to listen user inputs is the wrong way of doing Open Source Software and also deteriorates the reputation of Vanilla among its user base.

Why should a *Designer* have to modify Vanilla helpers in order to get the desired chrome? To me that seems dull, indeed not only Helpers logic is duplicated, but there are odds that Designers could break Helpers.

Bye

My .2

@Trashofmasters It seems you don't understand what they were getting at. They didn't suggest that it is the "God solution" as you put it. Without the helpers vanilla would be an awful lot slower so they have the solution that means that the majority of it can be done with templates and the tiny amount is done with php.

I don't know of any script that requires a designer to have completely no knowledge of the language it is written in. In the conventional sense the designer creates the UI and then a developer would be in charge of implementing it.

What script are you comparing vanilla too in terms of customizing?

Bah, it seems you're thinking about performances too early.
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" — Donald Knuth.
You're can't talk about performances/bottlenecks without having tangible, scientific proofs (software metrics, profilers). Designing and developing a software is not something that should be done randomly.
Moveover making a **Beta** software fast is a waste of brain and time for a quadrillion of reasons.

What if cars didn't have the gear shift because producers thought they were useless and **could** slow down gear-ratio switching? Would you hack inside the gearbox anytime you had to switch gear ratio?

Sounds idiotic, doesn't it?

Go monetize that car.

Apart from the example and this useless thread you're right, there's no solution that doesn't require one to know at least some basic template language.
The issue is that Vanilla core is stuffed here and there with HTML code that should not be there.

Vanilla is yours do whatever you want, it's software development don't take it personal.

Something like performance in vanilla templating will need to be sorted from the start, any changes to the way the templating is done down the line would mean a complete change of every template released up until that point. Clearly it was profiled and found that using a helper function was indeed faster.

There is no html in the vanilla core. Its all in templates and the helper functions in the view folder in vanilla 2. And all of which can be overwritten in your own theme.

If vanilla doesn't work exactly as you would like then don't use it, its clearly not for you. They didn't refuse to listen to you, just as they didn't agree with you. If you want something changed, its open source as you mentioned you can go and write it and come back to show it. If it is better then i'm sure that it will be considered.

For sake of politeness thanks for the invite to join the hack party, I enjoyed sharing opinions with you but I have to refuse because I've not enough spare time to patch code.

Don't mind, there are slimnesses that I'm not good to point out as I imagined. My fault.
Everything will have a sense in a couple of years, it's just a matter of time.

A part from typing code Open Source is also filing bugs/issues and reporting flaws and vulnerabilities =) that's a kind of contribution. Isn't it?

Enjoy teh super-hyper-fast colander (pun obviously intended).

Bye

Trashofmasters,

Regardless of anything you've said in the last few posts (which I found very hard to understand), have you not heard of Benevolent Dictator For Life (BDFL; Wikipedia)? You've a forum to speak here, and it's obvious you've spoken. But only those with commit privileges (and no, that doesn't include me) actually decide what goes in Vanilla. But hey, you're welcome to fork the project on Github -- I did. Which reminds me, I gotta pull in the latest changes...

Can you not point to any existing PHP source code as the way to follow? Why pick on Vanilla? If no one else has done it that way, why should we? And what is your native tongue, what language do you speak? I begin to wonder if English is part of what's confusing things.

Honestly, it's just my personal opinion, but I hope you don't reply again here. I begin to wonder at the value of your posts or "contributions" to this discussion.

@Louis: I apologize for the frequent errors in my posts, I don't have too much time to reply and the time zone difference doesn't help.

>Can you not point to any existing PHP source code as the way to follow?
Sorry? I'm not totally sure about the meaning of this sentence.
If you would like to see some references, here's a small list of the things I suggested:
Zf
Controller plugin architecture:
* http://framework.zend.com/manual/en/zend.controller.plugins.html
View helpers:
* http://framework.zend.com/manual/en/zend.view.helpers.html

PoEAA
Front Controller
* http://www.martinfowler.com/eaaCatalog/frontController.html
Two-Step View
* http://www.martinfowler.com/eaaCatalog/twoStepView.html
Template View
* http://www.martinfowler.com/eaaCatalog/templateView.html

> If no one else has done it that way else has done it that way, why should we?
Because you're just reinventing the wheel.

Another thing that surprised me was in the file: library/core/class.dispatcher.php @line 255
// Destruct the db connection;
$Database = Gdn::Database();
if($Database != null)
$Database->CloseConnection();

A Dispatcher should only take the Request object as input from a Front Controller and instantiate the proper Page Controller depending on its state. There shouldn't be any database related code inside of a Dispatcher.

That's it, I just wanted to point out some formal errors in the planning and development of Vanilla, because as I said twice (or more) I'm currently using it for a private project and I had to study the majority of Vanilla's code.

I hope I made myself clear.

Bye

@Trashofmasters Thank you for being more specific. As I said, I can't commit changes, but I'll read over what you've linked to, I'm half familiar with some of it.

All I can suggest is that patterns are merely patterns, and don't always have to be followed, but it should be a conscious decision to deviate or apply patterns where necessary. For instance, you mention Page Controller, but maybe thinking of the controller as what produces a "page" is a limitation - e.g. the overlay view of the sign-in form or, from a design perspective, what Adaptive Path called Page Rage yesterday.

But please, if no one implements your suggestions, don't take it personally. These things take time, and aren't easy. Perhaps the benefits don't yet outweigh the drawbacks. Or there are other problems to focus on. Who knows ....

Don't worry @Louis.
Now I really have to go (it's 6:42am and I didn't sleep to follow the topic).

I will fork Vanilla on my GitHub and implement some of my suggestion just to try them out as soon I have some spare time.

Bye

Ps: Thanks for the link to Wikipedia, I didn't know about "Benevolent Dictator For Life". That was an interesting read.

@Mark @Louis
After taking some time to think about this, its become apparent that a large number of online projects are already using the term/name "Garden" along with other similar slogans. for example

http://pages.ebay.com/garden/
http://www.drupalgardens.com/
http://wpgarden.com/ "not an official WP page"

so on and so forth.. to summarize on my opinion, I agree with @Todd. Not only is the name already in use by other projects, but keeping consistency with the Vanilla name would in my opinion be desirable for the end product.

So, instead of the core application being Garden, and Vanilla being an application addon for the forums portion, it makes more sense for the entire project to continue with the Vanilla naming, but the forums application should be renamed as proposed by @Mark to "Discussions/Forums"

also, if we continue with the Vanilla naming, and the forums are considered a addon/plugin/app ... will we change the domain name from vanillaforums to something more centrist?
@Mark @louis any thoughts or ideas regarding this, technically one coud install "Vanilla" and disable or remove the forums portion

did anything ever come about from this? will there be a follow up blog post?

hi i am new here