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>> 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