Initial WebUI for DOM Distiller.

components/dom_distiller/webui/DEPS

 include_rules = [
+  "+components/dom_distiller/webui",
   "+content/public/browser",

[Jói, 2013/09/09 08:29:58]

Since this folder depends on content, should it be under
//components/dom_distiller/content/webui?

[nyquist, 2013/09/10 01:56:53]

Added a more thorough explanation after talking to stuartmorgan@. I am fine
either way regarding a strict per-header-file approach or a full inclusion of
content/public/browser. Stuart argued that iOS tries to not be a nuisance to
engineers doing refactorings, and therefore wants to err on the side of allowing
more things.

[Jói, 2013/09/10 07:23:40]

I'm not sure I understand. Does this mean the C++ code in the directory right
now will not be used on iOS, only the HTML/JS code? If that's the case then I
would leave the HTML/JS code here and move the C++ code to
//components/dom_distiller/content/browser/webui.

[nyquist, 2013/09/10 07:51:11]

No, right now, the plan is to use //components/dom_distiller/webui on all
platforms, including iOS. That goes for both HTML/JS/CSS resources and the C++
code.

However, since the point of the //components/dom_distiller/content/ folder is
that it is supposed to be only used by non-iOS platforms, and we want the webui
to work on iOS, we put it in a directory "on the side" of the other top level
directories in the component.

When more of this feature lands, the main code will live in
//components/dom_distiller/core and there will be a content-version of whatever
is needed from content in //components/dom_distiller/content. And then when we
implements support for iOS, that code will live in
//components/dom_distiller/ios.

However, since WebUI lives in content, but it still supported on iOS, it does
not fit the normal folder structure of a layered component, so after discussing
with stuartmorgan@ we concluded that putting it in a separate folder was the
right thing to do.

On 2013/09/10 07:23:40, Jói wrote:

-  "+ui/base",
-]
+]