今天，已经把层次导航系统完成（如：所有目标>>我进行中的目标>>撰写目标"学习日记开发小组需求分析设计区(技术类：开发小组用)"的日记），下面将进行横向导航的设计（上一条，下一条）。这里把系统开几个窗口的问题与横向导航的设计结合起来设计。
我考虑了一下，凡是可以横向导航的地方都只开一个窗口，例如，现在我在查看一篇目标的内容，我
要查看另一篇目标的内容就不要再开一个窗口了。这样，也会横向导航的设计相一致了（横向导航的
上一条和下一条内容都在原窗口中打开）。
一、下面把横向导航的需要列个表：
１、在所有目标列表中：
１）目标内容；
２）目标的日记列表（上一条：在这里即上一目标的日记列表）；
３）日记列表中的日记内容；
２、在检索结果页面中：
１）检索目标列表：
１》目标内容；
２》目标的日记列表；
３》日记列表中的日记内容；
２）检索日记列表：
１》日记内容；（检索日记列表中的日记所有目标内容和日记列表的横向导航均没有意义，
所以在这个页面上不需要横向导航，但是，它们的内容应该各自在一个窗口中打开）
２》所在目标的日记列表中的日记内容；
３、您的进行中的目标列表：
１）目标内容；
２）目标的全部日记列表；
３）目标的我的日记列表；
４）２）和３）中的日记列表中的日记；
二、横向导航的实现方法，得到条目列表的上一条和下一条的goalID,在当前的url中仅仅修改goalID
参数就行了，其它（包括naviStr）一切不变。但是，怎么样才能得到上一条和下一条的goalID呢？
１、在所有目标中，需要参数：所有目标的列表，排序方式，当前目标的ＩＤ（所在的位置）；
２、在您的进行中的目标列表中，需要参数：同１；
３、在检索结果页面中，需要检索结果列表，排序方式，当前条目的ＩＤ；
上面所有的ＩＤ在url参数中均是goalID；
方法：
LearndiaryDB.getNext(currentID,list)
２００５年１０月２６日
我想了一下，把全部记录的ＩＤ保存在list中传给程序处理不会增加额外的内存开销，因为在Java中，传递对象实际上传递指向对象的指针。但是要保证这个list能及时销毁。
因为ID是整数，所以不能保存在list中，但可以保存在array中（在java中，传递array也是传递指针）。
这里，有以下几种处理的方法：
１）从查询结果集中取出每个ID后，保存在array中，马上关闭数据库连接，减少数据库连接开销。然后在同个方法中取得前面、当前、后面记录的ＩＤ。只返回３个元素的array给Pager类处理，这样，可以保证每条数据都是最新的，但是要不停的开启和关闭数据库连接；
２）把查询结果产生的array全部存在session中，Pager在session中取数据。这样，可以减少数据库的查询，但是存在两个问题，那个比较长的array在session中始终占用内存，还有，取出的数据的排序关系可能是过期的（这时，有人往数据库中增加或修改了数据）。
我不知道哪种方法可以减轻对网站的压力，决定采用第一种方法。
另外，在结果集中查询邻近的ＩＤ会出现几种结果呢？
１）在用户查看帖子期间，这篇帖子被删除了，结果返回：｛－１，－１，－１｝；
２）只有一篇符合要求的帖子，结果返回：｛－１，当前帖子ＩＤ，－１｝；
３）当前帖子是第一篇帖子，结果返回：｛－１，当前帖子ＩＤ，下一条帖子ＩＤ｝；
４）当前帖子是最后一篇帖子，结果返回：｛上一篇帖子ＩＤ，当前帖子ＩＤ，－１｝；
５）当前帖子前后都有帖子，结果返回：｛上一篇帖子ＩＤ，当前帖子ＩＤ，上一篇帖子ＩＤ｝；
写if语句时把最有可能的情况放在前面，于是为：
if 5 {
}else if 4{
}else if 3{
}else if 2{
}else{
}
在朋友数据缓存思想的灵感下，除了上面只取出邻近帖子ＩＤ的方法，我也想出了第三种处理方法：一次取出三条帖子的内容，并把这三条帖子统统存在Session中，这样，可以减少数据库连接的次数，但会稍微增加内存的开销，假设一条帖子平均１ＫＢ，增加两条帖子的内存增加２ＫＢ，１０个用户才增加２０ＫＢ，看来，这种方法也可以试一下吧。但是，一般的用户可能大多数时候还是从上到下的看帖子，也可以只取出当前这条帖子和下一条帖子的内容。
今天，我先把这个思路记在这里，暂不实现这个方法。先把整个导航系统运行起来。以后，系统优化的时候再统一考虑各种优化问题。否则，局部的优化也许会损害全局的性能也是有可能的吧？
２００５年１０月２７日
昨天，已经把在查看所有目标页面中的查看目标和日记的横向导航完成了。但是，在其它地方的横向导航需要根据导航封装客串得到它是来源于哪
里的，然后再根据这个得到Where clause 和 order by参数。下面对各种情况列一表：
类型 所在页面 导航特征字符串 where order
目标 所有目标 a10a3\\d+ typeID=1(IndexAtion,article表) sortGoalType(1)
目标 进行中的 a10a60a3\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType(2)
目标 退出的 a10a70a3\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType(3)
目标 完成的 a10a80a3\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType(4)
目标 检索的 a10ac0ae0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(5)
日记 所有目标 a10a2\\w+ typeID=2 AND parentID=?(DiaryAction,article表) sortDiaryType(6)
日记 进行全部日记 a10a60a2\\w+(与所有目标中的日记一样）(退出a10a70a2\\w+）(完成：a10a80a2\\w+)(7)
日记 进行我的日记 a10a60a0\\w+ typeID=2 parentID=? userID=?(MyDiaryAction,article表) sortMyDiaryType(退出a10a70a0\\w+)a80a0\\w+(8)
在退出和完成目标的日记与在进行中目标的日记同样(即退出、完成的全部和我的日记)
日记 检索中的日记 a10ac0ad0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchDiaryType
日记列表 检索 a10ac0ae0a2\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(与检索目标内容一样）
日记列表 所有目标 a10a2\\d+ typeID=1(IndexAtion,article表) sortGoalType(与１同）
以下是对应于目标的三种状态：只是把a3变成了a2和a0
日记列表 进行中的 a10a60a2\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
日记列表 退出的 a10a70a2\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
日记列表 完成的 a10a80a2\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
日记列表 进行中的我 a10a60a0\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
日记列表 退出的我 a10a70a0\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
日记列表 完成的我 a10a80a0\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
另外，检索日记中的日记所在目标和日记所在目标的日记列表暂不实现。
花了一晚上来做这个表，这么的罗列总结，是否有悖于计算机的自动化？是否设计思路有问题？我再想想。
１０月２９日
（待续）
昨天，有朋友给我介绍一下数据缓存技术。我把数据缓存技术看了一下，主要是把相关记录保存在一个双向链表中，并同时保存在一个HashMap中，用双向链表最新的数据保存在缓存中，在HashMap中快速检索数据。
数据缓存不能保持查询记录的固定顺序，所以不能用在上面横向导航的需求中。
而且，数据缓存是把常用的数据缓存在内存中，势必增加内存的开销，在学习日记现在的廉价空间中使用对网站的速度无疑是雪上加霜。
但是，数据缓存确实是个非常好的东西，它可以极大的加快常用数据的访问。在学习日记未来的版本中，可以考虑引入数据缓存技术。这样，可以加快常用目标的访问。例如：“公告”以及大家比较感兴趣的目标及其中的日记。
在这里，非常感谢向我介绍数据缓存技术的那位朋友。
good
横向导航需要提取当前页面所在的层次导航位置，昨天把特征码作了一个列表（见上面的日记），今天继续浓缩归类如下：
特征 类型 所在页面 导航特征字符串 where order
goal+a10a3 目标 所有目标 a10a3\\d+ typeID=1(IndexAtion,article表) sortGoalType(1)
goal+a6 目标 进行中的 a10a60a3\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType(2)
goal+a7 目标 退出的 a10a70a3\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType(3)
goal+a8 目标 完成的 a10a80a3\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType(4)
goal+ae 目标 检索的 a10ac0ae0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(5)
diary+a2 日记 所有目标 a10a2\\w+ typeID=2 AND parentID=?(DiaryAction,article表) sortDiaryType(6)
diary+a2 日记 进行全部日记 a10a60a2\\w+(与所有目标中的日记一样）(退出a10a70a2\\w+）(完成：a10a80a2\\w+)(7)
diary+a0 日记 进行我的日记 a10a60a0\\w+ typeID=2 parentID=? userID=?(MyDiaryAction,article表) sortMyDiaryType(退出a10a70a0\\w+)a80a0\\w+(8)
在退出和完成目标的日记与在进行中目标的日记同样(即退出、完成的全部和我的日记)
diary+ad 日记 检索中的日记 a10ac0ad0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchDiaryType
dl+ae 日记列表 检索 a10ac0ae0a2\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(与检索目标内容一样）
dl+a10a2 日记列表 所有目标 a10a2\\d+ typeID=1(IndexAtion,article表) sortGoalType(与１同）
以下是对应于目标的三种状态：只是把a3变成了a2和a0(因为要的是目标的前后ＩＤ，所以与目标的日记列表与目标的内容的横向导航是一样的。）
dl+a6 日记列表 进行中的 a10a60a2\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
dl+a7 日记列表 退出的 a10a70a2\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
dl+a8 日记列表 完成的 a10a80a2\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
dl+a6 日记列表 进行中的我 a10a60a0\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
dl+a7 日记列表 退出的我 a10a70a0\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
dl+a8 日记列表 完成的我 a10a80a0\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
另外，检索日记中的日记所在目标和日记所在目标的日记列表暂不实现。
昨天，已经把在查看所有目标页面中的查看目标和日记的横向导航完成了。但是，在其它地方的横向导航需要根据导航封装客串得到它是来源于哪里的，然后再根据这个得到Where clause 和 order by参数。下面对各种情况列一表：
特征 类型 所在页面 导航特征字符串 where order
1.goal+a10a3 目标 所有目标 a10a3\\d+ typeID=1(IndexAtion,article表) sortGoalType(1)
2.goal+a6 目标 进行中的 a10a60a3\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType(2)
3.goal+a7 目标 退出的 a10a70a3\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType(3)
4.goal+a8 目标 完成的 a10a80a3\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType(4)
5.goal+ae 目标 检索的 a10ac0ae0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(5)
6.diary+a2 日记 所有目标 a10a2\\w+ typeID=2 AND parentID=?(DiaryAction,article表) sortDiaryType(6)
7.diary+a2 日记 进行全部日记 a10a60a2\\w+(与所有目标中的日记一样）(退出a10a70a2\\w+）(完成：a10a80a2\\w+)(7)
8.diary+a0 日记 进行我的日记 a10a60a0\\w+ typeID=2 parentID=? userID=?(MyDiaryAction,article表) sortMyDiaryType(退出a10a70a0\\w+)a80a0\\w+(8)
在退出和完成目标的日记与在进行中目标的日记同样(即退出、完成的全部和我的日记)
9.diary+ad 日记 检索中的日记 a10ac0ad0a3\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchDiaryType
10.dl+ae 日记列表 检索目标 a10ac0ae0a2\\d+ condition参数在Session中(PostSearchAction,article表) sortSearchGoalType(与检索目标内容一样）
11.dl+a10a2 日记列表 所有目标 a10a2\\d+ typeID=1(IndexAtion,article表) sortGoalType(与１同）
以下是对应于目标的三种状态：只是把a3变成了a2和a0(因为要的是目标的前后ＩＤ，所以与目标的日记列表与目标的内容的横向导航是一样的。）
12.dl+a6 日记列表 进行中的 a10a60a2\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
13.dl+a7 日记列表 退出的 a10a70a2\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
14.dl+a8 日记列表 完成的 a10a80a2\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
15.dl+a6 日记列表 进行中的我 a10a60a0\\d+ userID=? state=?(ProcessGoalAction,usergoal表) sortMyProcessGoalType
16.dl+a7 日记列表 退出的我 a10a70a0\\d+ userID=? state=?(QuitedGoalAction,usergoal表) sortMyQuitGoalType
17.dl+a8 日记列表 完成的我 a10a80a0\\d+ userID=? state=?(FinishedGoalAction,usergoal表) sortMyFinishGoalType
另外，检索日记中的日记所在目标和日记所在目标的日记列表暂不实现。
花了一晚上来做这个表，这么的罗列总结，是否有悖于计算机的自动化？是否设计思路有问题？我再想想。
接着对上面的各种情况进行分析：
１、首先，需要导航的地方有三种情况：
１）、目标内容
２）、日记内容
３）、目标的日记列表
２、
１）、１的１）和２）需要放在DisGoalContentAction.java中处理；
２）、１的３）需要分在几个地方处理，分别是：
１》检索目标的日记列表，所有目标的日记列表，进行、完成、退出的日记列表：在DiaryAction.java中处理；
２》进行、完成、退出的我的日记列表：在MyDiaryAction.java中处理；
３、在几个Action中需要处理的情况：
１）、在DisGoalContentAction.java中，分２种情况：
１》在article表中查找，分为２种情况：
１》》检索的条目，where子句在session中；包括：５goal+ae，９diary+ad
２》》非检索的条目，where子句分别给出；１goal+a10a3，６diary+a2 ，７diary+a2 ，８diary+a0
２》用usergoal和article表联合查找，需要再重载一个方法,包括：２goal+a6，３goal+a7，４goal+a8
２）、在DiaryAction.java中，包括：１０dl+ae ，１１dl+a10a2 ，１２dl+a6 ，１３dl+a7 ，１４dl+a8
３）、在MyDiaryAction.java中，包括：１５dl+a6 ，１６dl+a7 ，１７dl+a8
下面就根据上面的分析开始编码。