[errai-dev] Errai navigation + templating discussion

Christian Sadilek csadilek at redhat.com
Mon Jan 14 18:49:12 EST 2013


Hi,

I really like the simplicity of our current "template wins" strategy. I just tried the following which seems to work:

In the constructor of TransitionAnchor (or any other widget for that matter) you could add an AttachHandler and change the desired attribute(s):

MyWidget() {
   addAttachHandler(new Handler() {
    @Override
    public void onAttachOrDetach(AttachEvent event) {
      //change attributes
    }     
   });
}

e.g.

TransitionAnchor(Navigation navigation, final Class<P> toPage) {
   ...
   addAttachHandler(new Handler() {
    @Override
    public void onAttachOrDetach(AttachEvent event) {
      initHref(toPage);
    }     
   });
}

This causes the href attribute in the template to be overridden and should work right away without changes to the framework. Eric, I built a quick prototype which worked, but it needs more testing.

The advantage of this programmatic solution is that it's flexible and also becomes a widget-specific feature which won't add complexity to the framework (no additional annotations required). Of course, that argument only holds if we consider this requirement an edge case, which I think it is. If this is a more common scenario we could also add an @WidgetAttached annotation to get rid of the AttachHandler boilerplate or implement the suggested @TemplateOverride.

Cheers,
Christian

On 2013-01-14, at 4:43 PM, "Lincoln Baxter, III" <lincolnbaxter at gmail.com> wrote:

> Rest of the Errai team, what do you think?
> 
> 
> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> I'd be favor of some annotations to control this aspect of the templates.  I agree that care is needed, though.  :)
> 
> Certainly an @TemplateOverride annotation per widget can make sense. Perhaps the existing @Templated annotation can have an additional attribute?
> 
> Simple set of global attributes that should be widget-favored:
> 
>    @Templated(
>       value="artifacts.html#page",
>       attributeOverrides={"href", "id", "src"})
> 
> That will cause the href, id, and src attributes to be widget-favored rather than template-favored.
> 
> Or a more advanced possibility:
> 
> @Templated(value="artifacts.html#page", attributeOverrides={"@href", "button at id", ".help-icon at src", "#breadcrumbs at class"})
> 
> That will cause the following attributes to be widget-favored:
>   * All href attributes
>   * The id attribute on button elements
>   * The src attribute on any element with class=help-icon
>   * The class attribute on the element with id=breadcrumbs
> 
> Support could exist only for the spec:
> 
> <element>[.#]<classOrId>@<attribute>
> 
> -Eric
> 
> 
> On 01/11/2013 01:36 PM, Lincoln Baxter, III wrote:
> Maybe we need an @TemplateOverride annotation to alter this behavior?
> 
> It wouldn't be hard to do. Though... we may want the ability to do more
> global overrides as well... for instance, maybe you want all href
> attributes to default to the widget value instead.
> 
> Getting the experience of this right might be tricky.
> 
> Thoughts?
> 
> ---
> Lincoln Baxter's Droid
> http://ocpsoft.org
> "Keep it Simple"
> 
> On Jan 11, 2013 1:14 PM, "Eric Wittmann" <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>> wrote:
> 
>     No worries, Lincoln.  Good luck with the Forge stuff. :)
> 
>     As for the remaining attribute issue, I came up with an acceptable
>     workaround.  As I mentioned in the pull request, I want the live
>     preview/templates to be as functional as possible, including the
>     ability to navigate around the different pages (statically when that
>     makes sense - e.g. a primary nav bar).  So I want to have "href"
>     attributes that work in the templates.  At the same time, I want the
>     application to have the right value set on the href.
> 
>     Since the template code favors attributes in the template (and I
>     agree it almost always should!) I figured I had two options.  Either
>     modify the templating code to *sometimes* prefer widget attributes
>     over template attributes, or else find a way to remove the href
>     attributes from the template.
> 
>     I thought about a "data-exclude-attributes" attribute in the
>     template, but that didn't feel right.
> 
>     Instead, I simply removed all the hrefs from my template and
>     replaced them with a tiny bit of on-document-load javascript that
>     inserts them. This way, when the file is used as an Errai template,
>     there's no 'href' attribute to get in the way.  At the same time,
>     when viewed directly in the browser, the templates still appear to
>     have valid hrefs (because they get added by my little bit of JS code).
> 
>     Seems like a reasonable workaround, assuming there aren't too many
>     static links.  And I think in my applications there won't be too many.
> 
>     -Eric
> 
> 
>     On 01/11/2013 12:22 PM, Lincoln Baxter wrote:
> 
>         Hey Eric,
> 
>         Thanks for getting in touch!
> 
>         I'm sorry it took me so long to respond, I've been in fire
>         fighting mode trying to get Forge ready for our big team meeting.
> 
>         I've also copied my preferred email address and the errai-dev
>         list, which are two places that will probably get a faster
>         response from me, since I don't always have access to the VPN :)
> 
>         The issue has already been resolved, but I agree with all of
>         your changes. The attribute "whacking" can be problematic if you
>         actually want to go the "other way."
> 
>         Sorry again for the late reply. Feel free to email me personally
>         (at home) and copy the dev list for best results :)
> 
>         Thanks!
>         ~Lincoln
> 
>         ----- Original Message -----
>         From: "Eric Wittmann" <eric.wittmann at redhat.com
>         <mailto:eric.wittmann at redhat.com>>
>         To: "Lincoln Baxter" <lbaxter at redhat.com
>         <mailto:lbaxter at redhat.com>>, jfuerth at redhat.com
>         <mailto:jfuerth at redhat.com>
>         Sent: Wednesday, January 2, 2013 1:31:03 PM
>         Subject: Errai navigation + templating discussion
> 
>         Hey Lincoln.  I'm in the JBoss middleware group, specifically
>         working on
>         the Overlord project.  One of my responsibilities is producing a
>         couple
>         of UI applications.  To that end, I've been digging Errai and
>         hope to
>         contribute back based on my project needs.
> 
>         Ok, that's out of the way.  :)  I've been discussing a couple of
>         Errai 3
>         features with Jonathan (via github pull request comments :)).
>           One of
>         these is a new injectable Transition widget in errai-navigation.
>           You
>         can see the pull request here:
> 
>         https://github.com/errai/__errai/pull/27
> 
>         <https://github.com/errai/errai/pull/27>
> 
>         The goal was to really take out a lot of the boilerplate for the
>         simple
>         case of static hyperlinks from one @Page to another.
> 
>         I think it works well except for one small issue (documented in the
>         "What's Missing" section of the pull request).
> 
>         Jonathan mentioned that you might have some thoughts about the
>         templating issue, as it relates to attribute priority.
> 
>         Any thoughts?  I'd like the href to be preserved in this case
>         because I
>         would like the template's href to point to some local HTML file
>         while
>         the live application uses the proper history token as the href.
> 
>         Thanks!
> 
>         -Eric
> 
> 
> 
> 
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130114/5e3a22ef/attachment-0001.html 


More information about the errai-dev mailing list