Thanks Eric! On 2013-01-22, at 9:37 AM, Eric Wittmann <[email protected]> wrote:
> 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 _______________________________________________ errai-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/errai-dev
