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" <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.**com <eric.wittmann(a)redhat.com&gt;&gt;&gt; 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" <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.**com <eric.wittmann(a)redhat.com&gt;&gt;&gt; > To: "Lincoln Baxter" <lbaxter(a)redhat.com > <mailto:lbaxter@redhat.com>>, jfuerth(a)redhat.com > <mailto:jfuerth@redhat.com> > 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/__... > > <https://github.com/errai/**errai/pull/27<https://github.com/errai/erra... > > > > 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 > >

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" <lincolnbaxter(a)gmail.com&gt; wrote: Rest of the Errai team, what do you think? On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann <eric.wittmann(a)redhat.com&gt;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" <eric.wittmann(a)redhat.com >> <mailto:eric.wittmann@redhat.**com <eric.wittmann(a)redhat.com&gt;&gt;&gt; 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" <eric.wittmann(a)redhat.com >> <mailto:eric.wittmann@redhat.**com <eric.wittmann(a)redhat.com&gt;&gt;&gt; >> To: "Lincoln Baxter" <lbaxter(a)redhat.com >> <mailto:lbaxter@redhat.com>>, jfuerth(a)redhat.com >> <mailto:jfuerth@redhat.com> >> 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/__... >> >> <https://github.com/errai/**errai/pull/27<https://github.com/errai/erra... >> > >> >> 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 errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

+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 <csadilek(a)redhat.com > <mailto:csadilek@redhat.com>> 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" > <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com>> wrote: > >> Rest of the Errai team, what do you think? >> >> >> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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" >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.__com >> <mailto:eric.wittmann@redhat.com>>> 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" <eric.wittmann(a)redhat.com >> <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.__com >> <mailto:eric.wittmann@redhat.com>>> >> To: "Lincoln Baxter" <lbaxter(a)redhat.com >> <mailto:lbaxter@redhat.com> >> <mailto:lbaxter@redhat.com >> <mailto:lbaxter@redhat.com>>>, jfuerth(a)redhat.com >> <mailto:jfuerth@redhat.com> >> <mailto:jfuerth@redhat.com >> <mailto:jfuerth@redhat.com>> >> 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 >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/errai-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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 <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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 <csadilek(a)redhat.com <mailto:csadilek@redhat.com> > <mailto:csadilek@redhat.com <mailto:csadilek@redhat.com>>> 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" > <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com> <mailto:lincolnbaxter@gmail.com <mailto:lincolnbaxter@gmail.com>>> wrote: > >> Rest of the Errai team, what do you think? >> >> >> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>> 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" >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>> >> <mailto:eric.wittmann@redhat. <mailto:eric.wittmann@redhat.>__com >> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>>> 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" <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>> >> <mailto:eric.wittmann@redhat. <mailto:eric.wittmann@redhat.>__com >> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>>> >> To: "Lincoln Baxter" <lbaxter(a)redhat.com <mailto:lbaxter@redhat.com> >> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>> >> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com> >> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>>>>, jfuerth(a)redhat.com <mailto:jfuerth@redhat.com> >> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>> >> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com> >> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>>> >> 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 >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> > https://lists.jboss.org/mailman/listinfo/errai-dev > > > > > -- > Lincoln Baxter, III > http://ocpsoft.org > "Simpler is better." > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/errai-dev -- Lincoln Baxter, III http://ocpsoft.org "Simpler is better." _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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 <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com>> 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 >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com>> 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 >> <csadilek(a)redhat.com <mailto:csadilek@redhat.com> >> <mailto:csadilek@redhat.com> >>> <mailto:csadilek@redhat.com <mailto:csadilek@redhat.com>>> 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" >>> <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com> >>> <mailto:lincolnbaxter@gmail.com> >> <mailto:lincolnbaxter@gmail.com <mailto:lincolnbaxter@gmail.com>>> >> wrote: >>> >>>> Rest of the Errai team, what do you think? >>>> >>>> >>>> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann >>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>> <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>> >> 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" >>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>> >>>> <mailto:eric.wittmann@redhat. >> <mailto:eric.wittmann@redhat.>__com >>>> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>>>> 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" >> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >> <mailto:eric.wittmann@redhat.com> >>>> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>> >>>> <mailto:eric.wittmann@redhat. >> <mailto:eric.wittmann@redhat.>__com >>>> <mailto:eric.wittmann@redhat.com >> <mailto:eric.wittmann@redhat.com>>>> >>>> To: "Lincoln Baxter" <lbaxter(a)redhat.com >>>> <mailto:lbaxter@redhat.com> >> <mailto:lbaxter@redhat.com> >>>> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>> >>>> <mailto:lbaxter@redhat.com >> <mailto:lbaxter@redhat.com> >>>> <mailto:lbaxter@redhat.com >> <mailto:lbaxter@redhat.com>>>>, jfuerth(a)redhat.com >> <mailto:jfuerth@redhat.com> >> <mailto:jfuerth@redhat.com> >>>> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>> >>>> <mailto:jfuerth@redhat.com >> <mailto:jfuerth@redhat.com> >>>> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>>> >>>> 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 >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> >>> >>> -- >>> Lincoln Baxter, III >>> http://ocpsoft.org >>> "Simpler is better." >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> <mailto:errai-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/errai-dev >> >> >> >> >> -- >> Lincoln Baxter, III >> http://ocpsoft.org >> "Simpler is better." >> >> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/errai-dev >> > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/errai-dev _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

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 <eric.wittmann(a)redhat.com > <mailto:eric.wittmann@redhat.com>> 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 >>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>> <mailto:eric.wittmann@redhat.com>> 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 >>> <csadilek(a)redhat.com <mailto:csadilek@redhat.com> >>> <mailto:csadilek@redhat.com> >>>> <mailto:csadilek@redhat.com <mailto:csadilek@redhat.com>>> 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" >>>> <lincolnbaxter(a)gmail.com <mailto:lincolnbaxter@gmail.com> >>>> <mailto:lincolnbaxter@gmail.com> >>> <mailto:lincolnbaxter@gmail.com <mailto:lincolnbaxter@gmail.com>>> >>> wrote: >>>> >>>>> Rest of the Errai team, what do you think? >>>>> >>>>> >>>>> On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann >>>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>>>> <mailto:eric.wittmann@redhat.com> >>> <mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>> >>> 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" >>>>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>> <mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com >>> <mailto:eric.wittmann@redhat.com>> >>>>> <mailto:eric.wittmann@redhat. >>> <mailto:eric.wittmann@redhat.>__com >>>>> <mailto:eric.wittmann@redhat.com >>> <mailto:eric.wittmann@redhat.com>>>> 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" >>> <eric.wittmann(a)redhat.com <mailto:eric.wittmann@redhat.com> >>> <mailto:eric.wittmann@redhat.com> >>>>> <mailto:eric.wittmann@redhat.com >>> <mailto:eric.wittmann@redhat.com>> >>>>> <mailto:eric.wittmann@redhat. >>> <mailto:eric.wittmann@redhat.>__com >>>>> <mailto:eric.wittmann@redhat.com >>> <mailto:eric.wittmann@redhat.com>>>> >>>>> To: "Lincoln Baxter" <lbaxter(a)redhat.com >>>>> <mailto:lbaxter@redhat.com> >>> <mailto:lbaxter@redhat.com> >>>>> <mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>> >>>>> <mailto:lbaxter@redhat.com >>> <mailto:lbaxter@redhat.com> >>>>> <mailto:lbaxter@redhat.com >>> <mailto:lbaxter@redhat.com>>>>, jfuerth(a)redhat.com >>> <mailto:jfuerth@redhat.com> >>> <mailto:jfuerth@redhat.com> >>>>> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>> >>>>> <mailto:jfuerth@redhat.com >>> <mailto:jfuerth@redhat.com> >>>>> <mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>>> >>>>> 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 >>>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>>> <mailto:errai-dev@lists.jboss.org> >>> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >>>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> <mailto:errai-dev@lists.jboss.org> >>> <mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Lincoln Baxter, III >>>> http://ocpsoft.org >>>> "Simpler is better." >>>> >>>> >>>> _______________________________________________ >>>> errai-dev mailing list >>>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>>> https://lists.jboss.org/mailman/listinfo/errai-dev >>>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >>> <mailto:errai-dev@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >>> >>> >>> >>> -- >>> Lincoln Baxter, III >>> http://ocpsoft.org >>> "Simpler is better." >>> >>> >>> _______________________________________________ >>> errai-dev mailing list >>> errai-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/errai-dev >>> >> _______________________________________________ >> errai-dev mailing list >> errai-dev(a)lists.jboss.org <mailto:errai-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/errai-dev > > > > _______________________________________________ > errai-dev mailing list > errai-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/errai-dev > _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev

On 2013-01-14, at 6:49 PM, Christian Sadilek wrote: > 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. I agree as well. I'd only add that if we find out later that this *is* a common requirement, I'd prefer the declarative approach (either @TemplateOverride or a new attribute in @Templated) over the simplified-but-still-programmatic approach of @WidgetAttached methods. -Jonathan _______________________________________________ errai-dev mailing list errai-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/errai-dev