[
https://issues.apache.org/jira/browse/HADOOP-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086675#comment-13086675
]
Luke Lu commented on HADOOP-7532:
---------------------------------
bq. 1. HTML4 strict compliance.
The two O in the DTD, means that they're optional (for both start and end tags
:) Omitting HEAD/BODY in the existing code is intentional as this makes
composing valid html much easier. I can give you detailed examples if this is
not clear enough. Please report any invalid html the framework produces. I'm
already aware of a few cases (missing alt attribute in img etc.) but this is
not one of them.
bq. 2. JavaScript (JQuery) code not being part of the model.
I guess the "model" you're talking about is the composeable blocks, as "model"
in a mvc framework has very different meanings, which is not relevant for this
particular discussion. One goal of the framework is progressive enhancement.
The separation of js and doc structure is intentional. Javascript is mostly
kept in init sections of views. OTOH, I can totally understand where you're
coming from. The current simplistic but flexible implementation makes certain
view/page methods (init methods) coupled with block implementations on the html
ids of the blocks. I personally don't find it particular difficult to override
various init methods (commonPreHead etc.) to customize different views. Keep in
mind, we need to have the choice to have different initialization (active tab
etc.) of the same block for different views based on the query. The current way
is less than ideal and I have some ideas to make it better. I welcome
suggestions to make it even easier.
bq. 3. Common widgets.
You're totally right. I actually have a table builder in the plan to abstract
much of the cruft (mostly for adaptive server-side rendering for huge tables)
away from the blocks. OTOH, the current pattern is actually quite
straightforward: write the doc structure in the blocks and write the
corresponding js init code in views.
bq. 4. InfoBlock in JobBlock.
Yes, info block is a bit of a hack. The initial use case of the info block is a
common about/attribute block for all the webapps. I usually put the
construction of ResponseInfo in controller, so that I don't have change views
at all. The JobBlock is a special case to reuse the logic. I admit that it's
not very intuitive.
Thanks for all the points raised here, Bobby. The main goal of the framework
itself is making such improvement/refactor transparent, type safe and
(relatively) straightforward (as it's pure java without all the arcane (and
still unsafe) DSLs in existing frameworks). IMO, the fact you refactored
jobhistory server quickly without asking any questions is a testament of the
ease of use of the framework :) Again, I welcome suggestions to make it better.
> 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
