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> 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>> 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
>
_______________________________________________
errai-dev mailing list
errai-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev