Hyperlink/Anchors: Passing data in Places

[Shaun Tarves]

When using activities and places, what is a proper approach to passing data through places on link clicks, but still keeping the good behavior associated with "real" links.

Is it best to use an Anchor, set an href using the placeHistoryMapper, and then preventDefault on the DOM when the anchor is clicked? That way, we still operate on the actual Place (which would contain some data, conceivably) unless the user directly navigates to that link in the URL bar or does a right-click -> Open in...

Or is it best to encode only the data necessary in the Place token and fetch what is required from the server based on that "shallow" Place?

[Thomas Broyer]

On Tuesday, May 15, 2012 10:13:56 PM UTC+2, Shaun Tarves wrote:

When using activities and places, what is a proper approach to passing data through places on link clicks, but still keeping the good behavior associated with "real" links.

Is it best to use an Anchor, set an href using the placeHistoryMapper, and then preventDefault on the DOM when the anchor is clicked? That way, we still operate on the actual Place (which would contain some data, conceivably) unless the user directly navigates to that link in the URL bar or does a right-click -> Open in...

Yes.

(though I actually didn't understand the alternative below ;-) )

[Shaun Tarves]

Sorry, the alternative below would be to have the URL contain enough information about the new "place" (such as an ID if that's sufficient to get all the data we need) and then always populate from scratch. I would call that a shallow place - it doesn't contain all the data we need, but it contains enough data to go fetch it.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/UdwC9D_-OuoJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Thursday, May 17, 2012 2:56:40 PM UTC+2, Shaun Tarves wrote:

Sorry, the alternative below would be to have the URL contain enough information about the new "place" (such as an ID if that's sufficient to get all the data we need) and then always populate from scratch. I would call that a shallow place - it doesn't contain all the data we need, but it contains enough data to go fetch it.

How is that different from the other suggestion ("set an href using the placeHistoryMapper"), besides letting the browser do the navigation rather than using preventDefault and calling PlaceController#goTo yourself? (that last bit is actually mostly an "optimization" here)

[Shaun Tarves]

It's about optimization, I guess. If you just have a shallow Place object (say it only knows an ID) and always fetch the data you need, that means more calls.

If you let the Place object contain a lot more data, you still have to code for when it doesn't (eg., when the user navigates directly to a URL or does a right-click -> Open in new tab...).

I was just curious if there's a preferred pattern here.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/9tdo2nSwBPUJ.

[Thomas Broyer]

On Thursday, May 17, 2012 4:42:13 PM UTC+2, Shaun Tarves wrote:

It's about optimization, I guess. If you just have a shallow Place object (say it only knows an ID) and always fetch the data you need, that means more calls.

If you let the Place object contain a lot more data, you still have to code for when it doesn't (eg., when the user navigates directly to a URL or does a right-click -> Open in new tab...).

I was just curious if there's a preferred pattern here.

IMO you should prefer the preventDefault+PlaceController#goTo way (and don't forget to code the "fallback" in the target PlaceChangeEvent.Handler and/or Activities!), as it's really small overhead for the developer (you could even make a PlaceHyperlink(PlaceHistoryMapper, Place) to avoid repeating the same things again and again) and a real win for the user.

[Shaun Tarves]

Hi Thomas -

I went down the road of the PlaceHyperlink [trying to create as extension of Hyperlink with a method setDestination(Place)]. My intention was that PlaceHyperlink could be used in UIBinder, and my presenters wouldn't all need to pass through a PlaceHistoryMapper.

I have GIN set up, so I'm trying to inject my PlaceHistoryMapper into my PlaceHyperlink (as a field injection - to avoid the missing no-arg constructor problem), but no dice. That PHM is always null (although it works fine in other places when constructor-injected).

I don't totally understand why this doesn't work. Any thoughts how to implement a PlaceHyperlink with UIBinder and GIN?

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/a-fAcWjwkGYJ.

[Thomas Broyer]

On Thursday, June 7, 2012 4:43:40 PM UTC+2, Shaun Tarves wrote:

Hi Thomas -

I went down the road of the PlaceHyperlink [trying to create as extension of Hyperlink with a method setDestination(Place)]. My intention was that PlaceHyperlink could be used in UIBinder, and my presenters wouldn't all need to pass through a PlaceHistoryMapper.

I have GIN set up, so I'm trying to inject my PlaceHistoryMapper into my PlaceHyperlink (as a field injection - to avoid the missing no-arg constructor problem), but no dice. That PHM is always null (although it works fine in other places when constructor-injected).

I don't totally understand why this doesn't work. Any thoughts how to implement a PlaceHyperlink with UIBinder and GIN?

You can either use a @UiFactory or use @UiField(provided=true) in your views (but that's a lot of boilerplate) or use a static field and requestStaticInjection(PlaceHyperlink.class) in your GinModule. I don't quite like it but it works, and I've been using it for the past year on a few widgets (particularly SuggestBox-like widgets, providing them the RequestFactory).

There's an issue on the tracker about making UiBinder more GIN-friendly but that's not an easy patch…

[Shaun Tarves]

Thanks for the suggestions.

I'm still perplexed why the field injection of the PHM doesn't work in a PlaceHyperlink.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/6EBTyXa-ek0J.

[Thomas Broyer]

On Thursday, June 7, 2012 5:58:10 PM UTC+2, Shaun Tarves wrote:

Thanks for the suggestions.

I'm still perplexed why the field injection of the PHM doesn't work in a PlaceHyperlink.

Depends how you do it; but given that it's created by UiBinder and not by GIN (unless you use @UiFactory or @UiField(provided=true)), you have to take explicit action to inject it with GIN. You should be able to do "instance injection" instead of "static injection" if you prefer (declare a method on your Ginjector taking a PlaceHyperlink as argument and with a void return-type, then call it with a PlaceHyperlink for an equivalent to Guice's injectMembers)

[Shaun Tarves]

Duh. Completely looked past that little fact.

So, something along the lines of a PlaceHyperlink Factory using @Assisted to get the Place into the PlayHyperlink and a provided=true should get the job done.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/DQe2uOI5gKcJ.