Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.


edited September 2009 in Vanilla 2.0 - 2.8
ok first off, i love the look of Vanilla. It works very nicely and I think it has loads of potential from a user interface point of view.

but... as a developer who only wants to deal with views(i can do more but in this case i only want to deal with views)

consider what they are faced with .. its not easy to understand at all and it should be.

Views should be a lot more modularized. At the moment they contain to much code and are tightly coupled with the controllers.

Why not create a situation where the controller passes all "data" required as variables .. only allow the views to use conditions, loops and echos(variables only). the rest should be pure html/javascript etc top to bottom. (Segmented if you want. e.g. headers.tpl, sidebar.tpl etc.. )

I for example want to put a simple div as a banner at the top of each page e.g.


This is my new banner


where do i do that? I'm sure when some one tells me, i'll understand from now on. That isn't the point though. Use the usability skills you clearly have to analyze the different developers you will have using your framework. wordpress do this pretty good for example.

anyhow more importantly can someone tell me where i can add this little banner div at the top of every page in vanilla? (its possibly I've missed something obvious)


  • Options
    on closer analysis.. i think it comes down to having no skeleton theme already in there. if i could dive straight in and enable a skeleton theme that already has a copy of the vanilla.css and master.default.tpl file then i think it would help greatly but in saying that i should have read the docs a bit better.
  • Options
    SS ✭✭
    @fplcentral do you read some documentation about views?

    Dig default.master.php
  • Options
    I have since my first comment but while it appears to be powerful, doesn't make it easy to dive straight in the way I can with a wordpress theme for example. I've things up and running now and it appears to work fine. but took ages to copy this file then copy that.. etc etc

    so I think an skeloton vanilla theme would be a good idea. Doesn't have to be enabled by defualt but I can edit it quickly and then enable it if I want.

    I suppose my other problem is I've never been a fan of smarty.. something like Savant always made more sense to me. (I know you can overide using the smarty engine)

  • Options
    LincLinc Detroit Admin
    I agree that the templating system is not as intuitive as Wordpress, but we must also realize that a templating system that is extensible for entire applications may not be as easy to use as a template for a CMS. :)
  • Options
    @Lincoln I understand that and some of what i said was merely ranting, but it still offers an insight into a person eager to make changes quick and easy. I still stand by my suggestion that a in-active skeleton theme for vanilla should be included in the distribution.
  • Options
    MarkMark Vanilla Staff
    @Lincoln is correct that templating a multi-page, multi-purpose application with a myriad of varying screens and constantly shifting data is never going to be as easy as templating something like WordPress - which is essentially like templating one page.

    However, I know what you mean about how difficult it is to copy/move things around. I've been doing developer-testing to see how developers and themers use it, and trying to change the things that they find confusing. So far I'm still working out how the CSS is structured. Next up I'll be working on the views.

    From an application perspective, it makes a lot of sense to have all of the views for each application within that application's /applications/app_name/views folder. But from a theming perspective, the person really doesn't understand where to find that stuff, and they want it all in the /themes/app_name/views/ folder. So, we're left with the option of duplicating the views in two places, or choosing one and hoping for the best. Currently I've chosen to leave the views with the applications. That may change in the future.

    Also, as far as passing "data" into the views. @Todd has been working on making this standard, but it hasn't been documented yet. Just know that it's coming, and it's awesome :)

  • Options
    edited September 2009
    @Mark great stuff, sounds very interesting indeed. I'll keep a close eye on this project.

    I'll see if I can contribute with plugins or applications in the future.
Sign In or Register to comment.