HBase
  1. HBase
  2. HBASE-6259

Unify all of the templates into one templating language

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.95.2
    • Fix Version/s: None
    • Component/s: master, regionserver
    • Labels:

      Description

      Right now .jsp and jammon templates can't share common parts as they are un-related. We should move to one templating language. Maybe also move away from jamon.

        Activity

        Hide
        Andrew Purtell added a comment -

        Maybe also move away from jamon.

        HBASE-3835 starts with "Jamon (http://jamon.org) is a template engine that I think is preferable to JSP. You can read an interview with some comparisons vs JSP here: http://www.artima.com/lejava/articles/jamon.html"

        Can you say more?

        Show
        Andrew Purtell added a comment - Maybe also move away from jamon. HBASE-3835 starts with "Jamon ( http://jamon.org ) is a template engine that I think is preferable to JSP. You can read an interview with some comparisons vs JSP here: http://www.artima.com/lejava/articles/jamon.html " Can you say more?
        Hide
        stack added a comment -

        IIRC, our current state spanning jsp and jamon is because the convertion went 90% of the ways and Todd left the last few templates for someone else to do so someone other than he would know about jamon; none of us took him up on the last few convertions.

        If you want to do something else, and I'd suggest that there should be a good reason for moving off one system to another, there is the spreadsheet Luke did a while back looking at templating systems for hadoop: https://spreadsheets.google.com/pub?key=0AtkkDCT2WDMXdC1HOEtnUHpCejJMbUhGeGJWUmh5dVE&hl=en&output=html Its out of HADOOP-7532. That spreadsheet, while it looks great and comprehensive, it must be wrong because it has the Grails abomination coming out on top. Besides Luke wanted something else altogether (See HADOOP-7532 for interesting templating system discussion).

        Show
        stack added a comment - IIRC, our current state spanning jsp and jamon is because the convertion went 90% of the ways and Todd left the last few templates for someone else to do so someone other than he would know about jamon; none of us took him up on the last few convertions. If you want to do something else, and I'd suggest that there should be a good reason for moving off one system to another, there is the spreadsheet Luke did a while back looking at templating systems for hadoop: https://spreadsheets.google.com/pub?key=0AtkkDCT2WDMXdC1HOEtnUHpCejJMbUhGeGJWUmh5dVE&hl=en&output=html Its out of HADOOP-7532 . That spreadsheet, while it looks great and comprehensive, it must be wrong because it has the Grails abomination coming out on top. Besides Luke wanted something else altogether (See HADOOP-7532 for interesting templating system discussion).
        Hide
        Elliott Clark added a comment -

        Sure.

        I'm not really advocating for jsp. I'm pretty much advocating the same thing that was advocated in HBASE-3835. Our pages have very bad separation between the html view and domain models. Things like per-region metrics, and getting config values use java code embedded in html way too much. Jamon seems like it has not seen the adoption of some other solutions and it hasn't really followed the trend of moving computation out of the template; in fact it looks like there has been no work on jamon in a while. In addition template inheritance is pretty messy in jamon, and now that we have more of a ui template it would be nice to use that so that changes like the HBASE-6219 could be done in one place.

        I don't have strong opinions on specific templating languages, however I do think picking one that minimizes java code would be good.

        Show
        Elliott Clark added a comment - Sure. I'm not really advocating for jsp. I'm pretty much advocating the same thing that was advocated in HBASE-3835 . Our pages have very bad separation between the html view and domain models. Things like per-region metrics, and getting config values use java code embedded in html way too much. Jamon seems like it has not seen the adoption of some other solutions and it hasn't really followed the trend of moving computation out of the template; in fact it looks like there has been no work on jamon in a while. In addition template inheritance is pretty messy in jamon, and now that we have more of a ui template it would be nice to use that so that changes like the HBASE-6219 could be done in one place. I don't have strong opinions on specific templating languages, however I do think picking one that minimizes java code would be good.
        Hide
        stack added a comment -

        Sounds reasonable. What from the list above cited would you consider (and don't say Grails)? And how much work converting to yet another templating system and do you think it worth the effort?

        Show
        stack added a comment - Sounds reasonable. What from the list above cited would you consider (and don't say Grails)? And how much work converting to yet another templating system and do you think it worth the effort?
        Hide
        Elliott Clark added a comment -

        I don't really know enough to have a very in-depth discussion about those so I would hold off on throwing my support to one until I have some time to poke at the options.

        As for do I think it's worth the effort, that kind of depends on what people want from hbase. If a minimal ui is all that we invision ever having then just keeping jamon and moving the last pages off of jsp seems the best. However if we want to have things like monitoring and trending (stack you and I had mentioned this), a shell (someone at hadoop summit mentioned this), and configuration (we started talking about dynamic configs lately) all on the ui then I think it could be worth it to go to a more modern and adopted framework (GWT would seem to be a good way to get rich views without a UI expert but that's just a first thought).

        ps. Why is rails even in there? I like rails and all but I don't really relish pulling in all of the ruby wold to make some html strings.

        Show
        Elliott Clark added a comment - I don't really know enough to have a very in-depth discussion about those so I would hold off on throwing my support to one until I have some time to poke at the options. As for do I think it's worth the effort, that kind of depends on what people want from hbase. If a minimal ui is all that we invision ever having then just keeping jamon and moving the last pages off of jsp seems the best. However if we want to have things like monitoring and trending (stack you and I had mentioned this), a shell (someone at hadoop summit mentioned this), and configuration (we started talking about dynamic configs lately) all on the ui then I think it could be worth it to go to a more modern and adopted framework (GWT would seem to be a good way to get rich views without a UI expert but that's just a first thought). ps. Why is rails even in there? I like rails and all but I don't really relish pulling in all of the ruby wold to make some html strings.
        Hide
        Andrew Purtell added a comment -

        GWT would seem to be a good way to get rich views without a UI expert but that's just a first thought

        And Ambari pulled in YUI...

        Show
        Andrew Purtell added a comment - GWT would seem to be a good way to get rich views without a UI expert but that's just a first thought And Ambari pulled in YUI...
        Hide
        Todd Lipcon added a comment -

        If a minimal ui is all that we invision ever having then just keeping jamon and moving the last pages off of jsp seems the best. However if we want to have things like monitoring and trending (stack you and I had mentioned this), a shell (someone at hadoop summit mentioned this), and configuration (we started talking about dynamic configs lately) all on the ui then I think it could be worth it to go to a more modern and adopted framewor

        IMO we should keep the built-in pages simple, and expose all the right APIs so that an external "fancy" UI can be built. The fancier we make the built-in UI, the more likely we have bugs in it, and the less likely it'll be usable from command line browsers like lynx (yes, I do that reasonable often!). It also tends to result in cases where we have data that's only visible through the UI, which encourages people to start scraping HTML to gather metrics, etc.

        On the other hand, if everything's available via APIs, then we can have an external web UI with all the whiz-bang features we want. The external UI might be another daemon running in the HBase project. I think Accumulo takes basically this approach (theirs is called the "Monitor" process, and it talks to the actual daemons via thrift, as far as I understand)

        Show
        Todd Lipcon added a comment - If a minimal ui is all that we invision ever having then just keeping jamon and moving the last pages off of jsp seems the best. However if we want to have things like monitoring and trending (stack you and I had mentioned this), a shell (someone at hadoop summit mentioned this), and configuration (we started talking about dynamic configs lately) all on the ui then I think it could be worth it to go to a more modern and adopted framewor IMO we should keep the built-in pages simple, and expose all the right APIs so that an external "fancy" UI can be built. The fancier we make the built-in UI, the more likely we have bugs in it, and the less likely it'll be usable from command line browsers like lynx (yes, I do that reasonable often!). It also tends to result in cases where we have data that's only visible through the UI, which encourages people to start scraping HTML to gather metrics, etc. On the other hand, if everything's available via APIs, then we can have an external web UI with all the whiz-bang features we want. The external UI might be another daemon running in the HBase project. I think Accumulo takes basically this approach (theirs is called the "Monitor" process, and it talks to the actual daemons via thrift, as far as I understand)
        Hide
        Elliott Clark added a comment -

        @Todd
        That sounds good to me. I would actually love to move lots of the stuff that's currently there out. (compacting, splitting, and the metrics) Exposing json/thrift/protobuf endpoints and using them in a Monitor like process would allow others to use the endpoints for their own uses.

        Show
        Elliott Clark added a comment - @Todd That sounds good to me. I would actually love to move lots of the stuff that's currently there out. (compacting, splitting, and the metrics) Exposing json/thrift/protobuf endpoints and using them in a Monitor like process would allow others to use the endpoints for their own uses.
        Hide
        Todd Lipcon added a comment -

        That sounds good to me. I would actually love to move lots of the stuff that's currently there out. (compacting, splitting, and the metrics)

        I think it's useful to have a very basic "HTML 1.0" UI which is standardized and accessible without tools. But I agree that anything fancy should be done in a separate webapp.

        Show
        Todd Lipcon added a comment - That sounds good to me. I would actually love to move lots of the stuff that's currently there out. (compacting, splitting, and the metrics) I think it's useful to have a very basic "HTML 1.0" UI which is standardized and accessible without tools. But I agree that anything fancy should be done in a separate webapp.
        Hide
        stack added a comment -

        HBASE-1473 is an old issue that talks of moving UIs off daemons.

        Basic sounds good to me. Elliott, you've already fixed our horrid layout and you've made our basic look 'pretty' w/ bootstrap... (I haven't tried the bootstrapped pages in my command-line browser yet to see how it looks).

        Show
        stack added a comment - HBASE-1473 is an old issue that talks of moving UIs off daemons. Basic sounds good to me. Elliott, you've already fixed our horrid layout and you've made our basic look 'pretty' w/ bootstrap... (I haven't tried the bootstrapped pages in my command-line browser yet to see how it looks).
        Hide
        Elliott Clark added a comment -

        Just tried the new ui in lynx and everything looks pretty darn good. All of the metrics templates look good and are well aligned. I haven't ever really styled for text. If there was a way to hide the tab links that would be good.

        Show
        Elliott Clark added a comment - Just tried the new ui in lynx and everything looks pretty darn good. All of the metrics templates look good and are well aligned. I haven't ever really styled for text. If there was a way to hide the tab links that would be good.

          People

          • Assignee:
            Unassigned
            Reporter:
            Elliott Clark
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development