hadoop-common-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Luke Lu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HADOOP-7532) Hadoop web UI 2.0
Date Thu, 18 Aug 2011 20:53:27 GMT

    [ https://issues.apache.org/jira/browse/HADOOP-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087279#comment-13087279
] 

Luke Lu commented on HADOOP-7532:
---------------------------------

bq. I do have to say that starting out with Hamlet was confusing for me.

I guess the confusion is mostly from the composition of the existing webapps rather than the
framework? Since you don't have to learn any new syntax (like wtf is <%& etc. in a
template system), the context sensitive help/hints will make you productive without consulting
any separate documentation. I bet that once you get the system, you can come back couple months
later (after working on non-UI projects) and be immediately productive without reading any
documentation. Same thing can't be said for any template systems which has their own particular
syntax.

bq. I do not see how forcing all java script on the page to go through the top level view
improves progressive enhancement.

I didn't say that. Progressive enhancement is a goal and the existing implementation is an
easy but obviously not the best way to do it. I can see the desire to improve the composability
of blocks/views, without having to do any subclassing and overriding, which is relatively
heavy in boilerplate code in Java.

I don't oppose ideas to include some init logic per block defintion, which gets called when
being rendered. How about something like this:

{code}
render(TwoColumnLayout.builder().
       withNav(MyNavBlock.builder().active(1)).
       withContent(MyContentBlock.class));
{code}

Which basically enhance the render API to also accept a ViewBuilder interface to do delayed
rendering.

bq. I thought that using table to do layout was an HTML anti-pattern.

I knew the question would eventually come up :) I preserved TwoColumnCssLayout in the source.
Read it with the comments and compare it with TwoColumnLayout for specific reasons why CSS
is bad for this particular but simple layout I want. I think the current generations of CSS
is bad for UI (vs content) layout in general (most css layout is fixed grid based and cannot
handle dynamic containees correctly) and tables is just a last resort.

If anyone can solve the problem cleanly, it's easy to rename the layout class in the library
without changing webapps code (the same can't be said for most existing framework like rails
and play etc which generates layout per webapp).

> Hadoop web UI 2.0
> -----------------
>
>                 Key: HADOOP-7532
>                 URL: https://issues.apache.org/jira/browse/HADOOP-7532
>             Project: Hadoop Common
>          Issue Type: Improvement
>    Affects Versions: 0.23.0
>            Reporter: Luke Lu
>            Assignee: Luke Lu
>             Fix For: 0.23.0
>
>
> People have expressed interests of bringing Hadoop web UI up to date with the lightweight
embedded web mvc framework used in MAPREDUCE-279 (cf. MAPREDUCE-2399). This is the umbrella
jira for UI improvement for 0.23+. Individual items like web framework refactor/move and the
unique challenge for MR2 webapp security will be filed separately.
> Thoughts/ideas on various improvement of Hadoop web UI are welcome here. Some of the
ideas will naturally become sub-issues.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message