[errai-dev] Errai navigation + templating discussion
Lincoln Baxter, III
lincolnbaxter at gmail.com
Mon Jan 14 20:02:19 EST 2013
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>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>
> 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>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
>>> "Keep it Simple"
>>>
>>> On Jan 11, 2013 1:14 PM, "Eric Wittmann" <eric.wittmann at redhat.com
>>> <mailto:eric.wittmann at redhat.**com <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 <eric.wittmann at redhat.com>>>
>>> To: "Lincoln Baxter" <lbaxter at redhat.com
>>> <mailto:lbaxter at redhat.com>>, 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
> "Simpler is better."
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
>
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130114/5ee1cddd/attachment.html
More information about the errai-dev
mailing list