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?
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.
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.
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.
@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.
@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.
Comments
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
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 =(
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.
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...
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.
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
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.
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
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 %> ...
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?"
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.
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.