<link rel="stylesheet" type="text/css" href="<ww:url value="/layout/css/style.css"/>">
<link rel="stylesheet" type="text/css" href="<ww:url value="/layout/css/thickbox.css"/>" media="screen">
<script type="text/javascript" src="<ww:url value="/layout/js/jquery-latest.js"/>"></script>
<script type="text/javascript" src="<ww:url value="/layout/js/thickbox.js"/>"></script>
<script type="text/javascript" src="<ww:url value="/layout/js/wingel.js"/>"></script>
<decorator:head/>

然后在要验证的Form里面加个属性validatable=true,如下åQ?br />

<form id="registerForm" action="user-register.action" validatable="true">

注意åQŒè¿™è¾¹ä¸è¦åŠ onsubmitæ–ÒŽ³•

接下来，ž®±å¥½äº†ï¼Œæ¯”如说有个输入框åQ?br /><ww:textfield name="name" id="name"/>
我想验证åQŒè®©å®ƒå¿…填，如下ž®±å¯ä»¥äº†åQ?br /><label for="name" validate="required">请填写名¿U?lt;/label>  其中 for属性里面填的要是验证的输入框idåQŒvalidate填的是验证方æ³?;label里面的文本就是验证不˜q‡çš„时候要昄¡¤ºçš„信息ã€?br />如果我想验证一个输入框的输入值长度怎么办，˜q™æ ·å­å°±è¡Œäº†

<label for="password" validate="lengthRange:6;20">

后面的参数用åQ›å·éš”å¼€åQŒéªŒè¯çš„æ–ÒŽ³•åè·Ÿå‚æ•°ç”? 隔开ã€?br />wingel.js里面已经包括了一些常用的验证æ–ÒŽ³•åQŒçŽ°åœ¨é—®é¢˜æ¥äº†ï¼Œå¦‚果要自定义验证æ–ÒŽ³•æ€Žä¹ˆåŠžï¼Œå¦‚下办：
比如你想加个验证æ–ÒŽ³•æ˜¯hello
则label里面的validate属性写成hello,
然后加一个JavaScriptæ–ÒŽ³•åQ?br />

<script type="text/javascript">
    wingel.validator.rules.hello= function(value, element, parameters,utility) ...{
             ...    }
</script>

里面三个参数,shit , couldn't input Chinese. now English will be used.

The first parameter is the value of the input element you want to validate,the second one is the validated element, the third one, is the parameters you add in validate label, the last one, is a utility class, you can invoke its method to make your code easier.

PROPAGATION_MANDATORY:
 Indicates that the method must run within a transaction. If no
 existing transaction is in progress, an exception will be thrown.

PROPAGATION_NESTED:
 Indicates that the method should be run within a nested transaction
 if an existing transaction is in progress. The nested transaction
 can be committed and rolled back individually from the enclosing
 transaction. If no enclosing transaction exists, behaves like
PROPAGATION_REQUIRED:
 Beware that vendor support for this propagation behavior is spotty at best.
 Consult the documentation for your resource  manager to determine if nested
 transactions are supported.
PROPAGATION_NEVER:
 Indicates that the current method should not run within a transactional
 context. If there is an existing transaction in progress, an
 exception will be thrown.
PROPAGATION_NOT_SUPPORTED:
 Indicates that the method should not run within a transaction. If an
 existing transaction is in progress, it will be suspended for the
 duration of the method. If using JTATransactionManager,
 access to TransactionManager is required.
PROPAGATION_REQUIRED:
 Indicates that the current method must run within a transaction. If
 an existing transaction is in progress, the method will run within
 that transaction. Otherwise, a new transaction will be started.
PROPAGATION_REQUIRES_NEW:
 Indicates that the current method must run within its own transaction.
 A new transaction is started and if an existing transaction is in
 progress, it will be suspended for the duration of the method. If
 using JTATransactionManager, access to Transaction-
 Manager is required.
PROPAGATION_SUPPORTS:
 Indicates that the current method does not require a transactional
 context, but may run within a transaction if one is already in
 progress.

Isolation levels:
In a typical application, multiple transactions run concurrently, often working
with the same data to get their job done. Concurrency, while necessary, can lead
to the following problems:
 â–?Dirty read—Dirty reads occur when one transaction reads data that has
 been written but not yet committed by another transaction. If the
 changes are later rolled back, the data obtained by the first transaction
 will be invalid.
 â–?Nonrepeatable read—Nonrepeatable reads happen when a transaction performs
 the same query two or more times and each time the data is different.
 This is usually due to another concurrent transaction updating the
 data between the queries.
 â–?Phantom reads—Phantom reads are similar to nonrepeatable reads. These
 occur when a transaction (T1) reads several rows, then a concurrent transaction
 (T2) inserts rows. Upon subsequent queries, the first transaction
 (T1) finds additional rows that were not there before.

Isolation level:
ISOLATION_DEFAULT:
 Use the default isolation level of the underlying datastore.
ISOLATION_READ_UNCOMMITTED:
 Allows you to read changes that have not yet been committed. May
 result in dirty reads, phantom reads, and nonrepeatable reads.
ISOLATION_READ_COMMITTED:
 Allows reads from concurrent transactions that have been committed.
 Dirty reads are prevented, but phantom and nonrepeatable
 reads may still occur.
ISOLATION_REPEATABLE_READ:
 Multiple reads of the same field will yield the same results, unless
 changed by the transaction itself. Dirty reads and nonrepeatable
 reads are prevented by phantom reads may still occur.
ISOLATION_SERIALIZABLE:
 This fully ACID-compliant isolation level ensures that dirty reads,
 nonrepeatable reads, and phantom reads are all prevented. This is
 the slowest of all isolation levels because it is typically accomplished
 by doing full table locks on the tables involved in the transaction. 

    做着做着的时候，发现åQŒå’¦åQŒå¥½åƒè¿™è¡¨å¾—增加一个字ŒD‰|‰è¡Œï¼Œå¢žåŠ äº†ï¼Œç„¶åŽæ‰€æœ‰æŸ¥è¯¢çš„SQL语句加一下，所有insertè·Ÿupdate的代码修改一下，™åµé¢ä¿®æ”¹ä¸€ä¸‹ï¼Œå—¯ï¼ŒçŽ°åœ¨åº”该正常了，看è“v来倒是没什么问题，咦，报表好像不怎么对啊åQŒé åQŒè¿™è¾¹è¿˜æœ‰è°ƒç”¨è¿™ä¸ªè¡¨çš„代码，妈的åQŒæ”¹å§æ”¹å§ã€‚磨íy­äº†å¥½å‡ ä¸ªå°æ—Óž¼ˆå½“然åQŒç†Ÿ¾lƒçš„话，òq¶ä¸ç”¨å‡ ä¸ªå°æ—Óž¼‰åQŒæ€È®—看è“v来都正常了ã€?/p>

    ˜q™ä¸€å›žï¼Œ˜q™ä¸ªåŠŸèƒ½ä¸­æœ‰ä¸€‹Æ¡ç”¨æˆ¯‚¯·æ±‚，讉K—®äº†å¥½å‡ æ¬¡æ•°æ®åº“，不行åQŒè¿™é‡Œåº”该用个cacheåQŒå¦åˆ™æ€§èƒ½ä¸Šä¼šæœ‰é—®é¢˜å•ŠåQŒç®—了，用算法解决一下，ž®½é‡ž®‘访问数据库好了åQŒæˆ‘对cache˜q˜ä¸ç†Ÿå‘¢ã€‚（写啊写啊åQŒBatch SizeåQŒè¿™æ ·å¤šåQŒé‚£æ ·å¤šåQŒFetch Size。。。，¾lˆäºŽåQŒçœ‹èµäh¥æ­£å¸¸ä¸€äº›äº†åQ‰ã€‚过了一ŒD‰|—¶é—ß_¼Œé ï¼Œ˜q™è¾¹åˆè¦è®‰K—®å¥½å‡ ‹Æ¡æ•°æ®åº“åQŒYa的受不鸟了，性能爱咋的咋的，反正一个地æ–ÒŽ…¢åˆä¸è¦ç´§ã€‚Oh shit!!!˜q™è¾¹ä¹Ÿæ˜¯å¥½å‡ ‹Æ¡ï¼Œ˜q™è¾¹åˆæ˜¯å¥½å‡ ‹Æ¡ï¼Œé‚£è¾¹åˆæ˜¯å¥½å‡ ‹Æ¡ã€‚不行了åQŒæˆ‘老老实实写个cache支持吧，于是又叮叮当当了好几天，¾lˆäºŽåQŒæœ‰ä¸ªç²—¾p™çš„cache出来了，¾lˆäºŽé€Ÿåº¦å¯ä»¥çœ‹ä¸€äº›äº†ã€‚后来改˜q›åˆæ”¹è¿›åQŒæµ‹è¯•åˆ‹¹‹è¯•åQŒç¯æ­ÖMº†åQŒè€å­å¥½ä¸çˆ½å•Šã€?/p>

    好像天下有点太åã^了，啊，你说我这个地方忘记更æ–îC½ å¢žåŠ çš„那个子表啊åQŒç®—了，没关¾p»ï¼Œæˆ‘明天看一下代码，˜q™ä¸ªå®ÒŽ˜“解决炏V€‚å—¯åQŒæˆ‘改了那边的代码了åQŒä¼šæ›´æ–°å­è¡¨ä¿¡æ¯äº†ã€‚什么？你说取主表的记录跟相应的子表记录列表éºÈƒ¦å•Šï¼Œæ²¡å…³¾p»ï¼Œæˆ‘æ›´æ–îC¸€ä¸‹å¤„理resultset的公共模块，明天再说ã€?br />    Oh shit......对这样子复杂的查询好像现在的公共模块支持不了啊，½Ž—了åQŒè¿™æ ·å­çš„查询不要用˜q™ä¸ªå…¬å…±æ¨¡å—åQŒæˆ‘们手动写一些代码好啊，别跟我讲˜q™æ ·ä»£ç ¾l“构很难看，你以为我不知道啊åQŒTMDã€?/p>

    TMD的，怎么˜q™è¾¹çš„SQL老是˜qè¡Œä¸äº†å•Šï¼Œä¸ä¼šæ˜¯åˆ†™åµåº•å±‚模块的问题吧，靠，怎么你的SQL语句有这么多order,group byåQŒé åQŒè¿˜æœ‰top啊，˜q™å½“然过不了了，不要吵了åQŒçŽ°åœ¨æ—¶é—´æ”¹åQŒä¸ç†å®ƒåQŒç›´æŽ¥ç”¨ä¸ªå‡åˆ†é¡µž®Þp¡Œäº†ã€‚你又说代码¾l“æž„éš„¡œ‹åQŒå°å¿ƒæˆ‘抽你哦ã€?/p>

    公司新来一个程序员åQŒçœ‹äº†å‡ å¤©ä»£ç ï¼Œä¸åœçš„抱怨说åQŒè¿™ä»£ç å†™å¾—真差啊。。。。。ã€?nbsp;

PROPAGATION_MANDATORY:
 Indicates that the method must run within a transaction. If no
 existing transaction is in progress, an exception will be thrown.

PROPAGATION_NESTED:
 Indicates that the method should be run within a nested transaction
 if an existing transaction is in progress. The nested transaction
 can be committed and rolled back individually from the enclosing
 transaction. If no enclosing transaction exists, behaves like
PROPAGATION_REQUIRED:
 Beware that vendor support for this propagation behavior is spotty at best.
 Consult the documentation for your resource  manager to determine if nested
 transactions are supported.
PROPAGATION_NEVER:
 Indicates that the current method should not run within a transactional
 context. If there is an existing transaction in progress, an
 exception will be thrown.
PROPAGATION_NOT_SUPPORTED:
 Indicates that the method should not run within a transaction. If an
 existing transaction is in progress, it will be suspended for the
 duration of the method. If using JTATransactionManager,
 access to TransactionManager is required.
PROPAGATION_REQUIRED:
 Indicates that the current method must run within a transaction. If
 an existing transaction is in progress, the method will run within
 that transaction. Otherwise, a new transaction will be started.
PROPAGATION_REQUIRES_NEW:
 Indicates that the current method must run within its own transaction.
 A new transaction is started and if an existing transaction is in
 progress, it will be suspended for the duration of the method. If
 using JTATransactionManager, access to Transaction-
 Manager is required.
PROPAGATION_SUPPORTS:
 Indicates that the current method does not require a transactional
 context, but may run within a transaction if one is already in
 progress.

Isolation levels:
In a typical application, multiple transactions run concurrently, often working
with the same data to get their job done. Concurrency, while necessary, can lead
to the following problems:
 â–?Dirty read—Dirty reads occur when one transaction reads data that has
 been written but not yet committed by another transaction. If the
 changes are later rolled back, the data obtained by the first transaction
 will be invalid.
 â–?Nonrepeatable read—Nonrepeatable reads happen when a transaction performs
 the same query two or more times and each time the data is different.
 This is usually due to another concurrent transaction updating the
 data between the queries.
 â–?Phantom reads—Phantom reads are similar to nonrepeatable reads. These
 occur when a transaction (T1) reads several rows, then a concurrent transaction
 (T2) inserts rows. Upon subsequent queries, the first transaction
 (T1) finds additional rows that were not there before.

Isolation level:
ISOLATION_DEFAULT:
 Use the default isolation level of the underlying datastore.
ISOLATION_READ_UNCOMMITTED:
 Allows you to read changes that have not yet been committed. May
 result in dirty reads, phantom reads, and nonrepeatable reads.
ISOLATION_READ_COMMITTED:
 Allows reads from concurrent transactions that have been committed.
 Dirty reads are prevented, but phantom and nonrepeatable
 reads may still occur.
ISOLATION_REPEATABLE_READ:
 Multiple reads of the same field will yield the same results, unless
 changed by the transaction itself. Dirty reads and nonrepeatable
 reads are prevented by phantom reads may still occur.
ISOLATION_SERIALIZABLE:
 This fully ACID-compliant isolation level ensures that dirty reads,
 nonrepeatable reads, and phantom reads are all prevented. This is
 the slowest of all isolation levels because it is typically accomplished
 by doing full table locks on the tables involved in the transaction.