[errai-dev] Errai navigation + templating discussion
Christian Sadilek
csadilek at redhat.com
Tue Jan 22 10:51:02 EST 2013
Thanks Eric!
On 2013-01-22, at 9:37 AM, Eric Wittmann <eric.wittmann at redhat.com> wrote:
> Worked like a charm, thanks for the assist.
>
> Took me awhile to get back to, but the changes are done and in a pull
> request:
>
> https://github.com/errai/errai/pull/35
>
> -Eric
>
> On 01/15/2013 01:26 PM, Christian Sadilek wrote:
>> 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 at redhat.com
>> <mailto:eric.wittmann at 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 at redhat.com <mailto:eric.wittmann at redhat.com>
>>>> <mailto:eric.wittmann at 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 at redhat.com <mailto:csadilek at redhat.com>
>>>> <mailto:csadilek at redhat.com>
>>>>> <mailto:csadilek at redhat.com <mailto: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 <mailto:lincolnbaxter at gmail.com>
>>>>> <mailto:lincolnbaxter at gmail.com>
>>>> <mailto:lincolnbaxter at gmail.com <mailto: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 <mailto:eric.wittmann at redhat.com>
>>>>>> <mailto:eric.wittmann at redhat.com>
>>>> <mailto:eric.wittmann at redhat.com <mailto: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 <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>
>>>> <mailto:eric.wittmann at redhat.com> <mailto:eric.wittmann at redhat.com
>>>> <mailto:eric.wittmann at redhat.com>>
>>>>>> <mailto:eric.wittmann at redhat.
>>>> <mailto:eric.wittmann at redhat.>__com
>>>>>> <mailto:eric.wittmann at redhat.com
>>>> <mailto: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>
>>>> <mailto:eric.wittmann at redhat.com>
>>>>>> <mailto:eric.wittmann at redhat.com
>>>> <mailto:eric.wittmann at redhat.com>>
>>>>>> <mailto:eric.wittmann at redhat.
>>>> <mailto:eric.wittmann at redhat.>__com
>>>>>> <mailto:eric.wittmann at redhat.com
>>>> <mailto:eric.wittmann at redhat.com>>>>
>>>>>> To: "Lincoln Baxter" <lbaxter at redhat.com
>>>>>> <mailto:lbaxter at redhat.com>
>>>> <mailto:lbaxter at redhat.com>
>>>>>> <mailto:lbaxter at redhat.com <mailto:lbaxter at redhat.com>>
>>>>>> <mailto:lbaxter at redhat.com
>>>> <mailto:lbaxter at redhat.com>
>>>>>> <mailto:lbaxter at redhat.com
>>>> <mailto:lbaxter at redhat.com>>>>, jfuerth at redhat.com
>>>> <mailto:jfuerth at redhat.com>
>>>> <mailto:jfuerth at redhat.com>
>>>>>> <mailto:jfuerth at redhat.com <mailto:jfuerth at redhat.com>>
>>>>>> <mailto:jfuerth at redhat.com
>>>> <mailto:jfuerth at redhat.com>
>>>>>> <mailto: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 <http://ocpsoft.org/>
>>>>>> "Simpler is better."
>>>>>> _______________________________________________
>>>>>> errai-dev mailing list
>>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>>> <mailto:errai-dev at lists.jboss.org>
>>>> <mailto:errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>>
>>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> errai-dev mailing list
>>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>> <mailto:errai-dev at lists.jboss.org>
>>>> <mailto:errai-dev at lists.jboss.org <mailto:errai-dev at 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 at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>>
>>>> _______________________________________________
>>>> errai-dev mailing list
>>>> errai-dev at lists.jboss.org <mailto:errai-dev at lists.jboss.org>
>>>> <mailto:errai-dev at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/errai-dev
>>>>
>>> _______________________________________________
>>> errai-dev mailing list
>>> errai-dev at lists.jboss.org <mailto: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
>>
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev
More information about the errai-dev
mailing list