[errai-dev] Errai navigation + templating discussion

Christian Sadilek csadilek at redhat.com
Tue Jan 15 13:26:49 EST 2013


Hi Eric,

Yes, it will work if you add an EntryPoint to the tests e.g.

@EntryPoint
public class NavigationTestEntryPoint {

  @Inject RootPanel root;
  
  @Inject PageWithTransitionAnchor anchor;
  
  @PostConstruct
  public void foo() {
    root.add(anchor);
  }
}

Also make sure that in your PageTransitionAnchor which extends SimplePanel you add the anchor to the panel:

@Dependent
@Page
public class PageWithTransitionAnchor extends SimplePanel {

  @Inject
  public TransitionAnchor<PageB> linkToB;
  
  @PostConstruct
  public void foo() {
    this.add(linkToB);
  }
}

Now everything is wired up and should be rendered. The event fires for me.

Cheers,
Christian


On 2013-01-15, at 12:49 PM, Eric Wittmann <eric.wittmann at redhat.com> wrote:

> Darn - anyone have any thoughts regarding how AttachEvents get fired in 
> the test environment?  I tried modifying the existing 
> TransitionAnchorTest to see if I would get AttachEvents but it seems I 
> do not.
> 
> I'll poke around some more.
> 
> -Eric
> 
> On 01/15/2013 11:20 AM, Lincoln Baxter, III wrote:
>> Sweet! We should add this to the Errai UI docs! Anyone have an example
>> of the code (And or a test case?)
>> 
>> 
>> On Tue, Jan 15, 2013 at 7:28 AM, Eric Wittmann <eric.wittmann at redhat.com
>> <mailto:eric.wittmann at redhat.com>> wrote:
>> 
>>    +1 for AttachHandler!
>> 
>>    When I impl'd the TransitionAnchor I tried @PostConstruct to do just
>>    what you described, but obviously that didn't work.  I didn't realize
>>    there was an attach handler capability.
>> 
>>    -Eric
>> 
>>    On 01/14/2013 08:02 PM, Lincoln Baxter, III wrote:
>>> Hmm, yes. I think I like the idea of using the AttachHandler as well.
>>> It's a bit cleaner and simpler. (From a framework perspective.)
>>> 
>>> 
>>> On Mon, Jan 14, 2013 at 6:49 PM, Christian Sadilek
>>    <csadilek at redhat.com <mailto:csadilek at redhat.com>
>>> <mailto:csadilek at redhat.com <mailto:csadilek at redhat.com>>> wrote:
>>> 
>>>    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 <mailto:lincolnbaxter at gmail.com>
>>    <mailto:lincolnbaxter at gmail.com <mailto: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 <mailto:eric.wittmann at redhat.com>
>>    <mailto:eric.wittmann at redhat.com <mailto: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 <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> <mailto:eric.wittmann at redhat.com
>>    <mailto:eric.wittmann at redhat.com>>
>>>>            <mailto:eric.wittmann at redhat.
>>    <mailto:eric.wittmann at redhat.>__com
>>>>            <mailto: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>
>>>>            <mailto:eric.wittmann at redhat.com
>>    <mailto:eric.wittmann at redhat.com>>
>>>>                    <mailto:eric.wittmann at redhat.
>>    <mailto:eric.wittmann at redhat.>__com
>>>>            <mailto:eric.wittmann at redhat.com
>>    <mailto:eric.wittmann at redhat.com>>>>
>>>>                    To: "Lincoln Baxter" <lbaxter at redhat.com
>>    <mailto:lbaxter at redhat.com>
>>>>            <mailto:lbaxter at redhat.com <mailto:lbaxter at redhat.com>>
>>>>                    <mailto:lbaxter at redhat.com
>>    <mailto:lbaxter at redhat.com>
>>>>            <mailto:lbaxter at redhat.com
>>    <mailto:lbaxter at redhat.com>>>>, jfuerth at redhat.com
>>    <mailto:jfuerth at redhat.com>
>>>>            <mailto:jfuerth at redhat.com <mailto:jfuerth at redhat.com>>
>>>>                    <mailto:jfuerth at redhat.com
>>    <mailto:jfuerth at redhat.com>
>>>>            <mailto: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>
>>>> 
>>>>                    <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 <http://ocpsoft.org/>
>>>>    "Simpler is better."
>>>>    _______________________________________________
>>>>    errai-dev mailing list
>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>    <mailto:errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>>
>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>> 
>>> 
>>>    _______________________________________________
>>>    errai-dev mailing list
>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>    <mailto:errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>>
>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>> 
>>> 
>>> 
>>> 
>>> --
>>> Lincoln Baxter, III
>>> http://ocpsoft.org
>>> "Simpler is better."
>>> 
>>> 
>>> _______________________________________________
>>> errai-dev mailing list
>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>> 
>>    _______________________________________________
>>    errai-dev mailing list
>>    errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>    https://lists.jboss.org/mailman/listinfo/errai-dev
>> 
>> 
>> 
>> 
>> --
>> 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
>> 
> _______________________________________________
> 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/20130115/06690328/attachment-0001.html 


More information about the errai-dev mailing list