Re: [errai-dev] Errai navigation + templating discussion

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(a)redhat.com <mailto:eric.wittmann@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(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@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(a)redhat.com <mailto:csadilek@redhat.com> >> <mailto:csadilek@redhat.com> >>> <mailto:csadilek@redhat.com <mailto:csadilek@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(a)gmail.com <mailto:lincolnbaxter@gmail.com> >>> <mailto:lincolnbaxter@gmail.com> >> <mailto:lincolnbaxter@gmail.com <mailto: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(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>> <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com <mailto: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 <http://ocpsoft.org/> >>>> "Keep it Simple" >>>> >>>> On Jan 11, 2013 1:14 PM, "Eric Wittmann" >>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>> >>>> <mailto:eric.wittmann@redhat. >> <mailto:eric.wittmann@redhat.>__com >>>> <mailto: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(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com> >>>> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>> >>>> <mailto:eric.wittmann@redhat. >> <mailto:eric.wittmann@redhat.>__com >>>> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>>>> >>>> To: "Lincoln Baxter" <lbaxter(a)redhat.com >>>> <mailto:lbaxter@redhat.com> >> <mailto:lbaxter@redhat.com> >>>> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>> >>>> <mailto:lbaxter@redhat.com >> <mailto:lbaxter@redhat.com> >>>> <mailto:lbaxter@redhat.com >> <mailto:lbaxter@redhat.com>>>>, jfuerth(a)redhat.com >> <mailto:jfuerth@redhat.com> >> <mailto:jfuerth@redhat.com> >>>> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>> >>>> <mailto:jfuerth@redhat.com >> <mailto:jfuerth@redhat.com> >>>> <mailto: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> >>>> >>>> <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(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@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(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/errai-dev >> > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/errai-dev _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev