[errai-dev] Errai navigation + templating discussion

Lincoln Baxter, III lincolnbaxter at gmail.com
Tue Jan 15 11:20:26 EST 2013


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>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>> 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>> 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>> 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>>> 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>>>
> >>                     To: "Lincoln Baxter" <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>>
> >>                     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>
> >>     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
> >
> >
> >
> >
> > --
> > 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
> https://lists.jboss.org/mailman/listinfo/errai-dev
>



-- 
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130115/b9353e6d/attachment-0001.html 


More information about the errai-dev mailing list