[errai-dev] Errai navigation + templating discussion
Eric Wittmann
eric.wittmann at redhat.com
Tue Jan 15 07:28:21 EST 2013
+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 at redhat.com
> <mailto:csadilek at 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 at gmail.com <mailto:lincolnbaxter at 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 at redhat.com <mailto:eric.wittmann at 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 at id", ".help-icon at src",
>> "#breadcrumbs at 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 at redhat.com <mailto:eric.wittmann at redhat.com>
>> <mailto:eric.wittmann at redhat.__com
>> <mailto:eric.wittmann at 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 at redhat.com
>> <mailto:eric.wittmann at redhat.com>
>> <mailto:eric.wittmann at redhat.__com
>> <mailto:eric.wittmann at redhat.com>>>
>> To: "Lincoln Baxter" <lbaxter at redhat.com
>> <mailto:lbaxter at redhat.com>
>> <mailto:lbaxter at redhat.com
>> <mailto:lbaxter at redhat.com>>>, jfuerth at redhat.com
>> <mailto:jfuerth at redhat.com>
>> <mailto:jfuerth at redhat.com
>> <mailto:jfuerth at 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 at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org <mailto:errai-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>
More information about the errai-dev
mailing list