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@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@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@id", ".help-icon@src", "#breadcrumbs@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@redhat.com
<mailto:eric.wittmann@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@redhat.com
        <mailto:eric.wittmann@redhat.com>>
        To: "Lincoln Baxter" <lbaxter@redhat.com
        <mailto:lbaxter@redhat.com>>, jfuerth@redhat.com
        <mailto:jfuerth@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev