[
https://issues.apache.org/jira/browse/HADOOP-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13087297#comment-13087297
]
Aaron T. Myers commented on HADOOP-7532:
----------------------------------------
bq. It's secure (always escape content (including attributes) unless you resort
to use raw response writer
Certainly many (if not most) templating frameworks (Jamon, Mako, etc) do this.
Nothing novel there.
bq. IDE/refactor friendly (pure java, live html help/hints without plugins);
While that's certainly true about Hamlet, I question whether or not that's a
goal which warrants writing/maintaining a brand-new templating framework.
bq. Statically validates html (you can still generate bad html if you really
try but you can generate valid html much easier).
Certainly there exist templating frameworks which can do this, or at least we
could wire in one of the many HTML validators out there to do this when running
the tests. This is what I've done in previous web projects with great success.
Again, this feature doesn't seem to warrant writing/maintaining a brand new
templating system.
bq. Since you don't have to learn any new syntax (like wtf is <%& etc. in a
template system)
You don't have to learn a new syntax per se, but you do have to learn a new
(and IMO arcane) Java library. Like for example, what's with the "$style"
method? or the many calls to "_()" all over the code? These were questions I
had when first looking at the code which uses Hamlet, and I'm guessing Bobby
had the same sort of questions. By using Hamlet, we're cutting off those
developers who *do* have some experience with existing templating systems in
favor of a new system which literally no one has experience with. As someone
who's used several templating systems in other projects before, I can say with
confidence that being required to use Hamlet will make me less productive than
a traditional templating system would.
I don't want to keep harping on this, as I don't feel super strongly about it,
but it still seems like a mistake to me to be introducing a novel web
templating framework into Hadoop. The Hadoop project, IMO, shouldn't be in the
business of web templating. Rather, the Hadoop daemons just have a few web
pages they would like to display. Why should we re-invent this wheel which has
already been invented many times before? If I'm the only one who feels this
way, then I'll shut up about it.
I know HBase uses Jamon for rendering its web pages. Perhaps someone with
experience developing those can comment?
> 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
