I will modify the implementation to use an attach handler to set the href. I believe there is already a test case, which I will modify to test for the proper href.
-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]>> 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]>>> 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]>>> > 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]>>> > 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: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: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]>>>>, [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]>> > >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > > > > _______________________________________________ > > errai-dev mailing list > > [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]> > 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] https://lists.jboss.org/mailman/listinfo/errai-dev
