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
