游乐游手机版
首页/前端开发/文章详情

Ext JS 4实现带星期的日期选择控件实战二

时间:2026-06-17 06:46
在深入之前,不妨先回顾一下:如果您尚未阅读前两篇关于 JavaScript 日期时间基础以及 Ext JS 4 日期控件扩展的实战文章,建议先查阅。简单来说,JavaScript 的 Date 对象是处理时间的核心工具,但它并不直接提供“周序号”这一信息。要在前端通过 JS 计算某天属于当年第几周,

Ext JS 4实现带week(星期)的日期选择控件(实战二)

在深入之前,不妨先回顾一下:如果您尚未阅读前两篇关于 JavaScript 日期时间基础以及 Ext JS 4 日期控件扩展的实战文章,建议先查阅。简单来说,JavaScript 的 Date 对象是处理时间的核心工具,但它并不直接提供“周序号”这一信息。要在前端通过 JS 计算某天属于当年第几周,需要借助特定算法。好在很多前端库(如 jQuery 扩展、Ext JS 等)已经封装了此类方法。Ext JS 提供了 Ext.Date.getWeekOfYear(date),使用起来非常便捷。

问题所在

那么,直接使用 Ext JS 就能完美解决星期显示问题吗?

本系列第一篇曾提到,Ext 的 datepicker 默认不显示星期信息,需要开发者自行扩展。但在扩展过程中,会遇到一个根本性的矛盾:JavaScript 的 Date 对象规定每周从星期天开始(0 = 星期天),而 Ext JS 的 getWeekOfYear 方法却遵循 ISO-8601 标准,每周从星期一开始。更令人困惑的是,Ext JS 内部混用了不同的日期标准——部分方法遵循 ISO,部分则不是。

具体来说,Ext.Date.getWeekOfYear 返回的是 1~53 的整数。但问题在于:Ext 的日期控件默认按星期天到星期六排列(S M T W T F S),而计算周号时却按星期一开始。结果导致两个明显的坑:

  • 星期天的周号少 1。例如 2013 年 8 月 18 日是星期天,本应是第 34 周,但 getWeekOfYear 将其算作上一周的结尾——第 33 周。
  • 跨年时周号归属混乱。由于日期控件默认显示 42 天(6 周),年底最后几天可能被算作下一年的第 1 周,或者当年第 53 周,逻辑不统一。
date = new Date("2013/08/18");
var week = Ext.Date.getWeekOfYear(date);
alert("week="+week);

解决方案

既然标准存在冲突,那就自行封装。结合 JavaScript 的 Date 对象和 Ext JS 的 Ext.Date,编写一个获取星期字符串的函数。核心规则只有三条:

  1. 每周以星期天为第一天,与控件显示保持一致。
  2. 每年的周数范围定义为 1~52,如果计算超过 52 周,则归入下一年的第 1 周(例如 2013 年 12 月 29 日本是第 53 周,直接记为 2014 年第 1 周)。
  3. 返回形如 “W1334” 的格式(W + 年份后两位 + 两位周号)。
/*
 * 返回格式如 W1334(对应 2013/08/20)
 * 规则:
 * 1. 如果是星期天,周号加1(因为 Ext.getWeekOfYear 使用 ISO-8601,周一为一周开始,而 JS Date 周日为一周开始)
 * 2. 如果周号大于52,则年份加1,周号减52
 * 3. 如果是12月且周号小于2,则年份加1
 */
function getWeekStrOfDate(date) {
    var weekStr = null;
    if (date != null) {
        weekStr = "W";
        var dateYear = date.getFullYear();
        var dateWeek = Ext.Date.getWeekOfYear(date);
        var firstDayOfMonth = Ext.Date.getFirstDayOfMonth(date);
        var day = date.getDate();
        var month = date.getMonth();
        // weekday 0-6
        var weekday = date.getDay();
        if (weekday === 0) {
            dateWeek++;
        }

        // week > 52 => year +1
        if (month == 11) {
            if (dateWeek > 52) {
                dateYear += 1;
                dateWeek -= 52;
            } else if (dateWeek < 2) {
                dateYear += 1;
            }
        }
        var yearStr = dateYear.toString();
        yearStr = yearStr.substring(2, 4);
        var dateWeekStr = dateWeek.toString();
        if (dateWeekStr.length < 2) {
            dateWeekStr = "0" + dateWeekStr;
        }
        weekStr += yearStr;
        weekStr += dateWeekStr;
    }
    return weekStr;
}

这样一来,日期控件上显示的星期与实际计算出的周号就能准确对齐了。关键是理解“星期天加1”以及“年末跨年”的处理逻辑,其他细节可根据具体业务场景灵活调整。

来源:https://www.jb51.net/article/40757.htm
上一篇Angular获取ngIf条件渲染DOM元素示例 下一篇Angular路由常用类详解
本站内容用于信息整理与展示,如有侵权或内容问题请及时联系处理。

相关推荐

补充同频道和同主题内容,方便继续浏览更多相关内容。

同类最新

继续查看同栏目最近更新的文章。

更多
Vue应用中异步更新性能问题的优化策略详解
前端开发 · 2026-07-03

Vue应用中异步更新性能问题的优化策略详解

先来看一个令许多开发者感到困惑的场景:明明修改了数据,DOM 却“毫无反应”,无法获取最新的高度,也无法计算正确的坐标。这并非 Vue 的缺陷,反而是它精心设计的性能优化策略。核心在于——你需要学会与它“异步更新”的特性协作,而非硬碰硬。 所谓的“异步更新性能问题”,本质上是一种认知偏差。Vue 的

如何避免原型对象挂载大体积动态数组内存污染
前端开发 · 2026-07-03

如何避免原型对象挂载大体积动态数组内存污染

原型链上的大数组:一个隐蔽的内存冲击波 先给个核心判断:直接在原型对象上挂载一个大体积动态数组,这既不是传统意义上的内存“污染”,也不是安全漏洞那种“污染”,而是一种相当隐蔽但后果严重的内存管理失当。它会导致所有实例共享同一份数据,而且正因为生命周期跟整个原型链绑定得太紧,垃圾回收器(GC)根本看不

利用堆栈信息精准定位显式绑定错误对象致未定义异常
前端开发 · 2026-07-03

利用堆栈信息精准定位显式绑定错误对象致未定义异常

深入追踪:显式绑定传错对象引发的未定义异常 说实话,这类问题在JavaScript开发中相当常见——显式绑定传错了对象,然后方法执行时静默失败、访问undefined、或者抛出TypeError。但真正的难点不在于“报了什么错”,而在于“到底是哪个对象被绑错了”。要解决它,需要跳出堆栈的表层报错信息

ES模块中默认导出和具名导出的执行上下文
前端开发 · 2026-07-03

ES模块中默认导出和具名导出的执行上下文

export default 与具名导出在 ES Module 中的行为机制截然不同,核心差异不在于“值如何传递”,而在于绑定如何建立以及导入时如何使用。先给出总结性结论,再逐一详细拆解。 export default 是一种语法糖,而非真正的变量声明 这种设计容易引起误解。实际上,export d

详解HTML中iframe标签loading=lazy属性实现嵌入内容懒加载方法
前端开发 · 2026-07-03

详解HTML中iframe标签loading=lazy属性实现嵌入内容懒加载方法

先聊聊 loading= "lazy " 这个属性——它本意是让 iframe 实现延迟加载,但实际落地时常常“失效”。这并非程序漏洞,而是浏览器内置的防御机制:只有所有条件同时触发,它才会真正推迟资源请求。比如 src 必须是跨域地址(类似 https: widget example com emb