@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.
@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).
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.
> 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.
@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 ....
@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
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
Comments
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
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?
"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.
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.
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
Enjoy teh super-hyper-fast colander (pun obviously intended).
Bye
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.
>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
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 ....
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.
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"
@Mark @louis any thoughts or ideas regarding this, technically one coud install "Vanilla" and disable or remove the forums portion