命名规范 约定优于配置 命名规则

一般是由一个单词 或者两个单词 组成
getXxx
setXxx
//bean的时候尽量不要用isXxx
delete 删除
update 更新
add/save 保存
find 查找
list

question

index  首页
config  站点设置
course  课程
teacher  教师
admin  管理员
uploadlesson  课件上传
student  学员
card  卡号
privacy  隐私设置
usergroup  用户组
credit  积分规则
profilefield  用户栏目
eventclass  线下活动分类
magic  道具设置
task  有奖任务
spam  防灌水设置
censor  词语屏蔽
network  随便看看
cache  缓存更新
log  系统log记录
space  用户
client
share  资源分享
blog  学习笔记
album  相册
pic  图片
comment  评论/留言
thread  话题
post  回帖
doing  记录
tag  标签
mtag  学习小组
poll  投票
event  线下活动
magiclog  道具记录
report  举报
block  数据调用
template  模板编辑
backup  数据备份
stat  统计更新
cron  系统计划任务
click  表态动作
defaultuser  默认好友设置
bulletin  公告信息
news  课程动态
wisdoms  名言警句
playset  播放器新闻
demo  试听课程
regstat  学员注册统计
listenstat  学员听课统计
onlinestat  学员在线统计
opencoursestat  开课统计
addtimesstat  增加听课次数
forbiduserstat 禁用学员统计
deleteuserstat 删除学员统计

数据库中的

0 代表 false
1 代表 true


以下QQ命名规范
GroupFriendFeeds 好友动态
GroupSpecialCare 特别关心
GroupAboutHost  与我相关
AppTitle 我的应用
AppStoreEntry 应用中心

show_applist_right 向右展示应用列表
AppListContainer





struts项目 通配符 中 命 名


第一个*为分类名称，第二个*为方法名
我采用的是 类名大写 方法名小写
jsp适应通配符







jsp 小写
action 小写

或者

jsp java类名
action java类名
或者

jsp Java方法名
action Java方法名

但是这里还是回到JSP文件和action-mapping的path命名去吧。个人认为应该遵循Java文件，也就是Java类名的命名规范：所有单词首字母大写。


以下为转的内容

struts项目中的JSP文件命名问题

受Java中方法名及属性名的命名规范影响，在前三个struts项目中制定jsp文件名命名规范时，沿用了方法名及属性名的规范，即首字母小写；同时想着Web服务器或应用服务器对文件名的大小写是敏感的，为了避免用户输入URL时出错，于是将jsp文件名全部设定为小写；为了增加文件名的可读性，允许适当在单词间增加下划线"_"。
　　但是，在制定命名规范时，还有很多东西没有考虑到：
　　1、在struts项目中，用户更多的是通过struts-config.xml等配置文件所配置的action-mapping的path来访问的；
　　2、在struts 1.2支持通配符后，小写的JSP文件名却导致项目无法使用struts1.2的这个最新且能带来更高工作效率的特性；
　　3、。。。
　　X、推荐一篇与本文仅有一点相关的文章：Friendly URL应当作为web2.0应用首先要考虑的问题。

　　从第1点和第X点可知，这不仅仅是JSP文件的命名问题，而是和项目整个URL有关，包括action-mapping的path，以及各种资源文件等。但是这里还是回到JSP文件和action-mapping的path命名去吧。个人认为应该遵循Java文件，也就是Java类名的命名规范：所有单词首字母大写。
　　但是，JSP文件夹的命名呢？难道是参照包的命令，全部小写吗？但是觉得URL上会比较别扭，再一个但是，域名一般都习惯使用全部小写的了，应该没关系吧。。。













Friendly URL应当作为web2.0应用首先要考虑的问题

web2.0概念的提出给这个灰暗的web应用世界带来了鲜活的色彩；而ajax的使用又给用户提供了更好的操作体验。然而，在具体的使用上，他们 给开发者带来的考虑不是更少而是更多。ajax滥用比不用更加可恶——满屏的loading实在不是什么好的体验。如何真正给用户提供真正易于理解舒心畅 快的应用，是2.0应用开发者首先需要考虑的问题。

OPOA提出后，我一直在考虑一个问题：如何将操作型应用与内容型应用有机的结合起来呢？这个问题的提出并非空穴来风。实际上，除了类似于邮件这样 的简单应用不需要考虑友好URL之外，大部分web应用，无论是企业应用还是面向消费者的 web2.0应用，都存在面对友好URL的问题。例如：到底是portal/index.action?userid=10001比较好看还是 portal/michaelchen比较好看？到底是michaelchen/photo/12319 比较容易懂还是 photo/viewPhoto.action?userid=10001&photoid=12319 比较容易懂？

答案是很容易看明白，一个好的URL不应该经常变动。

一个典型的web2.0应用在URL上首先是友好的：看看成功的应用大多如此：Flickr, del.icio.us, 豆瓣，等等。体贴的URL为传播、共享、搜索提供了潜在的巨大的便利，只有那些操作型应用系统才不需要考虑URL的组织方式。

因此，一个典型的web2.0应用，首先要考虑的是如何组织对外的URL——这个URL规则一旦建立，以后要进行变更的可能性就比较小（因为成本巨 大，无数 的人链接到了这个地址）。你可能采用某一个独立的模块来对这一部分进行维护。遗憾的是，传统的J2EE框架在这方面所做的事情少之又少，无论是 webwork还是struts, 都没有明显的对这方面的支持（所以说用这类框架做web2.0应用很痛苦）；tapestry相对好一些，在4.0中可以对url进行定制。另外UrlRewriteFilter对传统应用进行了修饰，但遗憾的是，怎么用怎么感觉不太好。

如何解决？我能想到的一个比较清晰的架构是：从一开始就考虑URL的结构，采用一个独立的servlet来管理URL链接，它的功能与 UrlRewriteFilter类似，但是它的结合点不是类似于product.action?id=xxx路径本身，而是直接指向相对应需要运行的 Struts/Webwork Action（或者Spring MVC的Controller）。

下午的时候无意中看到了django, 这个新型的类似于rails的快速开发框架，显然更懂web2.0——直接有了一个urls.py文件来对各类url映射进行配置，能够直接将某一个正则表达式支持的路径映射到一个执行的方法：

[python]
patterns = patterns(”,
(r’^blog/$’, ‘blog.views.page’),
(r’^blog/page(?P\d+)/$’, ‘blog.views.page’),
)

# View (in blog/views.py)
def page(request, num=”1″):
# Output the appropriate page of blog entries, according to num.
[/python]

上面的例子是不是能够给我们带来一些启发？

写到这里，我有了一些结论：一个完整的web2.0应用结构上应当包含两部分：URL处理引擎和Ajax引擎。前者用于在整个WWW范围内共享传 播，后者用于改善单个用户的操作体验。这样，架构渐渐完整和清晰了。不得不说的是，目前我还没有看到任何一个JavaEE web框架明显的独立出url处理引擎的概念，tapestry做了一些，但还不够独立，SpringMVC/Webwork/Struts更不提。也许 这与java在企业应用漫长的时间有关，但是在现在，这些框架已经表现出落后了。是不是buffalo应该做这件事情呢？