Mailing-List: contact common-issues-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: common-issues@hadoop.apache.org
Date: Thu, 18 Aug 2011 20:53:27 +0000 (UTC)
From: "Luke Lu (JIRA)" <jira@apache.org>
To: common-issues@hadoop.apache.org
Message-ID: 
 <416526920.50478.1313700807353.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <550363210.21720.1312925669268.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HADOOP-7532) Hadoop web UI 2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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