Blog Documentation Try Vanilla Cloud
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.
Options

"New way" of view output possible/desirable?

R_JR_J Ex-FanboyMunich Admin
in Feedback

Views by now always directly echo to screen. You can add something at each FireEvent but what has been echoed by a view can not be altered. If you do not like the output, you have to either use JavaScript or override the view.

I think it would be nice to buffer output with simply adding an ob_start, store the content in a variable with ob_get_contents and pass the reference to that string to the EventArguments. After the FireEvent the variable can be echoed to screen.
That way it would be easier to change output in "difficult" cases.

Is there any negative effect on buffering and passing the string reference that would speak against that proposal?

Comments

  • Options
    LincLinc Detroit Admin
    edited February 2015

    Storing HTML templates in memory and then operating on them doesn't matter for a small site, but would not scale well. It's adding a lot of overhead. I don't see a huge gain in flexibility here over simply overriding the view, especially when held against the performance hit.

    Todd's been experimenting with a PHP-ified handlebars.js for doing client-side template rendering, which should also lend itself to better granularity in what you can override. Ultimately, we want to completely decouple data delivery (API) from views to let you program any view you want with any data you want and no worry about future updates to the template you replaced. Like Smarty on steroids (sorta).

  • Options
    R_JR_J Ex-Fanboy Munich Admin

    Whoa! I'm happy I read my posts a second time before I send them. This part has been written after the part below. Please don't feel offended from what follows. It should really be more discussion than ranting but I haven't hit the right tone. Sorry for that... O.o

    I was just thinking that if you like to make only small changes (change sort order or add some extra tag anywhere) you'd be able to do this with a small string replace. But all in all it is much cleaner the way it is now.

    Client side rendering is a wrong direction to my opinion. Everyone tries everything to make browsing experience better by making it faster and if the client has to render the web page, you would never be able to benefit from server side caching. Users with older mobile phones will no longer be your visitors.

    Separating view completely from the rest is a good idea, but I bet most installations will still use the standard theme. There is nearly no theme that tweaks the DOM heavily (by overriding views). I do not count slightly changed default.master.tpl files in here. So I doubt that this step will change the number of really unique themes.
    I guess using Smarty at more places would have been a natural step before that or at least a step which could have made the transition easier. It now is something which feels really weird. I have a framework with one Smarty template and Smarty functions that I only use for this one template. If you only have one page, you hardly benefit from a template engine at all. With Smarty on steroids you'll create just another template engine. I'm no fan of templating engines (written in a templating language ;) ) at all, so I wouldn't be able to get fascinated by that. I just hope that whatever come as your next solution isn't a Smarty/GardenTemplate hybrid, but one consistent solution.

    Really, really, really not meant offending!

  • Options
    LincLinc Detroit Admin

    I should add that I'm really no expert on this whatsoever. I'm just piecing together bits of conversations with Todd over the last year or two. I know you guys probably think I'm the official word on this sort of thing, but I'm essentially just doing broken telephone between you and him. :)

    FWIW, I'd have the same concerns about client-side rendering on power-limited platforms. I don't really know enough details to speak to it, tho. I'd say we're several months out from a serious push on the next-gen framework when this sort of thing will be more of a focus.

  • Options
    BleistivtBleistivt Moderator
    edited February 2015

    @R_J said:
    Everyone tries everything to make browsing experience better by making it faster and if the client has to render the web page, you would never be able to benefit from server side caching. Users with older mobile phones will no longer be your visitors.

    @Linc said:
    FWIW, I'd have the same concerns about client-side rendering on power-limited platforms. I don't really know enough details to speak to it, tho. I'd say we're several months out from a serious push on the next-gen framework when this sort of thing will be more of a focus.

    Luckily, this problem has been already solved by isomorphic javascript apps.

    http://venturebeat.com/2013/11/08/the-future-of-web-apps-is-ready-isomorphic-javascript/

    Most client-side MVC frameworks support this now.

    My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations

    VanillaSkins.com - Plugins, Themes and Graphics for Vanillaforums OS

  • Options
    R_JR_J Ex-Fanboy Munich Admin

    @Linc: I really appreciate the (very detailed =) ) insight we get in your work! I'm always interested in motivations and considerations behind decisions so that's why I keep on asking such thinks.
    Thanks for your patience in answering questions - I know your job is to write code and not forum comments.

Sign In or Register to comment.