00:00
呃,上节课其实我们已经在JS里边,大家看到我们把这个render products函数已经实现。我们会发现从。我们一开始这里根据不同的节点类型,然后去给它不同的参数去做render,对不对,然后呢,我们是把这个。本身DOM节点的ID就作为一个参数传进来,然后另外还有一个参数是它对应的筛选条件啊,所以大家会发现那这两个参数其实是一一对应的,对不对,大家会发现我们如果给这个product list的话,那后面就给空。如果给的是review list的话,后面给status就是review,如果是finalize list的话,后面就给finalize,其实大家可以想到我们这个product list其实就相当于后面的status,应该是给,就是在拍卖状态的那个status,对不对?只不过如果我们就是,呃,这里只有一个是空的话,那其实我们可以默认它就在拍卖状态,所以这里我们不给也可以,那这两个是一一对应的,那既然一一对应。
01:16
那岂不是我们直接给一个参数就可以了吗?给两个参数目的是在哪里呢?啊,大家看啊,就是div这个参数给它这个ID进来,它的目的在什么?是在于我们查到对应的信息的时候,是不是就可以直接把它对应的那个DOM节点上,呃,附加上对应的那些div对吧?元素产品信息全部附加在上面就可以把它渲染出来了,它主要是做我们产品页面渲染用的,就是做这个这query的这个方法去做,呃,后面去添加到节点用的,那后面跟的这个filter是干什么用的呢?大家发现它的用途不是在渲染的时候用的。
02:02
而是一开始我们发请求的时候就得发过去的,对吧,因为后台你假如不给这个参数的话,后台不知道你要做什么。所以我们一定要告诉后台server那里,我这一次查询这个产品信息,我我给这个路由products,我就是要查产品信息,对吧?那我现在要查的产品列表是要查哪一类型的呢?我的status在这里给定,当然大家可以想到我这里直接给的是一个filter,而且大家如果细心的话会发现我们课件里边。还不叫filter,叫filters对吧,所以其实也就是说我们这个filter这里是只给了一个product status。就还有可能可以加别的对不对,所以大家会想到我们整个的这个filter传进去的筛选条件都是后台需要去处理的东西。好,那么我们上节课前台这一部分都已经实现了,假如说我们后台能够真正的根据它的这个筛选条件返回对应的数据的话,我们已经可以把它这个分分行分片给它显示在这个页面上了,那接下来我们就看看那后台到底应该怎么返回这个数据呢?
03:18
大家肯定就想到我们是不是要在server这里去添加了,添加什么呢?这就跟我们express这里的相关了,对不对啊,那这里就要去响应前台的请求app.get对吧?啊,这是标准的这种响应的方式,那么get前面是什么呢?大家应该还记得,我们一开始是不是就就试过这样,一开始我们直接就给一个杠,这是不是就它的路由啊,我们现在同样要给一个路由,给什么样的路由呢?大家前后台定义要一致对不对?这里访问的是products,所以我们这里是不是也对应的就是products这个路由,然后接收对应的参数对吧,然后返回好,那么后边还是同样的,大家还记得对吧?Request和RESPONSE2个参数做回调,那么在回调里边就可以定义怎么样去。
04:19
去发送这个返回response对不对?呃,要返回的数据就应该是塞在这个response里面去发回去的,好,这是我们首先能想到的,那现在的难题啊,或者说现在我们要首先要解决的一个问题是什么呢?首先我们要解决的是怎么样拿到数据,那拿数据大家其实想到了肯定就是跟网购交互呗,现在不用跟区块链交互了,对吧。那跟mango交互,我们是用哪个对象去交互呢?回忆一下上节课是不是用这个product model,对,所以我们这里能想到,如果要去查询,直接去product product model.find。
05:02
是不是又可以把它查出来了。当然查出来之后。我们应该能想到前面这一部分应该是一个query条件对吧,那后边应该还应该有我们对应的那些东西对不对,比方说呃,这个projection投影投投射到哪几个字段对不对?然后还有就是我们有没有一些别的特殊的要求,比方说呃,是否排序呀,是否做一些别的索引的一些要求啊,那有些特殊的选项,最后还应该有的一个是什么?是一个回调对吧?啊,大家就是记得我们的这个这个过程,那当然了,最后的这个回调应该还是要写成这个,就是error优先的。格式对吧?呃,那这里如果去拿到的话,可能拿到的是一组数据,所以我们这里,呃。
06:02
就叫。就叫it吧。所以我们可以定义这样一个回调,然后在这个回调里边,当然我们就是if error的话啊,这都是常规操作对吧,点log error,当然如果else的话。我们就cons点了个。Items。点length,我们把它的长度打印出来,能看到有几个对吧?然后我们是不是就可以把这个response发出去了,对吧?response.send it it。就是把返回的这一个数据筛选出来的数据直接发送到前端页面上去,然后我们前端页面是不是就在这里可以拿到这个data了,所以那里的it就是这里的data对吧?啊,所以大家搞清楚这个就可以,呃,那现在主要的难点在哪里呢?那其实我们可以想到是不是难点就在这个query条件啊。
07:24
这个query条件我们一定还记得,一开始我们在这个index JS里面定义的时候,是要把这个filter带过来的,对吧?我们是要根据不同的product status去做筛选的。那这个时候。我们的filter怎么去处理呢?啊,那首先。大家应该能想到,我们是不是应该去定义一个,比方说就定义一个叫per这样的一个东西,对吧,那这样的一个东西是不是就应该把我们传过来的东西先保存起来啊。
08:02
对不对,所以呃,那那么大家就会想到我们传过来的那个东西到底是什么呢?这个好像还有点儿麻烦,而且我们传过来的这个product status其实跟我们定义的那个还不一样,对吧。我们在这个产品定义里边的product status,它是什么?它是012,就是open sold on so的那个数,对吧,那跟我们这里的这个product status其实不是一回事。我们这里要的不是它到底卖出去没有的那个状态,我们要的是它是否还在这个可拍卖的状态下,或者是否是在这个揭示报价的这个状态下,这个状态。其实我们在。本身的数据结构定义里面是不是没有啊。那这个东西就麻烦了,我们怎么判断当前这个产品,它是在哪个哪个阶段呢。
09:01
是在可竞拍的阶段,还是在可揭示报价的阶段呢?我们用哪个字段去判断呢?大家看一下这里面能用到的字段,应该是根据哪个来判断。Product status现在看来是不行了,对吧?啊,大家其实可以想到。我们判断一个产品它的是否应该结束,然后进入review阶段,是根据哪个字段来判断的呀?是不是安啊?是不是我们当时判断的就是啊,大家回忆回忆一下啊,这个JS这里大家是不是已经忘记我们之前怎么写的了,对吧?这这里面写了很多对不对。假如说我们这个pass in p6 P6是什么。嗯,对,P6就是undertime对不对,假如说小于undertime的话,我们是不是B定点售,所以这个状态下是不是就应该是当前处在这个竞拍状态啊,然后我们是这里定义的,这是直接写死的一个review的时间,对吧,然后我们是P6加600。
10:15
那是不是之后十分钟范围内对吧,这就是review阶段对不对,然后再如果大于了P6加600,那是不是就变成了final finalize的阶段了啊,所以是这样一个状态对吧?这样一个定义,好,那么我们在这里已经想到了这个条件的话,那应该大家就会想到我们是不是还得需要另外一个东西啊。我们要判定。当前它处于哪个状态,是不是要拿一个参数。去跟这些东西做比较啊。Pass p6跟什么东西要去比较啊?是不是跟当前时间啊,这当前时间是在不停变的,对吧?所以每次查询我们都得去获取当前时间,好,那现在我们这个思路就终于回来了,知道他要怎么样去做查询了,呃,所以是不是得有一个current time呀?啊,那这个做法还是一样,对吧?mass.round round就是四舍五入对吧?New一个date,然后去除以1000,对,好,先拿到这个current type,然后这个query呢,大家会发现是不是?呃,跟我们当前的这个请求来的数据里边的那个status其实没什么关系啊。
11:40
所以这里边我们先给定一个默认的product status。Product status。大家想一下,这里我们的product status应该是什么?这里的product status应该是我们在这里定义的product status对不对?
12:05
对吧,产品真正存在mango里边的product status,它的这个数是什么呢?012对吧。我们现在要查的是什么样的产品呢?一和二是不是已经完全。结束之后的才会出现一和二的状态啊,就是sold on so的那个状态,对不对,哎,所以那我们在这里是不是查的应该默认就只是零的状态。你至少还应该是未完结状态对吧,哎,大家看一眼啊,就是。这个我们在哪里定义的,是不是还是在这里定义的呀。我们的那个。刚才说的那个product status在合约里边返回的是哪个值呢?是不是P8啊?P8,如果等于一,是不是就直接显示我们那个就是托管合约信息那些东西去了,是不是跟我们当前的这个产品信息就应该没有关系了,对吧?所以我们现在要的是什么呢?我们现在要的是下边的这几种状态。
13:13
是不是应该是P8不等于一,也不应该等于二,才会进入到我们的be reviewing和finalize这三个阶段啊?那是不是P8应该等于零啊?对,所以大家就回想一下我们之前的这个逻辑啊,大家如果要已经忘记的话,可能就有点这块就有点绕了,对吧?那这里边我们其实是要product status等于零对不对,但是大家注意看这里我们不要不能直接这么写等于零,为什么呢?因为这个query大家会想到是不是之后我们就把它直接写在这里去传入就可以了。对吧?那大家回想一下我们在mongol里边的find,它后面给的那个query条件是怎么写的呢?是直接product status0这样去写吗?
14:06
啊,当然直接这么写是可以的,就是你假如要求它一定等于零,那是可以这么去写的,对吧?那更普遍的情况其实是用一个对象来表示,这个对象里边可以有操作符,比如说等于就是EQ对不对,EQ对吧,EQ然后是零,所以这就表示它的值要等于零。啊,当然大家如果这里直接写零,其实也是可以的,对吧,我们这里只是给大家一个更通用的写法,因为我们这里的query是直接要放到这里的,而放到这里是给我们mango里边的find去用的。啊,大家要回忆起来我们当时mango find的时候给的那些参数,对吧?忘记的话大家再再回忆一下当时我们mango的那些参数,好,那么我们默认的这个query就已经知道了,我们要查的都是C等于零的这些条,呃,条件这些商品,那么大家就会就会想到我们查status等于零,那我们这个这个请求request里边不是还带了filter的吗?
15:13
那那个product status又应该怎么去用呢?那所以我们是不是还得去判断那个product status到底是什么,对不对?所以接下来我们要做的是一个什么事情呢?我们要判断,首先判断那个product status。我们当时的做法是不是?首先它有可能是空了啊,它有可能没有东西对吧?好,那么我们先处理这种情况,那没有东西怎么去判断呢?Object key要拿一个对象,拿哪个对象呢?Request的。Query对象对吧?啊,大家还记得我们呃,他发的请求是一个get请求,我们他的所有的data是不是全部会跟在这个URL后边作为一个呃查询参数啊,所以在这个express里边。
16:16
Request对象它是有这个query参数的,Query对象就是我们带过来的那些所有的查询条件,就是所有的筛选的那些条件,那那个对象这里拿出来我们它如果所有的K,它的长度lengths是零的话,那么是不是就是没有东西过来啊。没有东西过来,我们会想到这个时候查的是什么。这里没东西过来,我们要的是product list,对吧?Product list是不是就是还在竞拍状态下的那些商品?那我们这里的判断条件是要什么呢?
17:00
我们知道一个query对吧,判断条件是要什么呢。是不是要判断那个auction and time呀,是不是要判断它的竞拍截止时间是不是比当前的current time要大,对不对,如果说它大的话,才应该是在我们这个满足这个查询条件的,对吧?所以我们要的是这个条件,稍微有点绕啊,大家好好想一想,然后我们这里的写法大家也注意一下,我们直接写query它的option。等于。等于什么呢?把后面这个对象写进去对吧?啊,大家会想就会想到跟上面的这个写法是不是一样,那这里它是要求endtime应该要大于,大于是什么是GT对吧?Greater在GT大于谁呢?大于current time对不对?
18:01
好,所以是这样一个写法,那大家注意一下我们这里的query,然后后面加了这样一个方括号的写法,是表示直接给这个query,这是一个Jason对象,对不对。Jason,这个JS对象对吧,Object JS对象它里边的这一个K字段去赋值对不对?所以它本来里边已经有一个K叫product thes,它的值是E口零,那么现在我们又给它加了一个K叫option and time,然后它的字段是greater than current泰对吧,大于current。所以这是我们给它的定义,那大家会想到接下来传进去的,假如说走到这里的话,这个query它里边的内容应该是什么呢?我在这里写一下啊,这里是不是query的内容就应该是这样的一个样子。Product status后面我就不写了啊,然后这里是auction and time是不是这样一个形式对吧?所以我们下面传进来的query就是这样一个东西。
19:09
那大家肯定知道他俩之间的这个逗号关系表示什么呢?在我们这里面表示什么?还记得猫口里面的查询条件吧?联合查询与或非。这个是不是表示雨啊,对,如果要是或的话就麻烦了,前面还得Dollar or对吧?对,所以我们这里直接把它拼成这样一个对象,它直接就表示语,所以这个是比较简单的一种写法啊好,那么我们先把它删掉,然后接下来大家会发现,那我肯定就有else了,对不对,Else。Else if,首先else,大家会想到你这个lengths如果不等于零的话,那我是不是就得看你这个rare.query里边到底是什么字段了,对吧?我们一开始不是说可以有各种各样的这个呃,过滤条件吗?
20:06
对吧,Filter的这个字段嘛,所以我们这里要判断你的。ra.query点里边的product status,要看他是不是真的有,对不对。它假如不等于on five,假如说它有定义,我们真的要查这个东西了,诶那我们这个时候是不是就说明。就是走了这里的这个分支把这个东西传进来了,对不对,他要不是review,要不是final对吧?哎,那这两种情况又不一样,那我们是不是还得再if一下呀?啊,当然大家如果想去用那个Switch kiss也是可以的,对吧?啊,我们这里直接就if就好了,那如果要if什么呢?大家大家就想到这就是很这个很没有技术含量的这个一个一个判断了,对吧,Product status,假如说它就等于review的话,那当然这里边有,假如它等于review,那当然就有L。
21:20
RA query。点product status就有它等于final对吧。Final finalize,不好,这两种情况大家会想到,其实处理的这个方式应该是差不多的,对吧?那这里的处理方式应该是什么呢?跟上面一样,是不是还是query,我要去加一个条件啊。那如果是review的话,这个快条件应该是什么东西呢?Query,条件是不是应该是option and time,大家回忆一下应该是什么?
22:10
Antime应该是什么呀?呃,大家会想到我们的要求,前边的这个是要求它要大于,呃,就是current time对吧,那现在的话。他是不是不光要大于current time,还要要求。对,还要小于car time,呃,就是就是它加上。一个数字之后要小于current time对吧,所以就是过了一段时间之后才能到这个review阶段,而我们在原来的那个状态下是是给定的是多少呢?给定的是600秒对吧?所以我们这里要给的是小于。
23:04
小于什么呢?Car time减去600对吧?好,这是我们这里这样的一个查询条件啊,那当然大家就是可能大家比较习惯的是,我们就是是判断当前的current time应该要大于auction andtime加上600对吧?但习惯的表达可能是这样,对不对,我们当前时间要比它的那个竞拍结束时间还大,大十分钟的时候就进入到review阶段对吧?呃,所以大家可能习惯的是这样的一个条件,呃,所以。嗯。大家如果要是这个仔细去考虑的话,可能就会想到,那我们前面如果要是去更严谨的去筛选,可能还得把这个再加一个,不仅要大于这个current time,还得去,呃,小于等于这个。就是还得去。
24:01
啊,这个不是啊,就是current time,这个是要小于这个an time的,对吧?啊,这个没问题啊,所以大家会发现这里我们因为筛选条件是option on time,所以要跟大家平常习惯的那种写法要反过来,就大家平常习惯的写法是current on time要大于。Option and time加。600对吧,那现在我们的写法是要auction and time要小于。Current time减600对不对?这两个表达式是不是完全一样啊,这个判断是不是应该完全一样,其实就是个左右移项的过程对吧?啊,但是大家可能一下子就有点接受不了,是因为我们这里边是一定要用option time去做查询条件的,所以一定得用下面这个式子对不对?啊,所以大家把这个再搞清楚好,那么我们这里已经把这个review的这个环节已经查询出来了,那同样finalize的这个环节应该是什么样子呢?呃,那其实大家能够想到的啊,就是我们可能就还是去给一个auction and time,然后让他去等于一个查询条件,对吧?啊,那当然了,这个查询条件当时我们好像还是自己手动给它定义了一个对不对。
25:28
我们定义的是多久来着?啊,大家会发现就是只要是大于这个,呃,600以上就相当于我们这里就全可以去去,呃,就是超过了undertime,再加上600秒以上就进入的阶段是这个final option对吧,这个阶段好,那么我们这里就把它写出来。
26:04
嗯,大家就会想到我们这里是不是就应该是。诶,我们前面是不是写错了。Option on time应该是。比current time减600,小还是大?那大家再重新来来回顾一下啊,Current time,我们在它小于option on time的时候,这个应该是在第一个阶段,对不对,这是我们的这个对应的这个阶段应该是B阶段,对吧。好,那接下来current time,如果要是大于。这个确实有点绕啊,所以我们把它还是详细的写一下吧,大于n time,然后小于。
27:02
Option and time加。600秒的时候,这个是不是就应该是我们的review reviewing阶段啊,对吧,然后最后我们是不是就是current time要大于option and time加600秒,这个就是我们的final阶段对吧?那这个确实有点有点有点那个绕啊,所以大家再确认一下,这里边我们我我把这几行直接就写在上面吧。省得我们到时候这个。好,那么大家会发现,我们第一个要去判断option and time的时候大于current time,这个没问题对吧?第二个我们要去判断current time的时候是不是,呃,我们得判断auction and time对吧。
28:06
他是不是应该要。小于current time,然后要大于。Time减600啊,是不是这样一个范围。对吧,大家注意一下啊,刚才我们其实这个写的应该是有问题的,对吧?大家看一下这两个,这两个判断条件要一项对不对啊,这是个数学问题啊,对吧?所以大家会看到我们本来大家习惯定义的是current time作为中间,对吧?然后它要大于option n time小于optionu ntime加600,那么我们要是以这个AU and time作为这个判断,怎么样去判断呢?那是不是应该optionu and time,它应该。这里大于一个数后边要小于一个数对不对,那它大于哪个数呢?小于这个没有,没话说,这n time就小于current time对不对,这个我们就直接写在这里,那这里的这一个大于是不是要把这边要做一个移项啊,它要大于current time减600对不对,对,所以大家注意啊。
29:15
减600,所以这是我们真正要去写的这个表达式啊,前面我们这个还是写错了啊,所以这里大家注意,我们这里应该给的这个表达式应该是是什么呢。呃,它应该是大于current time减600对不对,然后如果要大家去详细写的话,应该是要再加一个条件是不是小于。Current time啊,是不是这样啊,当然就是说后边这个小于current time其实可以不写,为什么呢?因为前面我们的这个判断条件里边是去筛选这个current time的,对吧?啊,那在这个里边,其实大家就是不写也是可以的,好那么接下来。
30:04
接下来我们看这个finalize这一这一列啊,Finalize的时候这个就又简单一些了,其实大家会发现其实就是那个中间这个reviewing这个判断条件稍微麻烦一点,对吧,那这里的话就又简单是不是current time,只要。Of an option an time,只要小于currenttime减600就可以了,对,刚才是大于,现在是小于啊啊,所以大家不要搞错了。Car car time减600,好,诶,这里大家还要稍微注意一下,是不是这里直接小于car time减600就可以了呢?还不一定,为什么呢?因为还有可能小于600之后,有可能已经做过完结操作了,对吧,那是不是他的产品状态就已经变成,呃,就是已经卖出去,对吧,或者说他已经没有卖出去,已经到了这个状态,那所以我们是不是还得把上面的。
31:09
这一部分要加进去啊,Status productlo status一口零,这个是一定要放在里边的,对不对啊,那当然这里边大家可以再把它再重新写一遍,但如果我们上面已经有了的话,那下面其实已经有这个选项了,也可也可以不选,对吧,也可以不再写了。呃,我们的课件里边好像是把它又写了一遍,对吧?好,那么现在我们就已经把这个过程都已经定义完了,那我们这里要去把这个query传进去,呃,那细心同学可能发现,我们假如说拿出来的这一个,所有的拿到这一个返回的结果,我们是不是还得把它做个排序啊?因为我们当时插入这个商品的时候,它的顺序肯定是按插入时间去去去排序的,对不对?我们拿出来的这一个给用户显示的顺序应该是按它的上架时间去显示吗?还是应该根据什么呢?对,我们可能想到应该是根据用户最关心的可能是它的那个拍卖结束时间,对吧?所以我们这里边可能还要加一个salt,那这个salt加在哪里呢?是加在它的第三个参数,就是有一个。
32:22
有一个各种各样的options那个里面对吧,Salt去给一个。呃,我们给一个auction。安泰按照安泰去做这个排序,然后大家注意,如果我们。这三个参数有两个的话,那一定中间就不能少东西了,对吧?如果我们只有一个的话,它默认就是第一个参数是query,如果给两个的话,那第二个参数它默认应该是那个,呃,Project那个投影对不对?
33:02
对吧,最后一个参数它默认是这个呃回调,所以大家注意,假如说我们要给定这个第三个参数的话,第二个参数传一个档进去,呃这样的一个写法,好,那么大家可以发现,到目前为止,我们就已经把这个服务端server这一端也完全实现了啊,那这这就是我们这一部分内容啊。
我来说两句