会话保持仍是迷惑
专业向无知让步,总是带有额外的代价,区别只在于代价由谁来承担。使用病专栏替代首页,是chase没有网络常识,laura没有基本能力的妥协性产物。 实质上我做多了几件事:要使后台可以调置一个默认病专栏;要在前台特别协调;代价是一旦出现类似的变动就再次带有更大的成本。而如果使用一个首页就根本没 有这个问题。责任上说是laura的能力不足所致。
杨欠缺逻辑能力甚至可以从这样的语句看出来:(语句丢失,这个博客不能处理代码型的)
试问有必要吗?这是见其然不知其实的作品,换言之设定声明变量的用意他也没有理解。所以杨其实不是帮我而是帮laura,因为她连这个能力也没有。让他做的直接编辑病专栏一节也没有了,不过这个估计是由于覆盖造成的,开工后要重新让他做一次。
昨 天那个自动刷新功能是可以的,一晚都没有丢线;但是不知为什么,现在却是连连掉线。实验出现了不一致,也就不知该如何继续了。现在暂时改成刷新本页,应该 把握会变得大一点……仍是不行,自动刷新似乎无助于会话的保持.也许是由于meta 带来的自动刷新等同于告诉浏览器,不要保留会话。……仍是没有保留住会话。可能,这与最低时限有关系,低于某一界值的话,就无法通过刷新保持会话。而如果 可以保持会话的话,可能使用meta.refresh效果更佳。
section现在是一个base,但是使用方式却特别,用的是name 而不是id,这样潜藏着一个以前未涉及到的使用方式——基类是名字而不是ID。更 替到id是一个大工程,无疑id由于没有歧义,但也欠直观,紧简单的方式就是扩展baselect这类组件,令它可以支持名字的使用。
保险通知单现在还没有收到,不知是不是有点什么问题,象让那个王什么红的改掉了。要注意一下,这个月还是要把钱存进去的。
看来webadmin与普通科室的使用还是有很大区别的,难以合并。
www晚上似乎中断了一会,重启后发现会话极多;就象死循环。但没有发现有死循环,发现的几个错误地方也相应的修改了。本来打算连夜上去试验在线维持,但是操作失误,尽管恢复了过来,从保险起见,就暂进不更新www只对dep做功。
但是说到这里,又似乎有不妥的东西了——原来使用一个iframe是因为会话丢失。现在使用一个refreshmeta,把那个删除了,照理是不行的。但现在却是成功地登录了。这是什么意思呢?意味着和昨天的结论是相反的。到底是保持还是应该抛弃呢?
提高mysql连接数超过300的方法没有找到,记得是不允许的。使用samba转接出来也没有做,来不及了。