This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.

Suggestion to ease configuration

Mar 7th, 2013, 05:19 PM

I think it would be nice having a more configurable static factory method in SiteSwitcherHandlerInterceptor that not only allows you to use m.site or site.mobi etc, but just plainly let the coders configure whatever mobile and normal URLs they want. I know it could get configured today, but it is cumbersome (I guess for that same reason there are helper methods).

I agree with your feelings. When I added the tablet support everything became more complicated. The original static convenience methods made more sense when only dealing with mobile or normal options. What are your requirements, or do you have something already in mind? It's perfectly fine to discuss in the forum, but if you have some concrete ideas, can you please create a JIRA? Thanks!

the string expressions are just to make sure we can reuse existing property variables and create valid URLs (for example a trailing slash today makes m.mysite.com/ be different the getServerName() -- m.mysite.com -- and thus thing we are in the wrong URL (same thing with the port). This is probably just an issue we face.

I really don't know the code good enough to propose something sound from scratch, but I would try to see if there's a way to make all these options pluggable, so it's easier to extend, instead of hardcoding them in methods. For example, somebody that integrates with WURLF might want to have even different sites for mobile (android vs iOS, vs blackberry, vs feature phones). For example in StandardSiteSwitcherHandler.handleSiteSwitch() you just visit each of those and decide.. don't know, just saying.

I agree with your feelings. When I added the tablet support everything became more complicated. The original static convenience methods made more sense when only dealing with mobile or normal options. What are your requirements, or do you have something already in mind? It's perfectly fine to discuss in the forum, but if you have some concrete ideas, can you please create a JIRA? Thanks!

Comment

Ok, I see. This would basically be a configurable alternative for the mDot and dotMobi strategies, but not for the urlPath option. You've touched on a theme that has come up in our discussions, in that generally configuration needs to be more pluggable. This also applies to the LiteDeviceResolver. I don't think it makes sense to overhaul the configuration in a 1.1 release, but probably a 1.5 or 2.0 we'll want to seriously reconsider the configuration aspect. However, adding another static method now to allow for more custom configurations seems reasonable.