Thanks a lot for bringing this up, Sebastian! I watched the demo you showed last Friday and wanted to discuss about it. I think you have exposed the main downside we (RH) noticed about that approach: by using a separate template, changes in upstream templates might go unnoticed, and they would still require the same amount of effort to be merged. My suggestion would be, given we currently have (at least) 3 identified branding styles (community, SUSE's and Red Hat's), why not: - Exposing the pain points/gaps for the upstream to downstream flow. For example: at Red Hat we focused on 3 key elements: login screen, nav bar and about box. Login required a >90% replacement, while navigation and about-box were easier to adapt (<10%). Other branding tuning came (almost) for free as by using Bootstrap in upstream, Patterfly + RCUE (Red Hat Common User Experience) worked as a drop-in replacement. However, there were lots of elements left out of the branding (breadcrumbs, favicon, charts, cards, error pages, table elements, toast notifications, ...), since they provided minimal gains vs. effort required. - Providing in the upstream templates the required placeholders/hooks for the identified needs. - Using Angular environment files to fill those placeholders/hooks with downstream-specific stuff. Let me know your views on that or if that's something already explored/discarded. Kind regards, Ernesto On Tue, Dec 11, 2018 at 12:17 PM Lenz Grimmer <lgrimmer@xxxxxxxx> wrote: > > Hi Sebastian, > > thanks for the summary! > > On 12/10/18 8:21 AM, Sebastian Krah wrote: > > > Patrick, Kanika and I had a follow up discussion about how to implement > > branding in Ceph Dashboard > > > > Conclusion: > > We decided to create a folder name "vendor" in the ceph-dashboards root > > directory, where we can place all modified templates. The name of the > > modified template must be the same as the name of the original one. This is > > crucial, because we would execute a script during our build process which > > would either replace the original template with the branded one or change > > the path to the modified template inside the TypeScript file. If the vendor > > folder is empty, the script wouldn't do anything. > > The advantage of this approach is that we will be able to avoid merge > > conflicts when the upstream template is changed. A disadvantage is that if a > > component is changed upstream we might forget to add those changes to the > > modified downstream template. This could result in missing new > > functionalities or, even worse, in errors (e.g. when variable names > > changes). > > > > The script could also replace whole components and add or remove logic from > > upstream, if this would be necessary in the future. > > > > I'll continue working on this and add such a script to our building routine. > > Quick update about this topic: during today's standup we discussed the > actual implementation and concluded that it would be a better approach > to place the modified templates into their respective directories, using > a special file name extension to mark them. This way, there is no need > to have a mapping/configuration file but would rather use the plain > existence of such a customized file as the trigger for replacing the > original during the UI build process. > > Lenz > > -- > SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany) > GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg) >
