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.
Lincoln Baxter's Droid
"Keep it Simple"
On Jan 11, 2013 1:14 PM, "Eric Wittmann" <eric.wittmann(a)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
> 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
> 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.
> 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 :)
>> ----- Original Message -----
>> From: "Eric Wittmann" <eric.wittmann(a)redhat.com>
>> To: "Lincoln Baxter" <lbaxter(a)redhat.com>, jfuerth(a)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:
>> 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.
Hi Errai devs,
We had a slight hiccup today on the 3.0 branch, and we decided to rewind it by several commits in the upstream repo. If you pulled in the 3.0 branch any time in the past 5-6 hours, please be sure you re-fetch and rebase your work on the new 3.0 branch pointer in upstream.
One possible approach:
% git fetch --all
% git reset --hard upstream/3.0
(and then cherry-pick any commits you had that were abandoned.)
Another possible approach would be to rebase -i and drop the accidental commits.
Drop by #errai on freenode if you're in doubt. :)
I was thinking about the next steps we could take in making mobile development with errai better.
One thing I fought with in the past developing a mobile application with GWT is that there was the possibility that there wasn't any network. We had to store the things locally and then sync them later. We could create something would do that automatically, we could generate 'offline' versions of the server interface save it in client side database and sync automatically when the connection is there again. For the developer using it the whole experience is seamless.
Creating cordova projects and then setting all the things so you can publish them in the store is a bit a of a pain. We could make this better by having a maven plugin or forge extension to ease this.
That are the ideas I have does anybody have others?