5 Replies Latest reply on Apr 19, 2016 11:49 AM by mbarkley

    Disappearing nested templates in 4 beta

    christian.bauer

      I'm trying this example in 4 beta:

       

      Errai Reference Guide

       

      It seems you'll have a different result (and various "no data field or id or class found" errors) depending on the visibility of fields in the super and subclasses when you have parent/child nesting of template components. Are there any rules that could be documented?

       

      Thanks,

      Christian

       

      Edit: Attached a video of the problem and the source code ZIP

        • 1. Re: Document visibility rules of nested templates
          christian.bauer

          Also, components in templates seem to disappear from the page when you navigate between #fragments, see the attached video. The message (should this be ERROR level) in the JS console is:

           

          Current content widget vanished or changed. Not delivering pageHiding event to FooViewImpl.

          • 2. Re: Disappearing nested templates in 4 beta
            mbarkley

            Hi Christian,

             

            The rules for inheriting @DataFields are the same regardless of the visibility of the field. A @Templated bean inherits all @DataFields from it's superclasses. If any of @DataFields in a superclass do not have a data-field in the html template of the subclass, you should see an error. If you see any behaviour deviating from this, I encourage you to report it as a bug.

             

            After watching your video I checked out your code and the disappearing header is unrelated to inheritance. The problem is that the relevant three types, FooViewImpl, BarViewImpl, and Header, are all singletons. When the first page, FooViewImpl, Errai UI attaches the Header to this bean. When you click the button to navigate to BarViewImpl it is lazily loaded for the first time, and Errai UI attaches the header to it. But because there is only a single Header instance, attaching it to BarViewImpl removes it from FooViewImpl. You can make your sample code work by either making the Header dependent (so that foo and bar get their own headers) or by making both FooViewImpl and BarViewImpl depenent (so that a new instance is created each time so that the header is reattached whenever the page is loaded).

             

            Cheers.

            • 3. Re: Disappearing nested templates in 4 beta
              christian.bauer

              Thanks Max, I guess I should have removed more annotations to narrow the problem down.

               

              Documented template singleton life cycle by christianbauer · Pull Request #167 · errai/errai · GitHub

              • 4. Re: Document visibility rules of nested templates
                christian.bauer

                My next question after playing with the HTML templating for a while would be how I can share @Singleton view components in my application layout. If every page has dependent header/footer etc. components then those need to be initialized completely every time I navigate.

                 

                Also, I see this kind of warning message all the time, I think this is something fairly normal to do:

                 

                10:59:24 WARNING [TemplateUtil] WARNING: Replacing Element type [DIV] with type [PAPER-BUTTON] ErraiConsoleLogHandler.java:79

                • 5. Re: Document visibility rules of nested templates
                  mbarkley
                  If every page has dependent header/footer etc. components then those need to be initialized completely every time I navigate.

                  My general advice is don't make any UI components singleton unless there is something really expensive happening when initialized, and even then try and refactor so that the expensive operation is not part of the UI component. For example if some network trip is required (like an RPC) when a component is initialized, pull that out into a separate service with a cache. Most of the time this will have negligible impact on performance.

                  Or if you want the header and footer to literally be on every page, you could just manually add them to the host page around the navigation panel instead of having them be in your @Pages. Here is an example of adding a navigation bar above the nav panel.

                  Also, I see this kind of warning message all the time, I think this is something fairly normal to do:

                   

                  10:59:24 WARNING [TemplateUtil] WARNING: Replacing Element type [DIV] with type [PAPER-BUTTON] ErraiConsoleLogHandler.java:79

                  We print these warnings whenever an element in a template is overridden by a @DataField with a different element name to help users diagnose problems where there template renders unexpectedly in the compiled application.