[errai-dev] Errai navigation + templating discussion
Eric Wittmann
eric.wittmann at redhat.com
Tue Jan 22 09:37:33 EST 2013
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
>
More information about the errai-dev
mailing list