+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]>> 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]>> 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]>> 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:eric.wittmann@redhat.__com >> <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:eric.wittmann@redhat.__com >> <mailto:[email protected]>>> >> To: "Lincoln Baxter" <[email protected] >> <mailto:[email protected]> >> <mailto:[email protected] >> <mailto:[email protected]>>>, [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]> >> 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
