作为前端最主要的组件,无论是layui-table表格还是layui-form表单,其中都涉及到选项列的处理。如果是普通编程,一个任务对应一个程序,自然可以就事论事地单对单处理,前后端都配制好选项,手工保证两者的一致性,同时加强校验保证程序不出错。但是如果想做一个统一的库表编辑工具,这样处理显然是不行的。
所以,对于选项域的处理,第一个要求就是前后端一体化,即由后端服务作为唯一的数据源提供方,而前端是根据后端的数据做展示,这样,可以省去诸多一致性的麻烦。毕竟,有一些通用选项在业务界面中无数次出现,如果是在前端每一个选项都要配置上选项目明细,那出现变动时的修改就是恶梦般的事件。
当然,还有第二个要求,就是前端在表格和表单里处理选项域,对选项要能够完全参数化配置化,要通过DOM中的特殊定义的属性进行配置,通过属性要能指定选项集合名称、选项展示类型(列表、树以及其它)、显示格式(只显示名称、键值名称组合)以及选项的默认值等一系列信息,不能每一个选项都要对应JS处理程序,那样实现同样也是恶梦。
按照上面的这些要求来设计,后端服务首先要满足前端展现的数据要求,如针对表格选项列显示要提供选项字典(映射表),对表单选项域要提供选项列表(包括选项树型列表)等,同时还要提供唯一索引的选项集合名称,以便前端请求可以指定集合下载。因此,首先应该构建一个选项集合的基础类,命名为OptionSet,内容如下:
#选项集合基础类
class OptionSet(object) :
# 初始化方法
def __init__(self,v_opt=None,n_opt=None,t_opt=None):
self.opt_dict = v_opt
self.opt_name = n_opt
self.opt_title = t_opt
#logging.debug('options %s' % str(v_opt))
if n_opt :
sysOptionPool.add_optset(n_opt,self)
def get_dict(self):
return self.opt_dict
def get_map(self) :
return self.get_dict()
def get_name(self,id):
return self.get_dict().get(id)
def get_list(self,**kwargs) :
itemlist = []
d_opt = self.get_dict()
if d_opt == None :
return None
for (k,v) in d_opt.items():
itemlist.append([k,v])
f_sort = kwargs.get('sort')
if f_sort == None or f_sort == False:
return itemlist
return sorted(itemlist)
def get_option(self,sort=None) :
return self.get_list(sort=sort)
首先是以字典方式定义好选项条目数据,之后再定义上选项集合的名称。同时类还提供多个对外接口函数,分别是取选项原始字典get_dict(),取选项映射字典get_map(),取选项名称get_name,取选项列表get_list(),取选项明细get_option()。
注意,此处有个坑,就是后来才发现python是有类变量和实例变量的区分的。实例变量必须在在__init__()初始化函数中进行定义,由于python学的时间不长,所以在定义变量时就想当然地以为和JAVA的写法一致,在类名后面就直接写出。在类名后面定义的变量称为类变量,类变量确实能在类里公用,但根据同一个类定义的不同变量实际也是共享的,所谓类变量实际类似JAVA中定义的静态类变量。而要每个实例有自己的变量,就必须以self.val的方式定义在__init__()初始化方法。
当然光有这个基础类是不够了,大多数选项条目是存储在数据库表里的,复杂一些的比如机构、菜单选项更是以父子节点的树型存储的,这些复杂选项将以OptionSet的子类扩展出来,目前总结,包括列表选项、树型选项和类别树型选项三种,将在下一节列出来。本节主要介绍选项集合整体框架的实现,Option

最低0.47元/天 解锁文章
942

被折叠的 条评论
为什么被折叠?



