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@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.<csadilek@redhat.com <mailto:csadilek@redhat.com>
It's a bit cleaner and simpler. (From a framework perspective.)
On Mon, Jan 14, 2013 at 6:49 PM, Christian Sadilek<mailto:csadilek@redhat.com <mailto:csadilek@redhat.com>>> wrote:for that
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 widgetmatter) you could add an AttachHandler and change the desiredoverridden and
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 beshould work right away without changes to the framework. Eric, Irequired). Of
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 annotationscourse, that argument only holds if we consider thisrequirement anedge case, which I think it is. If this is a more commonscenario wecould also add an @WidgetAttached annotation to get rid of the@TemplateOverride.
AttachHandler boilerplate or implement the suggested<mailto:lincolnbaxter@gmail.com <mailto:lincolnbaxter@gmail.com>>>
Cheers,
Christian
On 2013-01-14, at 4:43 PM, "Lincoln Baxter, III"
<lincolnbaxter@gmail.com <mailto:lincolnbaxter@gmail.com>
wrote:<mailto:eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>>>Rest of the Errai team, what do you think?
On Fri, Jan 11, 2013 at 2:08 PM, Eric Wittmann
<eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>
wrote:of the
I'd be favor of some annotations to control this aspectmaketemplates. I agree that care is needed, though. :)
Certainly an @TemplateOverride annotation per widget canhave ansense. Perhaps the existing @Templated annotation canwidget-favored:additional attribute?
Simple set of global attributes that should bewidget-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<mailto:eric.wittmann@redhat.com> <mailto:eric.wittmann@redhat.com* 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@redhat.com
<mailto:eric.wittmann@redhat.com>><mailto:eric.wittmann@redhat.>__com<mailto:eric.wittmann@redhat.<mailto:eric.wittmann@redhat.com>>>> wrote:<mailto:eric.wittmann@redhat.comstuff. :)
No worries, Lincoln. Good luck with the Forgeremove
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 toattributethe href
attributes from the template.
I thought about a "data-exclude-attributes"At thein 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.littlesame time,
when viewed directly in the browser, the templates
still appear to
have valid hrefs (because they get added by myI've beenbit 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,probably getin 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 willaccessa faster
response from me, since I don't always haveto 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 toresults :)me personally
(at home) and copy the dev list for best<eric.wittmann@redhat.com <mailto:eric.wittmann@redhat.com>
Thanks!
~Lincoln
----- Original Message -----
From: "Eric Wittmann"<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:lbaxter@redhat.com>To: "Lincoln Baxter" <lbaxter@redhat.com<mailto:lbaxter@redhat.com><mailto:lbaxter@redhat.com <mailto:lbaxter@redhat.com>>
<mailto:lbaxter@redhat.com<mailto:lbaxter@redhat.com>>>>, jfuerth@redhat.com<mailto:lbaxter@redhat.com
<mailto:jfuerth@redhat.com><mailto:jfuerth@redhat.com><mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>>
<mailto:jfuerth@redhat.comdiscussion<mailto:jfuerth@redhat.com <mailto:jfuerth@redhat.com>>>
Sent: Wednesday, January 2, 2013 1:31:03 PM
Subject: Errai navigation + templatingresponsibilities
Hey Lincoln. I'm in the JBoss middleware group,
specifically
working on
the Overlord project. One of myanother.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 topriority.
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 attributetoken
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<mailto:errai-dev@lists.jboss.org <mailto:errai-dev@lists.jboss.org>>as the href.
Thanks!
-Eric
--
Lincoln Baxter, III
http://ocpsoft.org <http://ocpsoft.org/>
"Simpler is better."
_______________________________________________
errai-dev mailing list
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@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@lists.jboss.org <mailto:errai-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/errai-dev
errai-dev mailing list
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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev