When you import another component in your app as a dependency, your app and that dependency agree to use the same theme as your app (theme is defined in the app level, not in the component level). Which means that there is a *contract* between the theme, app, and dependency component(s). So setting a new "errorPageLayout" layout won't break that contract because the new "errorPageLayout" layout also agrees with the theme. Lets assume that app dev can override the layout of a page in a dependency component; that new layout should agree to the same *contract*. Which means all the pages, layouts, fragments, dependency components should agree to work with the theme. There is no way to escape that (at least in the currenct architecture)
IMO, forcefully overriding the layout of a page (in a dependency component) is a bag practice. The developer of that page didn't intended to change its layout. Its like changing a private variable's value via reflection. Dev of the page should add the necessary extension points in to the page (other UUF elements follows this way e.g. fragment params, defining zones in the page etc.). On Mon, Jan 23, 2017 at 8:27 PM, Manuranga Perera <[email protected]> wrote: > (When I say "default theme" I mean "foundation" component obviously.) > > When you put make the default theme understand to errorPageLayout you are > changing the *contract* of the theme, that means users (like Danushka) > has to know that, ether by reading the code/doc. > > I think this is a much bigger issue, we are just seeing the first instance > of it. Whenever you try to use a page developed by a different team, your > UI doesn't match because the layout is different. Ideal solution is to app > to be able to override the imported page's layout. Need to think about this > in detail. > >> -- Sajith Janaprasad Ariyarathna Software Engineer; WSO2, Inc.; http://wso2.com/ <https://wso2.com/signature>
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
