Worked like a charm, thanks for the assist. Took me awhile to get back to, but the changes are done and in a pull request:
https://github.com/errai/errai/pull/35 -Eric On 01/15/2013 01:26 PM, Christian Sadilek wrote: > 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 <[email protected] > <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected]>> 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 >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> 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" >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> wrote: >>>> >>>>> Rest of the Errai team, what do you think? >>>>> >>>>> >>>>> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann >>>>> <[email protected] <mailto:[email protected]> >>>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>>> >>> 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 <http://ocpsoft.org/> >>>>> "Keep it Simple" >>>>> >>>>> On Jan 11, 2013 1:14 PM, "Eric Wittmann" >>>>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>> <mailto:eric.wittmann@redhat. >>> <mailto:eric.wittmann@redhat.>__com >>>>> <mailto:[email protected] >>> <mailto:[email protected]>>>> 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" >>> <[email protected] <mailto:[email protected]> >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>> >>>>> <mailto:eric.wittmann@redhat. >>> <mailto:eric.wittmann@redhat.>__com >>>>> <mailto:[email protected] >>> <mailto:[email protected]>>>> >>>>> To: "Lincoln Baxter" <[email protected] >>>>> <mailto:[email protected]> >>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>> <mailto:[email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] >>> <mailto:[email protected]>>>>, [email protected] >>> <mailto:[email protected]> >>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>> <mailto:[email protected] >>> <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>> 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 >>>>> [email protected] <mailto:[email protected]> >>>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Lincoln Baxter, III >>>> http://ocpsoft.org >>>> "Simpler is better." >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>> _______________________________________________ >>> errai-dev mailing list >>> [email protected] <mailto:[email protected]> >>> <mailto:[email protected]> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> >>> >>> -- >>> Lincoln Baxter, III >>> http://ocpsoft.org >>> "Simpler is better." >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > > _______________________________________________ > errai-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/errai-dev
