Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 5 of 5
  1. #1
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,184
    Thanks
    10
    Thanked 569 Times in 550 Posts

    Mustache with ASP.NET

    Quote Originally Posted by felgall View Post
    By not keeping the JavaScript separate from the HTML and each independent script separate from each other you are losing all the benefits that have gone into programming language development over the past 30+ years.
    yeah, totally, you hit the nail on the head; that's not hyperbole or anything.

    if there is one make-or-break aspect of web programming, it's definitely avoiding
    Code:
     onclick="findRep.run(this.value)"
    in favor of
    Code:
    $("inpFRterm").click(function(){findRep.run(this.value);}
    you can spot from across the room how profoundly revolutionary and amazing better that .js-based binding is compared to the .html binding.

    why wouldn't everyone love that? i'm sure my designers won't mind digging through JS files or waiting on me to wire an extra close button in. it's super easy to firebug into a production site and dig though the minified css and js to find your edit point, not having to deal with all that pesky syntax-highlighted confusingly fancy stuff you see using "View Source". MVVM is not gaining popularity at all, and none of the big players put event or data binding in the markup itself. i mean we figured out in 1999 that that was a bad idea right?

    </sarcasm>

    alright, so joking aside, i agree with some of what your saying. i believe there is a balance, and it's more than possible to use html-based binding poorly. obviously i can't agree with everything there. i speak from my own personal experience, and what i've found.

    at my workplace we manage about 140 sites and about 40 custom web (.net mostly) applications. we have traditional programmers, dbas, designers, and many interns that actually build the static sites and maintain the content, do re-designs, etc. many of the sites were last refactored about 4 years ago, with complete separation of content, presentation, and logic. We have some sites from before where the interaction was done using event attribs. and we have newer ones where there is declarative markup but not actual js in the html markup, ala bootstrap. the interns and designers find the .net projects virtually un-touchable. there are tons and tons of folders and placeholders, so it's hard to tell from a paragraph in a file what's going to come out the other end. The younger employees also hate the super-detached hard-coded jQuery sites, and i have to agree they are more complicated to adjust to a re-design than the old-school ones. the interns also like the declarative attributes, which our framework turns into the sort of hooks and bindings that are often needed in js; slideshows, tabbed panels, video embeds, etc.

    i've also recently found through re-coding a highly-separated app that using templates drastically cuts the amount of code required. i took a fancy grid from 400+ lines of external js to 30 lines at the bottom of the page using mustache templates hard-coded into the static first-row html. by using event attribs to hit class toggles to show things like [Edit Status], and within those little panels that we inevitably need like [OK] and [Cancel], i'm able to wire-up the whole grid to a db in two or three lines of code, mostly html. the rest of the js is wiring the datatables to the ajax in a custom fashion. i did have to fatten up the object i fed mustache, but the payoff is a page that boots in half the time as before, saves two http requests, and is easier to maintain, all parties involved agree.

    i think the important distinction at play is not necessarily having 1995-style onwhatever events in the markup, but having something in the html markup in general. When one needs to edit the interface, they need to edit the html, that's a given. if the interns can cut and paste simple actions like they can the meta and styling triggers, fewer requests bubble up, which makes me happy.
    Last edited by rnd me; 07-27-2013 at 08:29 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/1/19) IE7:0.2, IE8:6.7, IE11:7.4, IE9:3.8, IE10:4.4, FF:18.3, CH:43.6, SF:7.8, MOBILE:27.5

  • #2
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    RndMe: So you are using Mustache Templates with ASP.NET?

    Did you roll your own, or do you have a URL to look at that describes the integration of the two?

    We are looking at rewriting some legacy classic ASP pages that are crying out for just such an implementation, from the sounds of it.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #3
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,184
    Thanks
    10
    Thanked 569 Times in 550 Posts
    Quote Originally Posted by Old Pedant View Post
    RndMe: So you are using Mustache Templates with ASP.NET?

    Did you roll your own, or do you have a URL to look at that describes the integration of the two?
    that app is behind an AD login, so i can't really show you. It's using .net mvc to "ajax" feed a jQuery datatables from a sql server db. i'm not a huge fan of datatables, but it works and does have a lot of features you can (almost) drop-in.

    the app had been rendering the html table server-side and then upgrading it with datatables.

    datatables also supports an ajax input, so in .net i basically switched out the html spitting part with a new action that spawns a lambda object, which is then transformed into json and returned to the controller. the data is populated from a linc query based on the pagination, search terms, etc. ~30 LOC (C#).



    i had to customize the datatables to get it all to work. fnServerData() if i remember correctly. basically, datatables like to simply echo one DB col into one html col. what i do in the fnServerData callback is transform the server data into HTML data, preserving the array structure datatables needs. so instead of injecting the raw column, it injects a transformed html string instead. in a loop-de-loop through each row's incoming array of cell data, i use something like
    Code:
     newrow[ i ] = Mustache.render( templates[ i ],  merge(row, objState) );
    note how it feeds the whole row of data, merged with some other data, instead of just a column of data, which is why "i" is used twice instead of three times. this was the big "aha" that unlocked a ton of power in the simple mustache library. the merge is actually done before the inner (column) loop to avoid repetition, but this reads easier...

    that all happens super fast, about 30 rows per ms, which was a huge step-up in performance compared to mounting/ripping an existing html table.

    the server data is like the first column in the middle of the datatables usage page.

    to gather the templates, i simply grab the first row's TD html right away, before anything renders (i used bottom of page on-page script tags, so i didn't have to wait on ready):

    Code:
    var templates=$("#grid tbody tr:first-child td")
       .map(function(){return $(this).html()}).toArray();

    the first row html would be something like this (made up particulars, pattern applies):

    PHP Code:
    <tr>
      <
    td>{{id}}</td>
      <
    td>Published at {{response.dates.publication}} 
        
    by <span class=info onclick="App.modal(App.getUserPanel('{{response.user.name}}'))">{{response.user.id}}</span></td>
      <
    td>
       {{
    #reponse.dates.completed}}Done{{/reponse.dates.completed}}
       
    {{^reponse.dates.completed}}Pending{{/reponse.dates.completed}}
      </
    td>
      <
    td>
           <
    input type=button onclick="App.confirmRemoval('{{id}}', this )">delete</button>
      </
    td>
    </
    tr
    datatables already has a lot of features, but it's main limit was dumb column insertion. using a client site template lets the server do less. the end-user result is that it's faster than before because it avoids shipping hidden rows or refreshing the page to navigate.

    you can probably do the same thing with some $(whatev).on() events instead of the click events. if you need other fancy events, like oninput, you might need attribs or after-rendering loops. i prefer the attribs because i don't have to loop through the dom after injecting the html to bind events.

    i can't show the before .net code, but it was a lot of conditionals and long-winded name-spaced class calls. very professional and abstract in it's own right, but about 400LOC to render the view. since i can feed a linc return right to json, and mustache turns that into rich html in a couple lines, and data tables does most of the behavior heavy-lifting like sizing, sorting, filtering, etc, the whole thing is about 100 lines of code front and back. it also boots much faster since were not spinning up as much (almost none) .net functionality for each grid rendered. users have raved about the pagination performance and boot time reduction since we switched it into production.
    Last edited by rnd me; 07-28-2013 at 05:38 AM.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/1/19) IE7:0.2, IE8:6.7, IE11:7.4, IE9:3.8, IE10:4.4, FF:18.3, CH:43.6, SF:7.8, MOBILE:27.5

  • Users who have thanked rnd me for this post:

    Old Pedant (07-28-2013)

  • #4
    Supreme Master coder! Old Pedant's Avatar
    Join Date
    Feb 2009
    Posts
    25,020
    Thanks
    75
    Thanked 4,323 Times in 4,289 Posts
    Very nice. Amazing that you used datatables like that, because that is *EXACTLY* the advice I gave just yesterday to a person trying to render similar "dependent" data. Granted, I wasn't suggesting Mustache, but the concept was the same. Now you're going to make me go take a real look at Mustache. Thanks, very much.
    An optimist sees the glass as half full.
    A pessimist sees the glass as half empty.
    A realist drinks it no matter how much there is.

  • #5
    Senior Coder rnd me's Avatar
    Join Date
    Jun 2007
    Location
    Urbana
    Posts
    4,184
    Thanks
    10
    Thanked 569 Times in 550 Posts
    Quote Originally Posted by Old Pedant View Post
    Very nice. Amazing that you used datatables like that, because that is *EXACTLY* the advice I gave just yesterday to a person trying to render similar "dependent" data. Granted, I wasn't suggesting Mustache, but the concept was the same. Now you're going to make me go take a real look at Mustache. Thanks, very much.

    if you like mustache but need a little more control, you might also want to checkout http://handlebarsjs.com/ . it's based on mustache, but with some extra stuff added to do customization and basic logical operation. it's quite a bit bigger than mustache, ~75kb vs ~15kb.

    i've found the mustache is enough for my projects, and it's tiny and bulletproof. if you look close, mustache does have the conditionals, pre-compilation, custom helpers, comments, and "with" blocks that handlebars touts. handlebars adds else, log, script-tag mounting, and few other things...

    anyway, there are a lot of templaters out there, and the make R.A.D. a lot more realistic on the web. you can use them like xslt without the compat problems and same-origin restrictions. none of them are a standard like xslt afaik, but they use other standards that are universally supported to perform the work, so they run reliably everywhere.
    my site (updated 13/9/26)
    BROWSER STATS [% share] (2014/1/19) IE7:0.2, IE8:6.7, IE11:7.4, IE9:3.8, IE10:4.4, FF:18.3, CH:43.6, SF:7.8, MOBILE:27.5


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •