Suggestion to ease configuration

[sotretus]

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).

thanks

[Roy Clarkson]

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!

[sotretus]

For once we worked around it by extending the class and providing another static method:

	public static SiteSwitcherHandlerInterceptor configurable(final String mobileName, final String normalName) {
		boolean tabletIsMobile = false;
		String mobileServer = mobileName.replaceAll("http[s]?://", "").replaceAll(":[0-9]+/", "");
		String normalServer = normalName.replaceAll("http[s]?://", "").replaceAll(":[0-9]+/", "");
		return new SiteSwitcherHandlerInterceptor(new StandardSiteUrlFactory(normalServer), new StandardSiteUrlFactory(
				mobileServer), new StandardSitePreferenceHandler(new CookieSitePreferenceRepository("."
				+ normalServer)), tabletIsMobile);
	}

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.

Regards
AB

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!

[Roy Clarkson]

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.

[Roy Clarkson]

Added and working on MOBILE-72.