电子商务系统的设计与实现(十四)：菜单高亮

菜单高亮，几乎是所有Web网站都需要的一个功能。

这个功能，说起来，简单得很，给当前页面的菜单增加一个高亮样式，删除其它菜单的高亮样式。

如果只高亮1个页面的菜单， 太简单了，但是如果菜单和页面比较多，就产生了争议。

第1种方式：每个页面单独高亮。

<li id="indexli"><a href="${base}/">首页</a></li>
    <script type="text/javascript">
	function highlightIndex() {
		highlight("indexli");
	}
      function highlight(id) {
		$("#" + id).addClass("liactive");
	}
</script> 

好处：灵活性非常强。
   坏处：每个页面都需要增加一个高亮菜单的方法。

第2种方式：通过匹配URL， 只写一个高亮菜单的方法。

     var url = window.location.pathname;
		//默认为‘首页’index
		var current = ‘index‘;
		if (url.indexOf(‘/service‘) != -1) {
			current = ‘service‘;
		} else if (url.indexOf(‘/case‘) != -1) {
			current = ‘case‘;
		} else if (url.indexOf(‘/article‘) != -1) {
			current = ‘article‘;
		} else if (url.indexOf(‘/code‘) != -1) {
			current = ‘code‘;
		} else if (url.indexOf(‘/about‘) != -1) {
			current = ‘more‘;
		} else if (url.indexOf(‘/news‘) != -1) {
			current = ‘more‘;
		} else if (url.indexOf(‘/help‘) != -1) {
			current = ‘more‘;
		} else if (url.indexOf(‘/ask‘) != -1) {
			current = ‘ask‘;
		} else {
			current = ‘index‘;
		}
		for (var i = 0; i < navList.length; i++) {
			if (i == map[current]) {
				navList[i].className = ‘liactive‘;
			} else {
				navList[i].className = ‘‘;
			}
		} 

好处：菜单高亮逻辑处理，都在一个地方。
坏处：灵活性很差，对URL有比较严格的要求。
简单说就是，URL的规则越简单越统一，匹配越简单。但是URL如果有例外的情况，就必须做特别处理。
当再增加一个URL的时候，需要考虑新增的URL和已有的URL匹配规则是否产生冲突。

-----------------------------------------------------------
上述2种方法我都用过，说说我的感受。
如果URL比较随意，就在每个具体的页面单独调用高亮函数。
如果URL非常统一，可以统一处理。

在实际过程中，比如公司的项目中，关于采用哪种方式就产生了争议，前端希望统一处理，后端倾向于单独定制。
后端开发过程中，url比较随意。前端希望后端把url规范命名，按照菜单的组织来定义url。
而boss则不愿意这么做，他认为菜单和后端url并不需要严格统一，菜单和后端业务不应该有过强的依赖。

就我们公司的项目和我自己的项目，我更倾向于每个页面单独调用高亮函数，非常灵活。
有的页面，只需要高亮最顶层菜单，有的页面，还需要高亮左侧的菜单。

至于高亮菜单的逻辑，可以封装成方法。

无论你增加了多少页面，每个页面的高亮，都不会互相影响。
-----------------------------------------------------------
再吐槽几句，封装菜单逻辑，每个页面调用一次高亮函数，分分钟就搞定的事情。非要去写统一的URL匹配，花费个把小时，还不能保证完全正确，并且， URL匹配也不能在多个项目之间复用。

团队开发就经常存在这么类似的很多问题， 导致开发效率非常低。

so，我认为，一个优秀的全栈式开发工程师，和5个人的小团队开发效率差不多。