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]>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]> > wrote: > > Rest of the Errai team, what do you think? > > > On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann > <[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 >>> "Keep it Simple" >>> >>> On Jan 11, 2013 1:14 PM, "Eric Wittmann" <[email protected] >>> <mailto:eric.wittmann@redhat.**com <[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:eric.wittmann@redhat.**com <[email protected]>>> >>> To: "Lincoln Baxter" <[email protected] >>> <mailto:[email protected]>>, [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 > "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 > > -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better."
_______________________________________________ errai-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/errai-dev
