亚洲欧洲日本精品,亚洲VA中文字幕无码一二三区,中文字幕亚洲天堂

Setting the conversation-timeout in Seam, why it really does work

seal — Mon, 19 Apr 2010 16:36:00 GMT

Conversation timeout seems to be a commonly misunderstood Seam concept. I often see postings on the Seam forums claiming that the conversation-timeout doesn’t work! Well, actually it does, you simply have to understand the semantics.

Configuring the conversation-timeout period can be accomplished through the following in your components.xml:

At first glance most developers relate conversation-timeout to session timeout, where any conversation will simply timeout after the configured conversation timeout period. As you will quickly notice during testing, this is not the case. To execute a quick experiment, try the following configuration in the components.xml of the seam-booking example:

Because the conversation-timeout is set in milliseconds, the above configuration sets the conversation-timeout to 1 minute. Now in the web.xml set the session timeout to 5 minutes:

Now in the destroy method of the HotelBookingAction add the following line:

...

@Destroy @Remove

public void destroy() {

log.info("Destroying HotelBookingAction...");

}

...

This will log our message when the conversation ends and the HotelBookingAction is destroyed. Now deploy the seam-booking example to your local JBoss instance and start up a conversation. This can be accomplished by logging in, navigating to the hotels listing, and selecting a hotel for booking. At this point, wait for the 1 minute period… nothing happens. Now wait for another 4 minutes, the message is displayed. The conversation timed out along with the session.

Foreground vs. Background Conversations

So why didn’t our conversation timeout as configured? This is because the conversation-timeout only affects background conversations. The foreground conversation will only timeout when the session times out. Foreground, background, what? The foreground conversation is the conversation that the user last interacted with. A background conversation is any other conversation in the user’s session. Thus, in our previous scenario the foreground conversation timed out with the session as expected.

Now lets try another approach. Perform the same steps as before to proceed to the booking screen. Now open a new window and perform the same steps. We now have a foreground conversation and a background conversation in progress. Again, wait 1 minute. Nothing happened. If you wait an additional 4 minutes, both conversations will timeout. So what is going on here, I thought we had a background conversation? We did, Seam simply checks the conversation timeout on each request. Thus, if I interact with the foreground conversation after 1 minute, the background conversation times out. Try it, perform the same steps, wait 1 minute and then click on the window of the foreground conversation and you will see the log message.

This is very desirable behavior. Essentially when a user leaves his or her desk for a period of time and comes back, if the session is still active it would be desirable to maintain the state the user was previously in. This is the foreground conversation state. All other background conversation state is left to timeout after the configured conversation-timeout period which reduces overall memory consumption. This enables a developer to think less about memory usage and cleaning up state and more about developing business logic. That’s why we’re here right?

Letting the user choose

So you may be asking at this point why the conversation-timeout doesn’t use polling. As we said, you must interact with the foreground conversation to cause the background conversations to timeout after the conversation-timeout period. Imagine that the user had many windows open and leaves his or her desk. Based on which window the user clicks on when they return, that becomes the foreground conversation timing out any other background conversations. This gives the user a chance to resume whichever conversation he or she chooses, not the one the developer chooses.

seal 2010-04-20 00:36 发表评论

javascript CDATA的意�?

seal — Mon, 07 Dec 2009 02:04:00 GMT

CDATA 内部的所有东襉K��会被解析器忽略�?/p>

假如文本中包含了大量�?"<" �?"&" 字符 - ��像�~�程代码中经常出现的情况一�?- 那么�q�个 XML 元素��可以被定义��Z��?CDATA 部分�?/p>

CDATA 区段开始于 ""�Q?/p>

在上面的例子中，�?CDATA 区段中的所有东襉K��会被解析器忽略�?/p>

关于 CDATA 区段的注�?

CDATA 区段不能包含字符�?"]]>"�Q�所以，CDATA 区段的嵌套是不被允许的�?/p>

同时也需要确保在 "]]>" 字符串中没有�I�格或折行�?/p>

��Z��么要使用CDATA:

XHTML的第二个改变是��用CDATA�D�c��XML中的CDATA�D는�于声明不应被解析为标�{��文本�Q�XHTML也是如此�Q�，�q�样��可以��用特�D�字�W�，�? ��于�Q?lt;�Q�、大于（>�Q�、和��P��&�Q�和双引��P��"�Q�，而不必��用它们的字符实体。考虑下面的代码：

�q�个函数相当��单，它比较数字a和b�Q�然后显�C�消息说明它们的关系。但是，在XHTML中，�q�段代码是无效的�Q�因为它使用了三个特�D�符��P��卛_��于�? 大于和双引号。要修正�q�个问题�Q�必��d��别用�q�三个字�W�的XML实体<�?amp;gt;�?amp;quot;替换它们�Q?/p>

�q�段代码存在两个问题。首先，开发者不习惯用XML实体�~�写代码。这使代码很难读懂。其�ơ，在JavaScript中，�q�种代码实际上将视�ؓ有语�? 错，因�ؓ解释�E�序不知道XML实体的意思。用CDATA�D�即可以以常规�Ş式（��x��ȝ��语法�Q�编写JavaScript代码。正式加入CDATA�D늚��Ҏ��? 下：

虽然�q�是正式方式�Q�但�q�要��C��Q�大多数��览器都不完全支持XHTML�Q�这��带来主要问题，卌��在JavaScript中是个语法错误，因�ؓ大多数浏览器�q�不认识CDATA�D�c�?/p>

当前使用的解��x��案模仿了“�Ҏ��览器隐�?#8221;代码的方法。��用单行的JavaScript注释"http://"�Q�可在不影响代码语法的情况下嵌入CDATA�D�：

现在�Q�这�D�代码在不支持XHTML的浏览器中也可运行�?/p>

但是�Q��ؓ避免CDATA的问题，最好还是用外部文�g引入JavaScript代码�?/p>

seal 2009-12-07 10:04 发表评论

seal — Wed, 28 Oct 2009 00:11:00 GMT

在页面中使用了richfaces和prototype�Q�结果在IE下一直报错，后来发现richfaces的文档中已经标注了此问题�Q?br />

1.74. Why does Java Script conflict?

Richfaces 3.1.3 uses 1.6.0 version of prototype.js script instead of 1.5.1 that's been used for earlier versions. There are 2 prototype versions included (the first included implicitly as a dependency of toggle panel components and the second one included explicitly as a link). Versions conflict is the cause of the problem.

RichFaces 3.1.3 is bundled with the same ones as Prototype 1.6.0, Scriptaculous 1.8.0

Example in web.xml::



...







    org.richfaces.ExcludeScripts



    Prototype,Scriptaculous







...

RichFaces components use Prototype very hard. In particular, some patches has been removed that are already included into 1.6.0. Adding feature with exclusion makes it possible to use Prototype with version less than 1.6.0. This will break some of the components.

seal 2009-10-28 08:11 发表评论

Seam扩展事务消息

seal — Fri, 23 Oct 2009 02:40:00 GMT

当事务成功之后（调用 persist()�?tt>update() �?remove() 成功后）�Q�Home对象会发��Z��?org.jboss.seam.afterTransactionSuccess 事�g�? 通过监听�q�一事�g�Q�我们可以在底层实体改变后，��h��查询�? 如果我们只需要在特定的实体保存、修�Ҏ��删除后刷新特定查询，我们可以监视 org.jboss.seam.afterTransactionSuccess. 事�g�Q?tt> 是实体的名字�Q��?

当一个操作成功时�Q�Home对象可以自动地显�C�Faces信息�Q�我们可以再一�ơ通过配置来定制信息�?


value="#{personHome.instance}"/>




entity-class="eg.Person"

new-instance="#{newPerson}">

New person #{person.firstName} #{person.lastName} created

Person #{person.firstName} #{person.lastName} deleted

Person #{person.firstName} #{person.lastName} updated






class="eg.Person">

#{country}

或者扩展：

@Name("personHome")

public class PersonHome extends EntityHome {



@In Country country;



@Factory("person")

public Person initPerson() { return getInstance(); }



protected Person createInstance() {

return new Person(country);

}



protected String getCreatedMessage() { return "New person #{person.firstName} #{person.lastName} created"; }

protected String getUpdatedMessage() { return "Person #{person.firstName} #{person.lastName} updated"; }

protected String getDeletedMessage() { return "Person #{person.firstName} #{person.lastName} deleted"; }



}

但是指定信息最好的�Ҏ��是把信息�|�于Seam所知的resource bundle中（在默认情况下�Q�这个bundle叫做 messages �Q��?

Person_created=New person #{person.firstName} #{person.lastName} created

Person_deleted=Person #{person.firstName} #{person.lastName} deleted

Person_updated=Person #{person.firstName} #{person.lastName} updated

�q�样方便�q�行国际化，从表现层的角度考虑也保持了代码和配�|�的整洁�?

最后一步是使用 �? 向页面中��d��验证功能�Q�我会把�q�个留给你们自己��d��现�?

seal 2009-10-23 10:40 发表评论

解决Safari中Richfaces某些�l��g不兼容的问题

seal — Tue, 22 Sep 2009 01:56:00 GMT

在项目中使用safari��试richfaces生成的页面时�Q�发现在一个文本框中输入html标签�Q�整个页面就会崩溃，不显�C�Z�Q何信息，也无错误信息�?br /> 感觉无从查�v�Q�只能借助Google�?br /> 才发现原来Safari下很多Richfaces的组仉��会出现问题，解决�Ҏ��反而很��单：
在你的xhtml��面�Q�或者你用jsp或其他模板技术）的页首位�|�，加这行：

 contentType="text/html" />



问题解决�?/pre>






seal 2009-09-22 09:56 发表评论

Seam中简单的checkbox操作

seal — Wed, 02 Sep 2009 03:26:00 GMT

有一�U�情冉|��我们�q�x��E�序开发中�l�常遇到的，�Ҏ��一个checkbox的��|��动态的昄��隐藏一个区域，
在��用Seam和Richfaces开发的时候，一个简单的a4j:support �?reRender �q�不能解决问题。试验了一番，解决了这个问题，例子代码�Q?br />

1 <h:selectBooleanCheckbox value="#{beanA.propertyA}"
2     styleClass="check" onclick="showHideHistorySelector()" id="adminView"/>
3 <s:div id="historySelectorRegion">
4     <h:panelGrid columns="3" rendered="#{beanA.propertyA}">
5         //Content here
6     h:panelGrid>
7 s:div>
8 <a4j:jsFunction name="showHideHistorySelector" status="waitingMask"
9     reRender="historySelectorRegion" ajaxSingle="true"
10     process="adminView" action="#"/>

通过使用a4j:jsFunction的process属性来控制��可以解决问题�?br />

seal 2009-09-02 11:26 发表评论

seal — Tue, 01 Sep 2009 03:41:00 GMT

在java 中如果想从国际化资源文�g中读取文本，可以通过注入seam的一个组�Ӟ��
@In(value="org.jboss.seam.international.messages")
private Map messages;

在��用时�Q�只需要像下面�q�样�Q?br /> String abc = messages.get("person.name.required");

seal 2009-09-01 11:41 发表评论

Seam ��目部��v�?tomcat �?�?

seal — Wed, 26 Aug 2009 04:36:00 GMT

JBoss Tools 生成�?nbsp;Seam ��目�Q�新建项目时�Q�服务器选择 tomcat�Q�，会生成一些必要的文�g�Q�如�Q�连接数据库的数据源文�g�Q�如�Q?/font>project-ds.xml �Q�但它只能在 Jboss as 的环境中�q�行�Q�不适用�?nbsp;tomcat�Q�，要想很我们的��目�Q?/font>war�Q�运行于 tomcat 中的�Q�我们得对它自动生成的文件做一些必要的修改�?/font>

一�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">修改数据库的�q�接方式

         1、采用数据源的�Ş�?br />             �?nbsp;tomcat 中配�|�数据源方式如下:
            在生成的��目同��目录中找此文�Ӟ�� context.xml
                     Servers/Tomcat 。。�?/font>/context.xml  作如下配�|�：
            在标�{?nbsp; 中间加入:
                               name="jdbc/demo" auth="Container" type="javax.sql.DataSource"
                  maxActive="30" maxIdle="5" maxWait="10000" username="root"
                  password="admin" driverClassName="com.mysql.jdbc.Driver"
                  url="jdbc:mysql://localhost:3306/demo?useUnicode=true&characterEncoding=UTF-8">

         2�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">使用非数据源的�Ş�?br />             在文�Ӟ��persistence.xml 中添�?/font>hibernate 的连接数据库的方式，如下�Q?br />               <property name="hibernate.connection.username" value="root"/>
            <property name="hibernate.connection.password" value="admin"/>
            <property name="hibernate.connection.driver_class" value="com.mysql.jdbc.Driver"/>
            <property name="hibernate.connection.url"
                  value="jdbc:mysql://localhost:3306/demo?useUnicode=true&characterEncoding=UTF-8"/>

二�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">修改 JPA 配置文�g persistence.xml

1�?/span>如果数据的连接方式采用数据源的�Ş式，则只需修改里面数据源的名称�Q�如�Q?br /> <jta-data-source>java:comp/env/jdbc/demojta-data-source>

2、如果采�?font face="Times New Roman">hibernate 的连接方式，则把此行删了�?/font>

          3�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">删除里面的此行配�|�：
             <property name="hibernate.transaction.manager_lookup_class"
                  value="org.hibernate.transaction.JBossTransactionManagerLookup"/>

4、修改事务的�{�略方式�?RESOURCE_LOCAL �Q?nbsp;

<persistence-unit name="demo" transaction-type="RESOURCE_LOCAL">

      三�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">配置 Seam 的事务管理器
          �?nbsp;component.xml 文�g加入�Q?br />           <transaction:entity-transaction entity-manager="#{entityManager}"/>
         默认生成的此文�g是不含有 transaction 的命名空��_��需要手动在此文件加入它的命名空��_��

          xmlns:transaction=http://jboss.com/products/seam/transaction
         http://jboss.com/products/seam/transaction
         http://jboss.com/products/seam/transaction-2.1.xsd

四�?span style="font-weight: normal; font-size: 10.5pt; font-family: '宋体';">为此��目加入必要的依赖包。。。。。�?/span>

seal 2009-08-26 12:36 发表评论

rich:tree中drag和drop后reRender对应的tree

seal — Thu, 13 Aug 2009 07:05:00 GMT

如果使用ajax方式拖拽rich:tree中的节点�Q?br /> 在DropEvent对应的listener的方法中可以调用AjaxContext重新reRender�Q?br /> public void processDrop(DropEvent dropEvent){
。。�?br /> �?/此处处理逻辑
UITreeNode destNode = (UITreeNode)dropEvent.getSource();
AjaxContext ac = AjaxContext.getCurrentInstance();
// Add destination tree to reRender
ac.addComponentToAjaxRender(destNode.getUITree());

另外�Q�如果要在拖拽后reRender其他的节点，要用到oncomplete属性，使用一个jsfunction来reRender。单�U�的reRender不�v作用�Q�我猜原因可能是listener�q�不是按照一个ajax��h��的方式来的，所以单�U�的ajax reRender也不起作用�?br />

seal 2009-08-13 15:05 发表评论

SEAM的PAGE和CONVERSATION context

seal — Thu, 13 Aug 2009 06:53:00 GMT

在SEAM�?如果要在几个��面中保持状�? 需要��用CONVERSATION scope,
如果在一个页面中保持状�? 优先使用PAGE context,�q�样可以提高效率.

seal 2009-08-13 14:53 发表评论

seal — Thu, 13 Aug 2009 06:51:00 GMT

在rich:tree中如果想要在��面中初始化tree的展开和选中状态或者在��面更改后返回时保持之前的状态，
可以讄��tree的adviseNodeOpened �?adviseNodeSelected属性�?br />

adviseNodeOpened	false	false	`javax.el.MethodExpression` (signature must match `java.lang.Boolean adviseNodeOpened(org.richfaces.component.UITree)`)	MethodBinding pointing at a method accepting an org.richfaces.component.UITree with return of java.lang.Boolean type. If returned value is: java.lang.Boolean. TRUE, a particular treeNode is expanded; java.lang.Boolean.FALSE, a particular treeNode is collapsed; null, a particular treeNode saves the current state
adviseNodeSelected	false	false	`javax.el.MethodExpression` (signature must match `java.lang.Boolean adviseNodeSelected(org.richfaces.component.UITree)`)	MethodBinding pointing at a method accepting an org.richfaces.component.UITree with return of java.lang.Boolean type. If returned value is: java.lang.Boolean. TRUE, a particular treeNode is selected; java.lang.Boolean.FALSE, a particular treeNode is unselected; null, a particular treeNode saves the current state

seal 2009-08-13 14:51 发表评论

Concurrent calls to conversational components

seal — Mon, 20 Jul 2009 02:17:00 GMT

A general discussion of concurrent calls to Seam components can be found in Section 4.1.10, “Concurrency model”. Here we will discuss the most common situation in which you will encounter concurrency �?accessing conversational components from AJAX requests. We're going to discuss the options that a Ajax client library should provide to control events originating at the client �?and we'll look at the options RichFaces gives you.

Conversational components don't allow real concurrent access therefore Seam queues each request to process them serially. This allows each request to be executed in a deterministic fashion. However, a simple queue isn't that great �?firstly, if a method is, for some reason, taking a very long time to complete, running it over and over again whenever the client generates a request is bad idea (potential for Denial of Service attacks), and, secondly, AJAX is often to used to provide a quick status update to the user, so continuing to run the action after a long time isn't useful.

Therefore, when you are working inside a long running conversation, Seam queues the action event for a period of time (the concurrent request timeout); if it can't process the event in time, it creates a temporary conversation and prints out a message to the user to let them know what's going on. It's therefore very important not to flood the server with AJAX events!

We can set a sensible default for the concurrent request timeout (in ms) in components.xml:

We can also fine tune the concurrent request timeout on a page-by-page basis:






         conversation-required="true" 



         login-required="true"



         concurrent-request-timeout="2000" />

So far we've discussed AJAX requests which appear serial to the user - the client tells the server that an event has occur, and then rerenders part of the page based on the result. This approach is great when the AJAX request is lightweight (the methods called are simple e.g. calculating the sum of a column of numbers). But what if we need to do a complex computation thats going to take a minute?

For heavy computation we should use a poll based approach �?the client sends an AJAX request to the server, which causes action to be executed asynchronously on the server (the response to the client is immediate) and the client then polls the server for updates. This is good approach when you have a long-running action for which it is important that every action executes (you don't want some to timeout).

7.11.1. How should we design our conversational AJAX application?

Well first, you need to decide whether you want to use the simpler "serial" request or whether you want to use a polling approach.

If you go for a "serial" requests, then you need to estimate how long your request will take to complete - is it much shorter than the concurrent request timeout? If not, you probably want to alter the concurrent request timeout for this page (as discussed above). You probably want a queue on the client side to prevent flooding the server with requests. If the event occurs often (e.g. a keypress, onblur of input fields) and immediate update of the client is not a priority you should set a request delay on the client side. When working out your request delay, factor in that the event may also be queued on the server side.

Finally, the client library may provide an option to abort unfinished duplicate requests in favor of the most recent.

Using a poll-style design requires less fine-tuning. You just mark your action method @Asynchronous and decide on a polling interval:

7.11.2. Dealing with errors

However carefully you design your application to queue concurrent requests to your conversational component, there is a risk that the server will become overloaded and be unable to process all the requests before the request will have to wait longer than the concurrent-request-timeout. In this case Seam will throw a ConcurrentRequestTimeoutException which can be handled in pages.xml. We recommend sending an HTTP 503 error:



   <exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">

503 Service Unavailable (HTTP/1.1 RFC)

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.

Alternatively you could redirect to an error page:



<exception class="org.jboss.seam.ConcurrentRequestTimeoutException" logLevel="trace">



   



   



      The server is too busy to process your request, please try again later

ICEfaces, RichFaces Ajax and Seam Remoting can all handle HTTP error codes. Seam Remoting will pop up a dialog box showing the HTTP error and ICEfaces will indicate the error in it's connection status component. RichFaces Ajax provides the most complete support for handling HTTP errors by providing a user definable callback. For example, to show the error message to the user:

7.11.3. RichFaces Ajax

RichFaces Ajax is the AJAX library most commonly used with Seam, and provides all the controls discussed above:

eventsQueue �?provide a queue in which events are placed. All events are queued and requests are sent to the server serially. This is useful if the request can to the server can take some time to execute (e.g. heavy computation, retrieving information from a slow source) as the server isn't flooded.
ignoreDupResponses �?ignore the response produced by the request if a more recent 'similar' request is already in the queue. ignoreDupResponses="true" does not cancel the the processing of the request on the server side �?just prevents unnecessary updates on the client side.

This option should be used with care with Seam's conversations as it allows multiple concurrent requests to be made.
requestDelay �?defines the time (in ms.) that the request will be remain on the queue. If the request has not been processed by after this time the request will be sent (regardless of whether a response has been received) or discarded (if there is a more recent similar event on the queue).

This option should be used with care with Seam's conversations as it allows multiple concurrent requests to be made. You need to be sure that the delay you set (in combination with the concurrent request timeout) is longer than the action will take to execute.
�? Polls the server, and rerenders an area as needed

seal 2009-07-20 10:17 发表评论

又一个有点变态的Seam错误�Q?Property ‘xxx�?not readable on type java.lang.Boolean

seal — Mon, 20 Jul 2009 01:24:00 GMT

今天又碰��C��个Seam的错误，感觉使用Seam开发的�q�程��是在不停的找Bug�?br /> 错误如下�Q?br /> 在��用rich:inplaceSelect做一个布��型的选择框时�Q�由于客户需要，在特定情况下需要一个默认��|��也就是rich:inplaceSelect的defaultLabel�Q�这时就需要除了true和false外再有一个null的��|��所以需要将后台session bean中的对应属性由原始�c�d��boolean改�ؓBoolean�Q�在改完之后�Q�重新运行程序报错：
Property ‘xxx’ not readable on type java.lang.Boolean
分析了一下，找不��Z��么可能的原因�Q�最后在一片帖子中发现了对应的信息�Q?br /> 原来JSF��原始类型boolean的get�Ҏ��默认为is....(),而将��装�c�d��Boolean的get�Ҏ��默认为get...().

Ok,在后台将对应那个的方法修改，问题解决�?br />

seal 2009-07-20 09:24 发表评论

Seam错误�Q�org.jboss.seam.InstantiationException: Could not instantiate Seam component

seal — Fri, 17 Jul 2009 01:53:00 GMT

今天一个问题让我困��C��很久�Q�新��Z��个session bean后，执行�E�序一直报错：
org.jboss.seam.InstantiationException: Could not instantiate Seam component: xxxAction
找了好久�Q�终于发��C��错误原因�Q?br /> 原来是对应的@Stateful的session bean对应的接口没有标注：@Local
The devil's in the Details�Q�果然如此啊

seal 2009-07-17 09:53 发表评论

在rich:inplaceSelect 中��用布��型的selectItem时碰到的问题

seal — Fri, 10 Jul 2009 09:13:00 GMT

作者： sealyu   日期�Q?009-07-10

我们都知道，�?lt;h:selectOneMenu>中��用布��型selectItem�Ӟ��itemValue�?true"/"false".例如�Q?br /> <h:selectOneMenu value="#{controller.booleanPropertyX}">


h:selectOneMenu>
�q�样是没有问题的�?br /> 但是如果你��?lt;rich:inplaceSelect>来实现选择功能的时候，"true"/"false"��׃��起作用了�Q�例如：
    defaultLabel="-Select-" immediate="true"
    value="#{controller.booleanPropertyX}">



�q�时候即使sfsb中的�?font size="2">booleanPropertyX�?true"/"false"�Q�也不会有selectItem被选中�Q�而且如果你选择一个selectItem�Q�还会报�?IllegalArgumentException.说明selectItem的itemValue�?/font>#{controller.booleanPropertyX}的值是不匹配的�?br /> 后来我将"true"/"false"改�ؓ"0"/"1", �q�是不�v作用�?br />
Finally�Q�终于试��Z��正确的方法：使用"#{true}"/"#{false}". 正确的��用方法：
    defaultLabel="-Select-" immediate="true"
    value="#{controller.booleanPropertyX}">



也就是说�Q?br /> �Q?�Q�。如果你使用<h:selectOneMenu>�Q�那么你的f:selectItem的itemValue应该使用�Q?true"/"false"
�Q?�Q�。如果你使用�Q�那么你�?/font>f:selectItem的itemValue应该使用�Q?#{true}"/"#{false}"

原因暂时�q�没研究出来�Q�但是结果就是这��L��了�?br />

seal 2009-07-10 17:13 发表评论

seal — Mon, 18 May 2009 02:01:00 GMT

�q�两天在作seam的时候不旉��?#8220;org.jboss.util.NestedSQLException: Transaction is not active”的错误信息，后来到jboss的wiki上发��C��问题的原因和解决�Ҏ��Q?br />

How do I set the Transaction Timeout?

Transaction timeout (unit is always seconds) can be configured in various ways:

This argument is the same no matter if you are using JBossTM(<=4.0.5) or JBossJTA-Arjuna(>=4.2).

Globally: You can change this behavior globally by modifying the TransactionManagerService in /conf/jboss-service.xml (or /deploy/jta-service.xml for 4.0.3)

Version <= 4.0.5

This part is the same for either JBossTM or JBossJTA and is the same for ejb2 and ejb3

Per-method basis: Modifying the element inside the element of a session or entity bean. This is located in the META-INF/jboss.xml deployment descriptor of a session bean. When the transaction timeout is specified at the method level, it overrides the default timeout. Further information about this element can be found in jboss-x.x.x/docs/dtd/jboss_4_0.dtd. Example taken from the testsuite:

Using BMT: Calling javax.transaction.UserTransaction.setTransactionTimeout(int seconds). Please, be aware that this only applies to transactions started after this invocation on the same thread. Example:

@TransactionTimeout(1500)

seal 2009-05-18 10:01 发表评论

seal — Wed, 13 May 2009 01:36:00 GMT

seam有个一个内�|�的component�Q�叫做redirect。它��h��获取当前view的能力当得到登陆授权后，可以直接获得��d��前的地址�q�行讉K��?/p>

在component.xml里添加：

seal 2009-05-13 09:36 发表评论

Seam错误�Q�deleted entity passed to persist

seal — Fri, 08 May 2009 00:59:00 GMT

在��用Seam的EntityHome.remove()�Ҏ��时报错： deleted entity passed to persist:[com.xxx.xxx.Person#]
单纯看错误信息，�q�以为是对象没有传进厅R��但调试之后发现personHome里面的对象是正确的�?br /> 后来��试了几�ơ发现是因�ؓ所要删除的对象隶属于另外一个对象，那么单纯删除此对象时�Q�会报这个错误，因�ؓ此时的约束关�p�还未解除�?br /> 例如�Q?br /> 我要删除一个Person实体�Q�而这个实体是属于一个组�l�Department的，
那么我应该在删除之前先执行： personHome.getInstance().getDepartment.getAllPersons().remove(personHome.getInstance()),
然后再执行personHome.remove().

seal 2009-05-08 08:59 发表评论

提高JSF�Q�SEAM�E�序的效率（转）

seal — Thu, 07 May 2009 01:16:00 GMT

原文�Q�http://www.jsfcentral.com/articles/speed_up_your_jsf_app_1.html

Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude - Part 1
by Dan Allen
05 Feb 2009 03:00 EST

In the first of this two-part article, Dan Allen discusses some common performance problems you may encounter when using JSF components, Seam components, and the EL. You'll learn about the set of best practices for eliminating them that led to an improvement of two orders of magnitude in the performance of his application.

JavaServer Faces (JSF) has a reputation for having poor performance. Some claim that this "runtime tax" is simply the cost of using a component-based abstraction layer. After focused research, I have determined that by following a handful of best practices, you can get your JSF data tables to perform almost as well as hand-crafted HTML while still being able to retain the benefits of developing with an event-driven programming model. I begin by identifying some performance problems that occur when using JSF UI components, Seam components, and the EL carelessly, and then present, through a series of four lessons, ways to eliminate these problems one-by-one until you have observed a remarkable, two orders of magnitude improvement.

All the test results reported in this article were gathered on a Lenovo R60 with 2.5GB RAM, Dual Core T2300 @ 1.66Ghz processor running Ubuntu Linux 7.10. The application was built using Seam 2.0.3.CR1, Sun JSF 1.2_04-b16-p02, and RichFaces 3.2.2.GA. It was deployed to JBoss 4.2.2.GA running on Sun JVM 1.6.0_03. The timing results are shown in six progressive phases. Each result shows the total request time and the time to render a data table with 50 records. All metrics were captured using the FireBug extension for Firefox.

Introduction

Developing a data management application is just a matter of getting data up on the screen in tabular format, correct? Oh, right, and being able to filter the data. Ah, and also allowing the data to be changed. Unfortunately, once those challenges are behind us, we tend to wash our hands of the application and move on. But the principle goal of most web applications is to enable users to perform their work more efficiently than they did before we introduced our "solution." In fact, none of those fancy features you add have any value at all if you can't improve the user's productivity. That's why, before you step away, you have to make sure that you have addressed the issue of performance.

My colleagues and I recently completed the first stage of an open source data management application based on JSF, Seam, and RichFaces in which we addressed this very concern. The application, named EDAS2, was developed for a group of scientists for managing water quality data (stored in the WQX database schema). Now, you have to understand that these scientists, they like their data. Hordes of data. And they like to view it all at once. So much, in fact, that it tends to cause the browser to crash. Naturally, we needed to condition the scientists to some degree that browsers have limits. But regardless, we were going to be dealing with large data sets. Our goal was to make sure that working with those data sets was not painful.

This article documents the bottlenecks that we discovered and a set of best practices for eliminating them. But we went beyond merely removing obstacles in performance. We tuned the application to the point where paginating, sorting, and filtering the data is actually faster than any desktop application our scientists had ever used. Find that hard to believe? Read on.

About the EDAS2 application

The intent of the EDAS2 application is to house and analyze water-quality measurement results. The results are taken from a location, known as a monitoring location, during a given visit, known as an activity. There are various types of results, depending on what is being measured. In this article, we will be focusing on the benthic measurement result, which in layman's terms is a sampling of mud with bugs in it. That data is recorded on site and later entered into the database and analyzed using the EDAS2 interface.

There isn't anything revolutionary about the interface of the EDAS2 application. Rather, the emphasis is on efficiency. We want to provide the experience of the MS Access database-which our scientists are currently using to manage this data-in a web application.

The application has two types of views. The first is a list view, which displays a paginated table of records for the currently selected parent entity, such as monitoring location, activity, or result. You will learn shortly that what makes this interface efficient is that it offers in-place editing of each row (it also has a floating popup dialog for detailed editing of the row).

The editable data table

The key feature of this application is that the data rendered in each table can be modified in place. To implement this functionality, we decided against using an off-the-shelf grid editor from a JSF component library. Instead, we took the RichFaces step-wise approach by building a composite, Ajax-enabled component using the partial page rendering technology that the Ajax4jsf core provides.

Ajax4jsf provides a set of tag libraries that can tie a JSF generated event to the rerendering of one or more regions of the user-interface. Those regions are identified by their JSF client IDs. When the JSF event is sent to the server, instead of the JSF servlet returning an entire page response, it returns only fragments of the HTML. Ajax4jsf then cuts out the old branches from the live view and stitches in the replacements returned from the server. The result is that the user observes the page updating without any noticeable refresh, in real-time, so to speak. And Ajax4jsf's declarative approach let's us fine-tune this behavior.

Figure 1 provides a view of the editable data table with one of the rows in edit mode.

Figure 1. The data table demonstrating its single-line editing capabilities.

When the page is first rendered, all rows have an edit and delete button. Clicking on an edit button puts the corresponding row in edit mode, at which point the outputs in the selected row become inputs. From edit mode, the user can make changes to the visible data and either save or cancel the update, which returns the table to read-only mode.

The strategy we use to deliver this row-level editing functionality is to have two UI components in each column of a standard JSF data table: one output component (e.g., ) and one input component (e.g., ). We then use the JSF rendered attribute on each component to control which one is displayed.

A backend supported by Seam

To support our editable data table, we put together a small hierarchy of classes that are instantiated as Seam components to manage the query (filtering, pagination) and the editing process (select row for editing, update, delete, cancel). We chose to put the components in Seam's conversation scope. The conversation scope is a slice of the HTTP session that is managed by Seam and associated with a sequence of pages through the use of a special request token (known as the conversation id). The conversation provides the developer the convenience of using the HTTP session without the memory leakage concerns, since the conversation has a much shorter lifetime and is kept isolated from other parallel conversations in the same session.

We chose to leverage the conversation for three reasons:

to reduce the number of times the database needs to be queried
to ensure the record remains managed by the persistence context while being edited
to maintain the search criteria and pagination offset

Using the conversation has the added bonus of making previously viewed result pages load faster since the records are already sitting in the persistence context (i.e., the first-level cache).

Given all the benefits the conversations provide, you may be wondering where the performance problem is. Let's take at look at where things began to go wrong and what we did about it.

The performance roadblock

Development was going smoothly until my colleague noticed something peculiar about the performance. Five or ten records on the page took a reasonable amount of time to render, but when that number went up to 50 or 100 records, the performance of the page plummeted. It turns out that the degradation was linear, but the slope was very steep. The page with 100 records was taking over 15 seconds to render. Obviously, that just wasn't going to fly. And so our optimization work began. Could we find the bottleneck and how low could we go?

As we optimized, we first looked at the most basic page and established a performance baseline. Then we added additional components to the page and tried to identify which ones were contributing to the major slowdown. As it turns out, in a Seam application, the first area to place your focus is on page actions, which are methods that execute before the page begins to render.

Page actions and component initialization

When a page is taking 15 seconds to render, there is likely a single culprit that is chewing up a bulk of that time. To establish a baseline, and to make sure I was focusing on the right problem, I first stripped everything from the page and requested it. The response took a couple of seconds to come back. This had me puzzled for a moment. I soon realized that that a Seam page action was registered with the page (i.e., view ID). A page action is a method-binding expression that is assigned to a JSF view ID (or a group of view IDs if a wildcard is used) in a Seam page descriptor and is evaluated by Seam just before the view ID is rendered by the JSF view handler. Here's the expression that was registered with the view ID of the results page.

The page action is there to eagerly fetch the results that are to be displayed on the page. However, the query in that method was executing in about a tenth of a second. So that wasn't the problem. After studying the code a bit longer, I recognized that the problem was not in the page action method, but rather the @Create method of the component being invoked. The @Create method is a synonym to the standard @PostConstruct method in Java EE and marks a method to be evaluated immediately after a component is instantiated.

Inside the @Create method was a handful of queries that retrieved more than 10,000 records of reference data. This data is used by select menus in various forms on the page, but those forms are all being conditionally rendered. So basically, we were charging the user a toll to enter the page with a chance that that reference data would never be referenced. That brings us to lesson #1.

Lesson #1: Don't make the user pay an upfront fee to view a page. Defer logic where possible.

Since the forms are rendered conditionally, and some via Ajax, the reference data can be retrieved at the same time the forms are activated. If you must display a form unconditionally, think about the most efficient way to prepare the data (perhaps using a cache). It's also preferable to use Ajax-based autocomplete rather than select menus with a large list of options, since making this switch can drastically reduce the speed of the initial rendering of the form. The user will likely be more patient when working on the field with autocomplete, and you can even keep the number of options delivered to a minimum as the user types.

With the toll skimmed off the top, we could get back to the performance of the elements on the page. Bringing back the page piece-by-piece, I determined that the next big time hog was in fact the data table. Again, I stripped out elements in the data table until I pinned down what was causing the problem. As it turns out, it was the expressions in the rendered attributes that I was using to hide or show various components in the table.

The cost of conditional rendering

In each row there are 6 "editable" columns, each containing an output and an input component and 4 icons for controlling editing (edit, delete, approve, cancel). In total, there are 16 uses of the rendered attribute appearing in each row. (Initially I had a couple columns with multiple input components, which I realized I needed to group within a panel group [i.e., ] so that the rendered attribute was only applied once).

As you know, logic that occurs in a single row is multiplied by the number of rows in the table. In a table with 100 rows, there are 1600 uses of the rendered attribute! But wait, there's even more! The rendered attribute is a nasty beast in JSF because it's often evaluated multiple times as the UI component tree is assembled. In fact, during the render response phase, it's resolved 3 or 4 times per component in a data table. What that means is that for our data table, the conditional rendering logic we are using is executed 5200 times for 100 rows! Whatever that logic is better be darn efficient or else it will have a huge impact on performance.

Warning: After hearing the bad news about how the rendered expression is abused by JSF, you might be inclined to use the tag from Facelets. This tag emulates the behavior of the equivalently named tag from the JSTL tag library. You have to be careful with this tag, though, because it's not a true JSF component. It's processed by the Facelets compiler prior to building the UI component tree and can thus exclude a region of the markup from contributing to the UI component tree for that view. The benefit of this tag is that it can reduce the size of the component tree when you know that certain parts of the page aren't needed. However, the conditional rendering that you expect to happen on a postback does not, because at that point, the tree is already built and Facelets does not reprocess the statements.

As it turns out, we were not being very efficient. Let's take a look at one of the columns of the data table in the /BenthicMeasurementList.xhtml view template:



Taxonomic Unit

As you can see here, I am calling the editing() method on a Seam component named benthicMsmntEditor to test whether the current row is in edit mode. We can pass the iteration variable, _item, to the method because Seam integrates with the JBoss EL, which introduces parameterized method calls to the Unified EL. The editing() method performs an identity check between the row data and the selected row.


public boolean editing(T itemInRow) {
return itemInEditMode == itemInRow;
}

Here we are only allowing one row to be in edit mode at a time, but this logic could easily be enhanced to support editing multiple rows simultaneously.

So where's the bottleneck? Initially, you may be inclined to point the finger at the EL or Java reflection. I did some testing and determined that the EL is surprisingly fast and Java reflection is equally optimized. And if you are inclined to believe that the slowness is caused by the parameterized method call, I'll inform you that comparing the current item using an EL operator to the item in edit mode retrieved using the JavaBean style accessor yields the same timing results:

rendered="#{_item == benthicMsmntEditor.itemInEditMode}"

The culprit is that the editing() method resides on a Seam component and each method call to a Seam component passes through a stack of interceptors, unless otherwise skipped by the presence of the @BypassInterceptors annotation at the component or method level.

When you call an intercepted method once, you would never notice the impact of the interceptors. However, when you call the method 5200 times, the time spent in the interceptors adds up. How much of a difference does it make and what other options do we have?

To determine the impact, I timed both the rendering of the entire page and the rendering of the data table region, as described in the introduction. The data table region consists of the data table and the pagination controls and summary information for the table. A test of 4 requests on 50 rows (2600 calls) produced these timing results:

Stage 1 timing results (50 rows)

Request	Elapsed time of request (ms)	Time to render table (ms)
1	6330	6090
2	6340	6096
3	6400	5883
4	6100	5850
avg	6292.4	5979.8

Not many people are going to stick around for a page that takes 6 seconds to render (in the best case scenario), and that doubles for 100 rows. The trick is to outject the selected row so that the comparison can be done without having to invoke a Seam component. Outjection is a mechanism in Seam that takes the value of a JavaBean property on a component and assigns it directly to the name of a variable in the specified scope (such as the conversion scope). You outject a property by annotating it with the @Out annotation, as shown here:

@Out(required = false) private T itemInEditMode;

(For readers with Seam experience, there is a reason why you cannot simply add @BypassInterceptors to the editing() method, which I will provide in a moment.)

Now we can check if the row is in edit mode by comparing the iteration variable in the data table to the outjected property using the following EL expression in the view:

"#{item == itemInEditMode}"

Here's how things improve after making this change:

Stage 2 timing results (50 rows)

Request	Elapsed time of request (ms)	Time to render table (ms)
1	904	663
2	807	608
3	813	569
4	823	592
avg	836.8	608

Less than one second is certainly a nice place to be. We can do better, but let's first focus on the 5 second discrepancy because it is a cause of concern regarding Seam's performance.

The truth is, interceptors come with a cost. Again, this cost only adds up when you are pounding the component, like the rendered attribute does. Unfortunately, that is more of a limitation (and a fact of life) in the way that the data table component in JSF was designed. On the other hand, that is why Seam provides the @BypassInterceptors annotation. This annotation is intended to be used on methods that read the state of a component, as opposed to a method with behavior. After all, Seam is a stateful framework and espouses using objects as they were intended, to have behavior and state.

So why not just add @BypassInterceptors to the editing() method to reduce the overhead of invoking it? Theoretically that would work. The only problem is that Seam relies on interceptors to restore the state of conversation-scoped components, at least in Seam 2.0. In Seam 2.1, this behavior is disabled by default, so you could just add @BypassInterceptors to the method. However, if you plan to use stateful session beans (SFSBs) in your application or run the application in a cluster, you will need to enable the behavior I am about to describe, so it's important to understand why interceptors on conversation-scoped components are important.

Seam's managed entity interceptor

Seam 2.0 uses an interceptor that aids with maintaining the object identity of persistent objects (managed entities) across passivation of a SFSB, or when components jump nodes in a cluster. This interceptor has good intentions, but can have bad consequences. At the end of a method call on a conversation-scoped component, the interceptor transfers the values of all fields holding references to entity instances directly into the conversation context, and then nullifies the values of those fields. It reverses the process at the beginning of the next call. The consequence is that without interceptors, your conversation-scoped object is missing state. Eeek! What's worse is that the performance of the interceptor is naturally challenged if your component happens to be storing large data sets, because it takes time for the interceptor to perform its work. It's an unfortunate sacrifice in order to achieve transparent replication.

Rather than worrying about whether to use this interceptor, or locking the design of your application into its absence, it's best just to avoid the need to disable interceptors. Besides, there are still other interceptors that may need to be enabled on a component's methods (its all or nothing when you disable them) and working with outjected data is the fastest approach anyway. You can feel comfortable calling methods on Seam components in other areas of your page, but you should avoid doing so inside of a data table, which brings us to our second lesson.

Lesson #2: Don't call intercepted methods inside a data table (or in excess)

The question is, have we done all that we can do to optimize? Not even close. There is another important lesson to learn, and this one has to do with the EL, or more specifically, the EL resolver mechanism.

Resolving variables efficiently

In JSF, the view is bound to server-side components using a syntax known as the Unified Expression Language (EL). The root of an EL string (e.g., #{itemInEditMode}) is presumed to be a variable in one of the available web application scopes, or the name of a component that must be created (such as a JSF managed bean or Seam component). The name resolution is handled by the EL resolver chain, which is a collection of objects that know how to locate or create objects that map to a name. All resolvers in the chain are consulted until the end of the chain is reached or a value is found. This lookup happens a tremendous number of times while rendering a JSF view, especially while rendering a data table. Thus, it's a potential source of performance problems.

As the EL resolver chain seeks out a variable, it becomes increasingly more aggressive. The standard EL resolver looks in the familiar places: the request, session, and application scope. It then turns the task over to the Seam resolver, which is where things start to slow down. Seam has lots of different places to look to resolve a variable: a component, a factory, a Seam namespace, a Seam context, and the list goes on. Thus, not finding a variable comes at a high cost.

So the solution is simply to avoid referencing a missing variable, right? Well, what happens when a null value for a variable is meaningful in your application, as is the case of our editable data grid. A null value for the itemInEditMode variable means the row is not in edit mode. Unfortunately, the EL resolver chain doesn't know that a null value means something, and will keep working through its crib sheet until it has tried all possible combinations. Thus, we need to find some way to tell Seam exactly where to look rather than allowing Seam to send out its search party, so to speak.

Again, taking advantage of the flexibility afforded to us by the JBoss EL, we can reach directly into the conversation context to look for the row in edit mode:

rendered="#{_item == conversationContext.get('itemInEditMode')}"

Here's the reward we get for telling Seam exactly where to look:

Stage 3 timing results (50 rows)

Request	Elapsed time of request (ms)	Time to render table (ms)
1	491	207
2	495	224
3	493	201
4	444	211
avg	480.8	210.8

We roughly doubled our performance and now have 100 rows coming in under a second, with an order of magnitude improvement over the first run. But there is still a slight bottleneck. The variable _item is stored in request scope by the data table and is resolved quickly, but the variable conversationContext is a pseudo-variable that Seam interprets after looking in all the usual places for a real variable named conversationContext. Not only that, conversationContext is an imported context variable, the qualified name being org.jboss.seam.context.conversationContext. It turns out that referencing a context variable in an imported namespace has a measurable cost associated with it. A better choice would be to pull the result of this lookup somewhere closer so that Seam doesn't have to keep searching for it. We can set that up using an alias (an event-scoped factory) in the Seam component descriptor named conversationScope (to match requestScope, sessionScope, and applicationScope provided by the standard EL resolver):

We now reference this name in our rendered logic:

rendered="#{_item == conversationScope.get('itemInEditMode')}"

Here's how the timing results improve:

Stage 4 timing results (50 rows)

Request	Elapsed time of request (ms)	Time to render table (ms)
1	399	161
2	373	150
3	458	207
4	560	163
avg	447.5	170.25

Those are the kinds of numbers we want to see! Just as I mentioned at the start of this article, there was likely a single culprit that was squandering a majority of the rendering time. It turns out to have been the logic in the rendered attribute of components within a data table. But really any logic inside of a data table has to be optimized because it's going to be compounded by the number of rows being rendered. For instance, you might be conditionally rendering columns based on the user's preferences. That brings us to the third lesson.

Lesson #3: Be extremely frugal with the logic you use within a data table

Incidentally, I thought about using an action listener to toggle the rendered state on components in a row when the user clicks on the edit button, since that's the "object-oriented" way of doing things. Unfortunately, the design of the data table is extremely naive and does not support this usage pattern. A data table doesn't have any concept of rows, only columns. The rows are introduced dynamically based on the data fed to the table (they are not represented in the state of the component tree). Thus, if you change the rendered attribute on a component in one of the rows, you end up affecting every row in the table. The dynamic nature of the data table leads to many other problems in JSF, including the "ghost click" which I discuss in my book, Seam in Action

If you are committed to squeezing as much performance as possible out of your page, then there is one more way you can optimize the speed of the rendered logic: don't use it. I'm not suggesting that we throw out the editable grid functionality. If you think about it, that logic only needs to be performed once the user has selected a row. Before that time, you know that you only need to display the table in read-only mode (and you know which controls to provide in that case). Thus, the best thing to do is split the table into two, one that has the rendered logic in the columns and one that does not, then toggle the rendering of the entire table. That way, the person just browsing the data does not have to pay the tax of checking for the row selected for editing. While this does increase the amount of code to maintain, it introduces the possibility of having different columns displayed when the user is editing than when they are just viewing (or even having the table look different in some way). You can move common code into templates to prevent duplication. Of course, the performance is now going to increase noticeably.

Stage 5 timing results (50 rows)

Request	Elapsed time of request (ms)	Time to render table (ms)
1	537	174
2	355	127
3	372	127
4	374	127
avg	409.5	138.8

You are probably feeling pretty happy with the progress so far. Where to next? In each of the performance results, I have provided two columns of data for a reason: to emphasize that we are paying yet another tax to render the remainder of the page. That is the focus of the next round of optimizations. Obviously, the size of this tax is going to depend on what else you have on your screen and won't necessarily amount to the ~270ms appearing in these test results. Regardless, the amount of this tax now exceeds the cost of the product and we need to do something about it. That's where Ajax comes in.

Cutting costs with Ajax

The bottleneck in any decently performing web application is the process of the browser requesting and ultimately rendering a new page. What makes the process worse is that it happens synchronously, forcing the user to wait until it finishes. It's extremely disruptive and it makes the application feel slow. A far better approach is to have the browser only replace the portions of the page that need to be changed and to insert those changes into the page when they arrive (i.e., partial page rendering), which doesn't interrupt what the user is currently doing (or at least keeps the disruption localized).

The exchange just described is achieved using Ajax. Fortunately, the RichFaces component library for JSF makes adding Ajax interactions to a page extremely straightforward. In the next part of this article, you'll learn to use RichFaces' partial-page rendering to only update the data table when the user change its state, such as to select a row for editing or paginating the table, thus eliminating the tax that comes with rerendering the entire page. Once this change is made, the two orders of magnitude performance boost will be realized.

Speed up your Data-Driven JSF/Seam Application by Two Orders of Magnitude – Part 2
by Dan Allen
27 Mar 2009 01:30 EDT

In the second installment of this two-part article, Dan Allen continues his discussion of some common performance problems you may encounter when using JSF components, Seam components, and the EL. You'll learn about the set of best practices for eliminating them that led to an improvement of two orders of magnitude in the performance of his application.

In the first part of this article, I began briefing you on optimizations I made to maximize the responsiveness of a JSF application that I developed out in the field. I cited performance problems caused by casually accessing components from a JSF view, then presented a set of best practices to eliminate this unnecessary overhead. Despite the progress made by the end of the first part, you had not yet witnessed the two orders of magnitude in performance improvement that was promised.

In this part, the additional gains will be achieved by leveraging partial page rendering-provided by the RichFaces JSF component library and by slimming the response. Partial page rendering cuts out the overhead of rerendering the entire page after each user interaction, which turns out to be the real bottleneck in most traditional web applications, and instead redraws only the areas of the page that have changed. Naturally, you want the replacement HTML source to be as condensed as possible. These optimizations allow the responsiveness of a web application to measure up to its desktop counterpart.

Tapping into Ajax

When the user performs an operation on the screen, such as selecting a row for editing or paginating a result set, we only want to rerender the area of the page that is affected. Using the data-driven application presented in the first part, that means redrawing the data table and its pagination controls. (Note that it's possible with Ajax4jsf to rerender a single row, when applicable, but I have found it to be more trouble than it's worth).

Putting numbers aside, using Ajax is going to make the application feel far more responsive because the browser does not have to bootstrap a whole new page and all the assets that come along with it. Research has shown that creating HTTP connections is more costly than rendering large pages. Partial page rendering accounts for these findings by treating the static areas of the page and its associated assets as completed work, and focusing solely on retrieving updates. This section will support my recommendation that you should always consider using Ajax in your application, as it truly does eliminate a lot of overhead.

Accessible Ajax with Ajax4jsf

Turning regular JSF postbacks into Ajax requests is pretty simple with Ajax4jsf. However, if used inappropriately, you won't get all the performance gains you are looking for. We'll get to that in a second. First, begin by changing your and components to the ones from Ajax4jsf: and . Next, select what you want to rerender. You reference the areas of the page to update using a comma-separated list of the regions' component IDs in the reRender attribute of the command component. If you are paginating, you need to rerender the whole table and the pagination controls (dataTableContainer). If you are transitioning into edit mode, there's no need to requery or update the pagination, so you only have to rerender the table itself. Here's the code for the pagination controls:

The code for the edit control buttons in each row is similar. Here's how the edit button is defined:

What's important about using an Ajax request is to keep it simple. You don't want to perform a lot of processing on the server because then the users aren't going to get the "instant" feedback they are expecting. You can drastically reduce the portion of the component tree that is processed by JSF by using either the <;a:region> tag or the ajaxSingle attribute on an Ajax4jsf component. Let's focus on ajaxSingle.

Keeping the Ajax call brief

By default, JSF processes the whole component tree on a postback because it doesn't know where events may originate or which input fields within the submitted form contain new data. What the ajaxSingle attribute does is tell JSF to advance directly to the component that was activated, process events from that component, and re-encode it as if it were the only component on the page. The result is a drastic speed increase in the processing, independent of the size of the component tree. In fact, the only time you would forgo using ajaxSingle is when you need to capture input data from a form (a classic form submit).

When deciding whether or not to use this attribute, ask yourself if you are capturing form data or whether JSF is simply using the form submit to perform server-side work (a contrived form submit). In JSF, it's most often the latter.

Note: Interestingly enough, ajaxSingle is also a drop-in replacement for immediate, which is excellent since immediate is so poorly understood. When ajaxSingle is placed on a command component (such as a button), the form data is not processed, and hence no validation/conversion failures can occur, thus eliminating the need for immediate.

Having shifted all interactions to the Ajax bridge, it's now time to look at the performance gains. Of course, when using Ajax, the tax of rendering the portions of the page outside of the data table is gone. The performance on the server is also no longer a primary concern. Now what matters is the size of the response. Unfortunately, giving timing results here would be arbitrary because it's highly dependent on the speed of the network (and I'm testing against my own box). We have to focus on what we can control.

Trimming down the response

So what affects response size? The answer is, every character in the view. Every character that you type that is encoded into the response, as well as the markup that the JSF components generate, affects the size of the response. That includes:

Component IDs
View IDs
The path of images, external JavaScript files, and CSS
The application context path
Embedded JavaScript
Inline styles and names of style classes
Erroneous markup that is encoded into the response

As you can see, there's lots of room for improvement in this category. I want to focus on component IDs first, since they are the biggest culprit.

Resources

Code samples for this article (browse)
Code samples from this article (SVN checkout)
Best Practices for Speeding Up Your Web Site
An introduction to RichFaces
JBoss virtual host configuration
EDAS2 Homepage
Seam
RichFaces
Seam, Hibernate, RichFaces, and JBoss Tools blog

Dan Allen is a Senior Software Engineer at Red Hat and author of Seam in Action. He has over eight years of development experience using technologies that include Java frameworks (Seam, JSF, EJB3, Hibernate, Spring, Struts), testing frameworks (JUnit, TestNG), JavaScript and DOM scripting, CSS and page layouts, Maven 2, Ant, Groovy, and many others.

After graduating from Cornell University with a degree in Materials Science and Engineering in 2000, Dan became captivated by the world of free and open source software, which gave him his debut in software development. He soon discovered the combination of Linux and the Java EE platform to be the ideal blend on which to build his professional career, with his interests equally divided between the two platforms.

Dan is a member of the Seam project, a dedicated open source advocate, and a Java blogger. He lives with his extremely supportive wife in Laurel, MD. You can keep up with Dan's development experiences by subscribing to his blog at Mojavelinux

seal 2009-05-07 09:16 发表评论

seal — Wed, 06 May 2009 07:30:00 GMT

作者： sealyu   日期�Q?009-05-06

在Seam中，如果要提供一个集合属性传到页面，那么可以有两�U�选择�Q?br /> �Q?).在SFSB中徏一个集合属性，�q�徏立一个方法用来取得对应的数据。例如我们有一个SFSB�Q�TestAction.java�Q�：
�Q�Stateful
@Name("testPerson")
public class TestAction extends TestActionLocal implements Serializable{
protected List personList;
public List getPersonList(){
      //得到对应数据
}
}
每次在前台页面调用的时候可以直接��用：
.

但是�q�种�Ҏ��有种�~�点�Q�因为将对应的��D��值给一个JSF�l��g�Q�所以在��h��一个页面的时候经帔R��要调用很多次取数据的函数�Q�即使你作判断（例如�Q�当��g��为空的时候不再重新取��|��Q�这个函数还是会执行很多�ơ，可能会造成效率的问题�?br /> 但是�q�种�Ҏ��的好处是��L��可以取得最新的数据。在你经帔R��过传递参数来取得数据列表的时候，�q�种�Ҏ��比较好�?br /> �Q?).使用�Q�Factory.
�Q�Factory有两�U�，在它的javadoc里面是这么说的：
* Marks a method as a factory method for a context variable.
* A factory method is called whenever no value is bound to
* the named context variable, and is expected to initialize
* the value of the context variable. There are two kinds of
* factory methods. Factory methods with void return type are
* responsible for outjecting a value to the context variable.
* Factory methods which return a value do not need to
* explicitly ouject the value, since Seam will bind the
* returned value to the specified scope.

�W�一�U�工厂方�?
�q�种工厂�Ҏ��没有�q�回��|��但是你需要将得到的数据注出到context里面�Q�大多数情况下你可以直接使用�Q�DataModel�Q�例如：
�Q�Stateful
@Name("testPerson")
public class TestAction extends TestActionLocal implements Serializable{
@DataModel
protected List personList;
@Factory(value="personList", autoCreate=true)
public void getPersonList(){
      //得到对应数据
     this.personList=mgr.createQuery....
}
}

�W�二�U�工厂方法：
�q�种工厂�Ҏ��有返回��|��seam会根据scope的值将数据�l�定到对应的上下文中。��用这�U�方法，你不用显式的注出。例如：

�Q�Stateful
@Name("testPerson")
public class TestAction extends TestActionLocal implements Serializable{
protected List personList;
@Factory(value="personList", autoCreate=true)
public List getPersonList(){
      //得到对应数据
     this.personList=mgr.createQuery....
     return personList;
}
}

不管使用哪种�Ҏ��Q�你都可以在��面中直接访问这个factory的��|��

使用�Q�Factory的好处是不用重复的去取��|��但是同时也有一个缺点：
使用@Factory的时候，只有在context中没有这个@Factory所对应的绑定值的时候，seam才会重新执行工厂�Ҏ��来取得这个倹{��所以如果你惌��在CRUD一个实体之后更新列表的话，你可以监听org.jboss.seam.afterTransactionSuccess.XXEntity事�g来更新这个＠Factory的倹{��暂时没扑ֈ�强制清空�q�刷斎ͼ�Factory的方法，seam好像现在�q�没有提供这个方法，所以我现在是直接清�I�＠Factory所对应的list的值来辑ֈ��h��的目的�?br />

seal 2009-05-06 15:30 发表评论

seal — Wed, 29 Apr 2009 02:21:00 GMT

在xhtml��面中加入空��g��能��? " 要��?nbsp;

seal 2009-04-29 10:21 发表评论

h:panelGrid 属性详�?�?

seal — Fri, 24 Apr 2009 00:34:00 GMT

一.��面布局:
样式表基本概�?
单元格样�? columnClasses="columnClasses1, columnClass2,..." <==> ....
行样�? rowClasses="rowClasses1, rowClasses2" <==> ....
样式: styleClass="" ==
�? 无法实现多个表头单元.

panelGrid 标签学习
�q�个标签可以用来作简单的�l��g排版�Q�它会��用HTML表格标签来绘制表��|��q�将�l��g�|�于其中�Q�主要指定columns属性，例如讑֮��?2�Q?

则自动将�l��g分作 2 �?column来排列，排列出来的样子如下：

的本体间只能包括JSF�l��g�Q�如果想要放入非JSF�l��g�Q�例如简单的��L��Q�template�Q�文字，则要使用包括住，例如�Q?

Username

Password

�q�个�l��g用来��数个JSF�l��g包装��h��Q��其看来像是一个组�Ӟ��例如�Q?

�?lt;h:panelGroup>中包括了两个�Q�这使得< h:panelGrid>在处理时�Q�将那两�?lt;h:commandButton>看作是一个组件来看待�Q�其完成的版面配�|�如下所�C�：

下面转蝲与http://blog.csdn.net/liyong1115/archive/2008/02/27/2125029.aspx
一、初识panelGrid和与之相关的设计元素

panelGrid相当于HTML的表��|��在设计中与之相关的组件有panelGrop�Q�与之相配合的CSS

设计元素有styleClass、headerClass、footerClass、rowClasses、columnClasses。这些元

素的有机�l�合�Q�可以设计出不同的输出画面�?

在HTML�|�页设计中，表格�?lt;table>�q�是�?lt;td>起作用的CSS�c�，�q�行��装。如写在style语句�?

�Q�则形如下：

...










默认论坛版面

�{�标记符��P��也可以在标记�W�号内嵌入CSS�?

制语句来控制输出的表现�Ş式。JSF中的panelGrid虽然与HTML表格相对应，但是二者在设计�?

�q�是有很大差异的。例如我们假设有一个HTML的表如下�Q?

...	...
...	...

则panelGrid与之对应的标记是�Q?

...
...
...
...

它只有外��x��讎ͼ�没有行控制和列控制标记�?

熟悉HTML�~�程的道��Z��眼就看出�Q�只有外��x��讎ͼ�你该怎样控制行或列的输出样式呢？�?

急，JSF设计者已�l�想��C��Q�他们设计出

了styleClass、headerClass、footerClass、rowClasses、columnClasses�q�些设计元素来控

制行与列的输出样式，其中
styleClass是格式表格�ȝ��外观的，如表格的长与宽、外�Ҏ��样式、表格的背景样式�{��?
headerClass、footerClass分别是控制表的header和footer的�?
rowClasses和columnClasses分别是控制表格的行与列样式的�?

�q�是举个例子说一下，我们有下例：

styleClass="styleClazz"
headerClass="headerClazz"
footerClass="footerClazz"
rowClasses="row1,row2"
columnClasses="column1"
>

�q�就是一个表��|��columns="1"�Q�规定这个表只有一列，cellpadding="5"说明了边框外�U?

与内�U�的距离�?个像素。这个表�׃��个头部、一个尾部和中间表��n三部分组成。headerClass

是格式头部样式的�Q�footerClass是格式尾部样式的�Q�rowClasses和columnClasses是格式行�?

列样式的�?rowClasses="row1,row2"规定了表格的行与行交替��用row1和row2样式�c�L��格式

输出样式�Q�同��P��列也是，�q�且�q�可以用3个�?个或更多个row3、row4...来依序交替格式输

出样式�?

对应的样式类可以像以下这��L��写在css文�g中：

/*styleClass处于父类的地�?headerClazz,rowClasses�{�的字体讄��取em�?
其在屏幕上显�C�的大小会参照该�c�d��体的大小讄��而放大或�~�小*/

.styleClazz{
font-size:1em;
color:blue;
border-style:solid;
border-color:red;
border-width: 1px;
}

.headerClazz{
background-color:#3F536B;
font-family:宋体;
font-size:1.5em;
color:white;
text-align:center;
}

.footerClazz{
background-color:#3F536B;
font-family:宋体;
font-size:1.5em;
color:white;
text-align:center;
}

/* 当行样式与列样式都用�?则行样式服从于列样式
�Ҏ��的颜色需要在columnClasses中定�?
在rowClasses中定义不起作�?
*/

.row1{
background-color:#FFFFFF;
}

.row2{
background-color:#C9D3E0;
}

.column1{
border-style:solid;
border-color:red;
border-width: 1px;
}

.column2{
}

你可以用CSS在JSP中的语法��其�~�写在JSP文�g中�?

二、panelGrid如何来格式成��h��拆分合�ƈ样式的表

�q�要用到panelGroup�Q�它的作用是��封装在内的元�g作�ؓ一个元件来看待�Q�如果panelGroup

中封装了一个panelGrid�Q�则被封装的表放在其他表中就相当于一个子表。通过panelGroup来封

装各UI�l��g的办法，可以实现表格的拆分目的�?

...

或者：

它们在容器中相当于一个显�C�元�?好像本来是一个�h住一间房�Q�现在是更多的�h住一间房)�?

三、如何在panelGrid中实现设计元素对�?

panelGrid是通过CSS语言来格式输出样式的�Q�在CSS语言中可用vertial-align:...;来格

式输出元素纵向对齐，使用text-align:...;来实现输出元素横向对齐。其中text-align有点

�q�L��人，因�ؓ从字面看它应该是针对文本的，其实它对其他元素也�v作用�?

在对齐的设计中有个居中对齐的问题�Ҏ��l��h。在HTML中可�?lt;center>...来实

现被��装的视囑օ�素居中，但在CSS中好像没有类��D��句。其实还是有的，只不�q�绕了一个弯

。你惛_��Q�说到居中，那究竟是在多宽的范围内居中？是我�q�个元素在封装我的容器中居中�Q?

�q�是被我��装的元素在我这个容器中居中�Q�这个问题CSS与HTML处理语义是不��L��?

在HTML中表格居中是�Q?

...

表格在这里的居中是指�q�个表格“�?#8221;在封装我的容�?lt;body>中居中，具体表现为在屏幕上居

中，但是您不能通过

...

来实现panelGrid�?lt;body>中居中。因为panelGrid标记�Ҏ��不支持这个语句。还是要通过CSS

来实现。下面这个��用CSS语句描述居中的语义与HTML使用align="center"语义不同�?

�q�个语句说的是me�q�个对象在panelGrid 中居中，而不是指表格�?lt;body>(屏幕)中居中。我

要在屏幕中居中怎么办？有两�U�办法，一�U�是通过�?lt;body>中加入格式说明，�W�二�U�办法是�?

panelGrid的外面再套一个panelGrid。即�Q?

�q�样��实��C��被封装的panelGrid B �?A 中居中，注意�Q�这里的width=979px;是必��ȝ��Q�它

规定了居中是在多宽的范围内居中！数字多少可以调整�Q�但是你不能不写�q�个�U�定�Q�否则，�?

��装在里面的panelGrid�q�是不会在屏�q�上居中�?

�q�有一�Ҏ��意，里面panelGrid B 的text-align�l�承外面panelGrid A 中的text-align�?

性的�U�定�Q�即里面的panelGrid不写style="text-align:center"�Q�对象me们也会在�?

面panelGrid中居中。但是里面的panelGrid不��承外面的width�Q�像上面�Q�里面panelGrid的显

�C�宽度与最长的me1有关�Q�而不是外面panelGrid A的宽�?79px�?

四、其�?
■当屏幕的显式格式是1024 X 768 �Ӟ��最外面的panelGrid宽度�?79px是屏�q�最大化�?

底部滚动条由出现��C��出现的��界��|��如超�q?79则滚动条��׃��出现�?
■可以按照是�?lt;table>

item1

item4-panelGroup

seal 2009-04-24 08:34 发表评论

seal — Thu, 23 Apr 2009 07:36:00 GMT

原帖地址�Q�http://odyssi.blogspot.com/2008/01/intro-to-jboss-seam-security-part-1.html

Intro to JBoss Seam Security, Part 1 - Authentication

Recently, I mentioned how I had just started working with the JBoss Seam application framework. The more I have worked with it, the more impressed I have become at how it makes things that are typically difficult using standard Java EE much simpler and more streamlined. One of the areas in which Seam really shines is security. While Java EE defines JAAS for use in securing applications, it is left up to the developer to ingrain this security down to each facet of the application. With Seam, it is easy to define security constraints at all levels of an application, simply through using annotations. In addition, the complexity of authenticating users with JAAS is reduced through Seam's authenticator mechanism. This article will give an introduction to Seam authentication, and show how to write your own custom authenticator.

Seam's authenticator construct hides the complexity of managing a JAAS configuration, and allows you to implement authentication how you see fit. Perhaps your organization relies on a simple username/password combination for authenticating user accounts in LDAP. Maybe you use a SecureID token, and the accounts are stored in a SQL database. By writing your own authenticator class, or making use of publicly available ones, you can control the way authentication is done in your organization.

To get started with your own authenticator, you must first declare it in the components.xml file. This file manages much of the configuration for Seam. To add your authenticator, you simply define the class and method that will be used for authentication. For example:

view plain print ?

xmlns:core="http://jboss.com/products/seam/core"
xmlns:security="http://jboss.com/products/seam/security"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://jboss.com/products/seam/components http://jboss.com/products/seam/components-2.0.xsd
http://jboss.com/products/seam/security http://jboss.com/products/seam/security-2.0.xsd">

You'll notice the #{} syntax used here. This is JBoss' expression language pointing to a class with the instance name of authenticator, where the authenticate method will be used to login a user. Now that we have declared an authenticator to Seam, we're ready to implement it. Our example will be quite simple. If the user enters a username of admin, with a password of password, they will be authenticated successfully. In addition, we will assign them to the role of admin, so that they can perform some sort of administrative function within our application. The implementation of our authenticator would look like this:

view plain print ?

@Name("authenticator")
public class Authenticator {
private static final String valid_user = "admin";
private static final String valid_password = "password";
public boolean authenticate() {
String username = Identity.instance().getUsername();
String password = Identity.instance().getPassword();
if((username.equals(valid_user)) && (password.equals(valid_password))) {
return true;
}
return false;
}
}

Our example is rather trivial. However, it gives a slight glimpse into how Seam authentication works. The first thing that you should notice is the @Name annotation. This annotation prompts Seam to create a bean with the name specified in the annotation. In this case, the name is authenticator, which is how we arrive at the value specified in our components.xml file. Our authenticate method will return true if authentication was successful, and false otherwise.

So how does the authenticate method get the username and password? This is done via the Identity class. The standard Identity class that comes with Seam is quite extensive, but basically provides support for a username/password combination. It is possible to subclass Identity, however, to support whatever authentication mechanisms you may need. You could implement code to support getting a SecureID token value from a user, or a SPNEGO ticket. All that is needed to make use of the Identity subclass is to add the following annotations to your implementation:

view plain print ?

@Name("org.jboss.seam.security.identity")
@Scope(SESSION)
@Install(precedence = APPLICATION)
@BypassInterceptors
@Startup
public class MyCustomIdentity extends Identity
{ ... }

Your custom Identity subclass is now ready for use.

Now that we have our authentication classes in place, we are ready to create our login form. This is trivial to create using Seam, particularly because of Seam's use of the JBoss expression language in forms. Our login form fragment would look like the following:

view plain print ?

That's all there is to it. You are now ready to authenticate users via your own custom login form and authenticator. While this is an introduction to the simplified form of authentication in Seam, it should give you a good foundation to learn and explore on your own.

Next time, we will look at how authentication is used throughout an application, not just at the entry point.

Posted by WhoAmI? at 11:59 AM

seal 2009-04-23 15:36 发表评论

seal — Mon, 20 Apr 2009 12:10:00 GMT

原帖地址�Q�http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/4.3.0.cp04_fp01/html/Seam_Reference_Guide/ch10s02s02.html

Configuring a Seam transaction manager

Seam provides a transaction management abstraction for beginning, committing, rolling back, and synchronizing with a transaction. By default Seam uses a JTA transaction component that integrates with Container Managed and programmatic EJB transactions. If you are working in a Java EE 5 environment, you should install the EJB synchronization component in components.xml:

However, if you are working in a non EE 5 container, Seam will try auto detect the transaction synchronization mechanism to use. However, if Seam is unable to detect the correct transaction synchronization to use, you may find you need configure one of the following:

JPA RESOURCE_LOCAL transactions with the javax.persistence.EntityTransaction interface. EntityTransaction begins the transaction at the beginning of the apply request values phase.
Hibernate managed transactions with the org.hibernate.Transaction interface. HibernateTransaction begins the transaction at the beginning of the apply request values phase.
Spring managed transactions with the org.springframework.transaction.PlatformTransactionManager interface. The Spring PlatformTransactionManagement manager may begin the transaction at the beginning of the apply request values phase if the userConversationContext attribute is set.
Explicitly disable Seam managed transactions

Configure JPA RESOURCE_LOCAL transaction management by adding the following to your components.xml where #{em} is the name of the persistence:managed-persistence-context component. If your managed persistence context is named entityManager, you can opt to leave out the entity-manager attribute. (see Section 10.3, “Seam-managed persistence contexts”Seam-managed persistence contexts)

To configure Hibernate managed transactions declare the following in your components.xml where #{hibernateSession} is the name of the project's persistence:managed-hibernate-session component. If your managed hibernate session is named session, you can opt to leave out the session attribute. (see Section 10.3, “Seam-managed persistence contexts”Seam-managed persistence contexts)

To explicitly disable Seam managed transactions declare the following in your components.xml:

For configuring Spring managed transactions see Section 24.5, “Using Spring PlatformTransactionManagement”using Spring PlatformTransactionManagement. .

seal 2009-04-20 20:10 发表评论

JSF Validator(�?

seal — Tue, 14 Apr 2009 02:58:00 GMT

JSF Validator入门基础��?- JSF Validator的介�l�与使用

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄��功能�Q�以帮助用户能正��输入�?/span>

在开始本文之前，��阅读下面的文章：
深入了解JSF
深入了解JSF�Q�二�Q�：从JSF的Lifecycle看JSF寚w��面的处理机制和流�E?/strong>
以了解JSF的概�늭��?br />
JSF Validator图：

JSF Validator特点�Q?/div> 输入数据的验证放在服务器端进行�?br /> 需要验证输入值的�l��g�Q�输入组�Ӟ��在JSP里通过JSF标签加以讄��Q�方法简单直观�?br /> 每个输入�l��g可以同时�l�定多个Validator�?br /> 验证发生错误�Ӟ��可以向FacesContext��d��错误信息�Q��ƈ且可以通过JSP直接昄��。显�C�风��g��位置可以自由讑֮��?br /> 验证错误�Ӟ��JSF的生命周期控制机制自动中止处理流�E�，跌��{到画面描画阶�D�（Render Response Phase�Q��?br /> JSF标准提供�Ҏ��|��long, double�Q�的最大最��值验证，文字列的最大最��长度验证，以及必须(required)验证�{�Validator�?br /> 支持用户自定义Validator。用戯��定义Validator的方法有2�U�，一�U�是Method Validator�Q�一�U�是实现javax.faces.validator.Validator接口。本文的后面��对其作详细介绍�?br />

JSF标准Validator

validateDoubleRange

Validator标签名：f:validateDoubleRange标签�?br />   属性名�Q?br />       maximum="最大�?
      minimum="最��?
Validator ID�Q�javax.faces.DoubleRange
Validator �c�：javax.faces.validator.DoubleRangeValidator
输入值的范围验证�?br /> 输入值必��MؓNumber�Q�数��|��c�d��或者可以�{换�ؓDouble�c�d��的�?br />

validateLongRange

Validator标签名：f:validateLongRange
  属性名�Q?br />       maximum="最大�?
      minimum="最��?
Validator ID�Q�javax.faces.LongRange
Validator �c�：javax.faces.validator.LongRangeValidator
输入值的范围验证�?br /> 输入值必��MؓNumber�Q�数��|��c�d��或者可以�{换�ؓLong�c�d��的�?br />

validateLength

Validator标签名：f:validateLength
  属性名�Q?br />       maximum="最大�?
      minimum="最��?
Validator ID�Q�javax.faces.Length
Validator �c�：javax.faces.validator.LengthValidator
输入值的长度验证�?br /> 输入值必��MؓString�Q�字�W�串�Q�或者可以�{换�ؓString�c�d��的�?br />

JSF required�Q�必��输入） Validator
JSF的几个输入组件还可以使用required属性简单地验证表单元素是否得到输入�?br />

JSF Validator的��?/div> 各输入组件��用required validator的方法上面已�l�作了介�l�，�q�里不再重复�?br />

使用Method Validator

JSF支持Method�U�别的Validator�Q�这�U�Validator实现��h��比较��单，可以在�Q何JSF的managed-bean里实��C��个类��g��下的�Ҏ��Q?br />

view plain print ?

public void validateXxxx(FacesContext context,

        UIComponent component, Object value){



    String text = value.toString();

    if(!text.equals("xxxx")){

        throw new ValidatorException(new FacesMessage("some message"));

    }

}

public void validateXxxx(FacesContext context,         UIComponent component, Object value){     String text = value.toString();     if(!text.equals("xxxx")){         throw new ValidatorException(new FacesMessage("some message"));     } }

其中�Q�context变量为JSF容器上下文环境，component�? �l�定的组�Ӟ��value为组件的输入倹{��validateXxxx可以��Z�Q意你喜欢的方法名。与预期的输入��g��W�合的话�Q�可以通过throw一�? ValidatorException�?some message"便是惌��昄��的错误消息�?br />
然后在JSP中：

view plain print ?



便可�?br /> 错误消息的显�C�稍后再作介�l��?br />

Validator标签的��?/h3>
Validator标签可以接收参数�Q�所以功能上比较强大�Q�也比较灉|��。同�Ӟ��除了使用JSF标准的Validator标签之外�Q�你�q�可以自定义Validator标签。关于自定义Validator标签我们��在另外的文章中加以介绍�?br /> Validator标签的��用例�Q?br />

view plain print ?









�? 例对id为xxxxValue的输入框�l��g的输入值做double范围验证�Q�指定范围最大��gؓ5。超�q?的情况则昄��错误消息�Q�错误消息可以�� ?lt;h:message />或�?lt;h:messages />标签昄��。有��x��息处理的详细介绍请参考：
JSF全面理解之消息处�?/strong>
一�?br />

f:validator标签的��用与Validator ID

除了以上2�U�验证方法之外，�q�可以��用f:validator标签对输入值加以验证。f:validator标签需要指定validatorId属性，Validator Id需要在faces-config.xml配置文�g中加以配�|��?br />

f:validator标签的��用例�Q?br />

view plain print ?









"Some Validator ID"为具体的Validator ID�Q�我们将在自定义Validator标签一文中对Validator ID做详�l�介�l��?br />
JSF框架��调用指定Validator ID所对应的Validator�?br /> public void validate(FacesContext context, UIComponent component, Object value)
�Ҏ��?br />
跟Method Validator一��P��不能f:validator标签传入参数�?br />
本文介绍了JSF Validator的机�Ӟ��特点�Q�种�c�，以及使用�Ҏ��{�。我们将在近期其它文章中介绍怎么自定义Validator�?br />
JSF Validator�q�阶��?- 自定义JSF Validator

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄��功能�Q�以帮助用户能正��输入�?/span>

�?JSF Validator入门基础��?- JSF Validator的介�l�与使用  一文中我们介绍了JSF Validator的机�Ӟ��特点�Q�种�c�，以及使用�Ҏ��{��?br />
本文��介�l�怎么自定义Validator和Validator标签�?br />
自定义Validator�?�U�方法：一�U�是Method Validator�Q�我们在JSF Validator入门基础��?- JSF Validator的介�l�与使用  一文中已作了介�l�，�q�里不再详述�Q�另一�U�是通过实现Validator接口�Q�也��是使用自定义的Validator�c�R�?br />
自定义Validator�c�M��Validator标签有以下几个步骤：
自定义Validator�cȝ��实现
faces-config.xml��d��
自定义Validator标签�c?br /> 讄��TLD文�g

自定义Validator�cȝ��实现
定义一个类�Q�该�c�d��现javax.faces.validator.Validaotr接口�Q?br />
MyValidator.java

view plain print ?

package com.mypackages;



import javax.faces.validator.Validaotr;



public class MyValidator implements Validator {

    public void validate(FacesContext context, UIComponent component, Object value)

            throws ValidatorException {



        String text = value.toString();

        if(!text.equals("xxxx")){

            throw new ValidatorException(new FacesMessage("some message"));

        }

    }



    ... //其它参数讄��Q�方法等�Q�略�Q?nbsp;

}

package com.mypackages; import javax.faces.validator.Validaotr; public class MyValidator implements Validator {     public void validate(FacesContext context, UIComponent component, Object value)             throws ValidatorException {         String text = value.toString();         if(!text.equals("xxxx")){             throw new ValidatorException(new FacesMessage("some message"));         }     }     ... //其它参数讄��Q�方法等�Q�略�Q? }

faces-config.xml��d��
自定义Validator�c�M��后，�q�得向faces-config.xml��d��之后才能使用�?br /> faces-config.xml

view plain print ?



  "-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.0//EN"

  "http://java.sun.com/dtd/web-facesconfig_1_0.dtd">









        MyValidator

        com.mypackages.MyValidator





             MyValidator         com.mypackages.MyValidator

�l�过上面2个步骤，��可以��用MyValidator了�?br /> 例：



自定义Validator标签�c?/div> 上面的MyValidator虽然可以通过f:validator标签加以利用�Q?但不能向其传入参敎ͼ�若要向其传入参数�Q�则需要定义自定义Validator标签�c�R�?br /> MyValidatorTag.java

view plain print ?

package com.mypackages;



import javax.faces.webapp.ValidatorTag;



public class MyValidatorTag extends ValidatorTag{



    private String xxxParam;



    public MyValidatorTag(){

        setValidatorId("MyValidator");

    }



    protected Validator createValidator() throws JspException {

        MyValidator validator =  (MyValidator)super.createValidator();

        validator.setXxxParam(xxxParam);

        return validator;

    }



    public String getXxxParam() {

        return xxxParam;

    }



    public void setXxxParam(String xxxParam) {

        this.xxxParam = xxxParam;

    }

}

package com.mypackages; import javax.faces.webapp.ValidatorTag; public class MyValidatorTag extends ValidatorTag{     private String xxxParam;          public MyValidatorTag(){         setValidatorId("MyValidator");     }          protected Validator createValidator() throws JspException {         MyValidator validator =  (MyValidator)super.createValidator();         validator.setXxxParam(xxxParam);         return validator;     }     public String getXxxParam() {         return xxxParam;     }     public void setXxxParam(String xxxParam) {         this.xxxParam = xxxParam;     } }

另外�Q��ؓMyValidator.java加入相应参数及方法实现�?br />

TLD文�g
定义好Validator标签�c�M��后，�q�需要在TLD文�g讄��Q�有关TLD�q�里��׃��介绍了。请大家参考相兌��料�?br />
MyValidator.tld

view plain print ?



  PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.2//EN"

  "http://java.sun.com/dtd/web-jsptaglibrary_1_2.dtd">



    1.0

    1.2

    myv

    my validator tag

    my validator tag





        validateMyData

        com.mypackages.MyValidatorTag



            xxxParam

            false







    1.0     1.2     myv     my validator tag     my validator tag              validateMyData         com.mypackages.MyValidatorTag                      xxxParam             false

自定义Validator标签的��?/div> web.xml

view plain print ?



  /WEB-INF/MyValidator.tld

  /WEB-INF/MyValidator.tld



  /WEB-INF/MyValidator.tld   /WEB-INF/MyValidator.tld

JSP

view plain print ?

<%@ taglib uri="WEB-INF/MyValidator.tld" prefix="myv" %>



...









<%@ taglib uri="WEB-INF/MyValidator.tld" prefix="myv" %> ...

seal 2009-04-14 10:58 发表评论

seal — Mon, 13 Apr 2009 07:34:00 GMT
原帖地址�Q�http://blog.csdn.net/bq_cui/archive/2007/03/21/1536706.aspx

开始学习seam的时候，有两个问题：我会用Spring和Hibernate�Q�但一点也不懂Seam 和EJB3�?EntityManager。我用了一些时间学习seam�Q�但EntityManager 一直困扰我�?span>
    同时我也有了一些小收获�Q�愿意跟刚刚开始学习seam的朋友分享以下。别紧张�Q�我不敢��信我写的东襉K��正确 ;).
    好了�Q�关于EntityManager有何用处�Q�它��理你的entities ;)�?那是一些简单的java对象�Q�通过getters and setters具备一些属性。这些属性之一是id�Q�一般是Long数据�c�d��Q�，�q�且�q�些class必须以@Entity注解(annotated )。在seam的源码中可以扑ֈ�一大批�q�样的例子，例如booking例子。在seam中，一件很重要的事情就是，每个Entity都有一�? @Name 注解(annotation)�Q�这��P��它们才能被注入到其他seam部�g(component)中�?br />     假设我们有这样一个entity class�Q�叫�?Entity"。其生命周期内包含以下功能：
�?/p>
�?/p>
�?/p>
�?/p>
EntityManager 提供了这些功能。首先，如何把EntityManager 引入我的代码�Q�很��单：

@PersistenceContext
private EntityManager em;

    好了�Q�我们看看一个Entity �q�程如何产生�Q?/p>

Entity entity = new Entity();

    �q�很��单。现在，�q�entity 的状态是NEW/TRANSIENT 。这意味着一个entity已经存在于你的应用程序中�Q�但�q�不��h��id�Q�也不存在于你的数据库中�?br />
    �׃��我们要��它持久化�Q�即它应被写入数据库�Q�，我们应把它的状态�{换�ؓMANAGED �?/span>

em.persist(entity);

    现在�Q�此entity由EntityManager��理了。EntityManager控制entity写入数据库。这动作无须立刻发生�Q�可能把你的entity攑֜�cache�Q�稍后写入数据库。你可以攑ֿ��Q�写动作肯定会发生�?br />
Ok, what about reading an existing entity from the database? Therefore we use:

好，如何从数据库中读出已存在的entity呢？�q�样�Q?/p>

Entity entity = em.find(Entity.class, Id);

    每个entity 有一个id�Q�我已经说过�Q�多数情况下是Long数据�c�d��Q�，通过id你可存取entity。这是这里的�W�二个参数。第一个参��C��表你要存取的Entity class的进�E�。find操作之后�Q�entity的状态也�?span style="font-weight: bold;">MANAGED �?/span>

一旦entity数据有所改变�Q�将反映到数据库中。不能确认EntityManager何时会向数据库写入更新的数据。但是这一事�g肯定会发生，一般是马上�Q�但不会晚于EntityManager消失;)。你可以控制触发更新数据库：

em.flush();

     �q�将强制EntityManager 立刻��更新写入数据库。请��C��Q�这条语句将影响所有状态�ؓMANAGED�?/span>entitie�Q�而不是当前一个。不�q�，一般情况下不必�q�么做�?br />     如果你想反其道而行之，也就是从数据库蝲入一�?span>entity �Q�因为别人可能已�l�修改其数据�Q�，�q�么写：

em.refresh(entity);

    怎样删除一个entity呢？很简单：

em.remove(entity);

    现在�Q�entity的状态成�?span style="font-weight: bold;">REMOVED�Q�表�C�其已经被列入删除计划。你可以�?/span>flush()语句�Q�让删除动作马上发生�Q�但没必要这么干�?br />
    现在来点复杂的。当注入EntityManager 的时候，有一�?span style="font-weight: bold;">事务范围持久上下文（ Transaction Scoped Persistence Context�Q�。当entitie处在MANAGED状态时�Q�其处在持久上下文（persistence context �Q�的“容器”中�?#8220;事务范围”意味什么？首先�Q�什么是“事务”�Q?br />
    EJB3Stateful �?Stateless beans (依同名标注��L�?的每个方法调用都包装��C��个事务内。（��Z��说一下，事务一旦发生RuntimeException�Q�即发生会滚�Q�对数据的改变将撤销�Q�。因此，持久上下文（persistence context�Q�将在调用方式之前徏立，方式调用�l�束后移除。然后，持久上下文中��理的所有entity的状态成�?span style="font-weight: bold;"> DETACHED�?/span>

    假设在你的bean里头有两个method。第一个是load(), 它调用find函数取出数据库中的一个实体。第二个是finish()�Q�返回一个JSF输出。调用这两个函数中间修改了实体数据。这�U�修�Ҏ��久到数据库中吗？回答是：NO�?br />
    load() 函数�l�束后，EntityManager'的持久上下文�l�束�Q�它所有管理过的entity状态成为DETACHED。一个后果是�Q�与新entity相反-有一个ID�Q�但他们的状态�ƈ不是managed �Q�对�q�些detached entities 所作的更新�q�不影响数据库。如果你想��一个entity 更新数据库，需要将光��新attach到持久上下文。在�q�个例子中，�?span>finish()�Ҏ��中增加以下行�Q?br />

em.merge(entity);

    现在�q�个entity 已经合�ƈ到finish()�Ҏ��的持久上下文�?��C��Q�每个方法是一个事务，每个事物有自��q��持久上下�?�Q��ƈ且状态是又变为managed�?br />
     �q�样做是可以的，但有两个�~�点�Q?br /> -需要调用merge(->多了一些代�?
-调用find()之前�Q�如果某个entity未初始化�Q�而你又要存取它的某些属性，��会得到exception 错误�?br />
    有一个简单的解决�Ҏ��Q�扩展持久上下文的生命期�Q�这��P��当调用多个事�?�Ҏ��Ӟ��entity状态始�l�保持�ؓmanaged 。因此，我们改变EntityManager的注入方式：

@PersistenceContext(type=PersistenceContextType.EXTENDED
private EntityManager em;

     现在�Q�managed entities "生活�?一个扩展持久上下文�? Extended Persistence Context )�?br />
    你甚��x��d��叫merge()�Ҏ��Q�因为eitities从未被DETACHED。你可能会问�Q�普通事务范��_�� "normal" (transaction scoped) �Q�持久上下文的好处是什么？它一直依附于你做的事情（��崔�Q�什么意思？�Q�。扩展上下文需要更多的内存�Q�因为即使你不需要，它也一直存在于内存。�ƈ且一旦entities被其他的bean改变�Q�它们有自己的持久上下文�Q�，你需要显式地调用refresh()�Ҏ��Q�在overviews/list��面�Q�。当你需要普通EntityManager 时它��在那里�Q�因其生命周期短�Q�只能操作即时数�?)

    当谈及列表：为取得不止一个实体，而是一个实体集合，使用�Q?br />

List<Entity> entities = em.createQuery("from Entity").getResultList();

    �q�不�?#8220;真正”SQL�Q�而是�c�M��sql的东西，�U�C��?span>EJBQL。你可以用它执行某些条�g查询�Q�排序等�Q�如

..."from Entity where lastName=".nameToSearchFor." order by firstName"

    仅��用entity属性名�U�即可。关于EJBQL 要说的太多了�Q�但对于本篇介绍来说�q�已��_��?br />
    好，基本介绍到此为止。希望对你来��_��在如何��用EntityManager斚w��Q�这一个简单易懂的介绍�?br />
    我已声明�q�，不能保证癑ֈ�百正��。�ƈ且肯定有许多��p��语法错误(对不��P��我是德国人，不要打我PP�?。欢�q�斧正�?br />

2007.4.11��译自：
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=88460

seal 2009-04-13 15:34 发表评论

SEAM中JSTL标签和ui标签的�؜合��?c:forEach vs ui:repeat)

seal — Mon, 13 Apr 2009 00:52:00 GMT

c:forEach vs ui:repeat in Facelets

Posted by Roger Keays, 7 June 2007, 12:28 PM

This is probably one of the most frequently asked questions on the Facelets mailing list. Why doesn't my c:forEach tag work correctly? Unfortunately, there are may ways to misuse the jstl tags available in Facelets, so the answer isn't always simple. Here is an explanation of the differences between c:forEach and ui:repeat, along with some examples which will hopefully save you some headaches.

TagHandlers vs Components

The most important thing to understand about the jstl tags in Facelets is that they do not represent components and never become a part of the component tree once the view has been built. Rather, they are tags which are actually responsible for building the tree in the first place. Once they have done their job they expire, are no more, cease to be, etc etc.

Here is a table of the semantics of several common tags. I just discovered, reading the Facelets code, that validators and converters are classified separately. I had always thought they were just tag handlers, but I imagine they behave in much the same way.

TagHandlers
Components
Other

c:forEach
c:choose
c:set
c:if
f:facet
f:actionListener
f:valueChangeListener
ui:include
ui:decorate
ui:composition
any custom tag file

ui:repeat
ui:fragment
ui:component
f:view
f:verbatim
f:selectItems
h:inputText
h:datatable
any custom UIComponent
f:validator
f:converter

One of the problems here is that there is no naming convention to indicate which tags correspond to which constructs. You've just got to know, or find out.

When is the view built?

Now that you understand that tag handlers are only effective when the tree is built, the next logical question should be well, when is tree built?

The short answer is that a new view is built for every request which is not a postback. During a postback, the view is reconstructed from saved state. Quite confusing, and not very obvious I know, but there you have it.

Common laments

The most common pitfalls are either with the JSF lifecycle, EL evaluation or combining tag handlers with components.

My c:if always evaluates to false

Yes, the c:if is always evaluating to false! But it is only ever evaluated once - when the tree is built. The h:outputText component never makes it into the tree. Solution: replace the c:if with:

...

You could also use the rendered attribute on the h:outputText component in this example.

My ui:include fails inside ui:repeat



The EL for the ui:include is evaluated when the view is built and is invalid since it relies on a variable only made available by the ui:repeat during rendering. Use c:forEach in this case.

My recursive tag never stops

myTag.xhtml:

The stop condition in this recursion is supposed to be when you run out of children. The problem is that the custom eg:myTag is just a tag handler, like a special version of ui:include. When the view is built, the ui:repeat has no influence on the building process and can't stop the recursion. Use c:forEach here instead of ui:repeat. Or better still, convert your tag file to a real UIComponent.

You might also recognise that the ${child} EL expression is meaningless during build time in this example, unless you use c:foreach.

My list doesn't change size after deleting or adding an item

When your view was built you only had, say, 5 items. If you post back to this view and add or delete an item, your view still has 5 h:outputText components in it since it was restored from saved state. In this simple case, you should use ui:repeat and your tree will always contain one h:ouputText component which is iterated over with differing values of ${item}.

If you rely on using c:forEach to dynamically include different form components you could run into difficulty. Always try to think about what the resulting tree looks like and remember it doesn't change on a postback.

Suggestions for the future

Probably the best relief to this problem would be to come up with a better syntax or naming convention to distinguish between tag handlers and components. I imagine you could also improve compilation performance if you did this.

Secondly, we need better terminology. I've used the terms tag handler and component in this blog which isn't too bad. The Facelets' FAQ [1] uses the terms build-time tags and render-time tags which is a bit misleading because render-time tags (components) are involved in all phases of the JSF lifecycle, not just the Render View phase.

Whatever happens, tag handlers are very useful (would you use facelets without ui:decorate?) so let's not get rid of them.

References

[1] http://wiki.java.net/.../FaceletsFAQ#Why_doesn_t_my_c_if_ui_repeat_ui

seal 2009-04-13 08:52 发表评论

seal — Thu, 09 Apr 2009 02:54:00 GMT

Selecting from a list of entities

See http://docs.jboss.org/seam/latest/reference/en/html/controls.html

Use to produce a list of labeled select items from a list of entities.

Use to map back and forth between the select items and the actual entity values. This is what allows you to map the value of the directly to the property of the referencing entity (e.g. a property that is a many-to-one).

(1)
label="#{continent.name}" noSelectionLabel="Please Select..."/>
(3)

person is an entity that has been outjected into the conversation. It has a 'continent' property which is many-to-one association with another entity.

continents is a Seam application framework 'query' object. This 'query' object should probably use a Seam-managed EntityManager because we want have the Hibernate session-in-view behavior so we don't get lazy initialization exceptions when rendering the labels, etc.

s:convertEntity will convert the Continent entities into values for the HTML select, and vice versa.

Tips

To avoid LazyInitializationExceptions and/or writing extra code in your EJB/Controller bean to initialize objects, use session in view.

For required fields, put required="true" on the selectOneMenu and override javax.faces.component.UIInput.REQUIRED in messages.properties (see Standard Faces Error Messages).

Select from an enum

This works just like selecting an entity, but is used instead.

XHTML:

required="true">
label="#{status}"
noSelectionLabel="Select a status..."/>

EnumLists.java:

@Name("enumLists")
@Scope(ScopeType.STATELESS)
public class EnumLists
{
public Status[] getStatusArray()
{
return Status.values();
}
}

person is an entity that has been outjected into the conversation. It has a 'status' property which is an enum.

We need to expose the values of the enum as a list or an array, so we make a stateless POJO component with getters that returns arrays for various enums called enumLists.

Multi-select from an enum

Here we use a selectManyCheckbox.

layout="pageDirection" value="#{person.roles}"
required="true">
label="#{role}"/>

Unfortunately, Seam's convertEnum can't handle multi selects yet. This example will yeild a strange exception:

java.lang.IllegalArgumentException: java.util.List is not an enum type

Luckily, it's very easy to create custom converter tags with Facelets. Here is the converter class that handles both ordinary enums and multi-selects:

package eg;

import javax.faces.component.*;
import javax.faces.context.*;
import javax.faces.convert.*;
import javax.faces.el.ValueBinding;
import java.util.List;
import java.util.Collection;

/**
* Converter for enum multi-selects.
*
User: Joshua Davis
* Date: May 16, 2007
* Time: 7:25:58 AM
*/
public class EnumListConverter implements Converter
{
@SuppressWarnings({"unchecked"})
public Object getAsObject(FacesContext context,
UIComponent comp,
String value)
throws ConverterException
{
ValueBinding binding = comp.getValueBinding("value");
Class enumType = binding.getType(context);
if (enumType.isEnum()) // Single enum?
return Enum.valueOf(enumType, value);
else // List of enums.
{
// Find the s:selectItems so we can get the enum.
List children = comp.getChildren();
for (Object child : children)
{
if (child instanceof UIComponent)
{
UIComponent c = (UIComponent) child;
ValueBinding b = c.getValueBinding("value");
Class t = b.getType(context);
// Array of enums: use the component type.
if (t.isArray() && t.getComponentType().isEnum())
{
t = t.getComponentType();
return Enum.valueOf(t,value);
}
else
{
Object v = b.getValue(context);
// Collection of enum values, get the type of the first element.
if (v instanceof Collection)
{
t = ((Collection) v).iterator().next().getClass();
return Enum.valueOf(t,value);
}
}
}
}
throw new ConverterException("Unable to find selectItems with enum values!");
}
}

public String getAsString(FacesContext context,
UIComponent component,
Object object)
throws ConverterException
{
if (object == null) {
return null;
}

return ((Enum) object).name();
}

}

Retrieved from "

seal 2009-04-09 10:54 发表评论

Richfaces�?lt;a4j:repeat>标签判断最后一个元素的�Ҏ��

seal — Thu, 02 Apr 2009 09:42:00 GMT

使用rowKeyVar按照上面的方法判断就可以�?br />

seal 2009-04-02 17:42 发表评论

seal — Wed, 01 Apr 2009 05:47:00 GMT

How to iterate over java.util.Set in JSF
By bozhobg
I spent quite some time trying to find a solution for the following JSF issue: it is not possible to iterate over a java.util.Set.
- ui:repeat (facelets) doesn’t work
- a4j:repeat (richfaces) doesn’t work
- c:forEach works..only in case it does not rely on a variable defined by a parent component (rich:dataTable for instance)

All above are pretty logical phenomena, as UIData relies on ordered data, and generally a Set is not ordered.

In my case I had to use a Set defined in the Hibernate (JPA) object (PersistentSet).
An important note: you should use a set in case the view order is of no matter to you.

The solution..is pretty simple. And I’ll suggest it to be a part of facelets/richfaces for the next version, unless of course there is some valid specific

reason for it not to be.

1. Define your own UI component extending an existing repeater component. I used a4j:repeat (HtmlAjaxRepeat)
2. Override the metohd getDataModel
3. Define your component in your faces-config
4. create a custom facelets tag definition
5. Define a context-variable in web.xml pointing to the facelet tag definition.

Note: for use with JSP instead of Facelets, you should define a .tld and a Tag handler, which is not an ojbect of this post.

Now let’s see the steps in detail:

1,2. Here some code:

view plain copy to clipboard print ?

package com.myproject.components;

import java.util.ArrayList;

import java.util.Set;



import javax.faces.model.DataModel;

import javax.faces.model.ListDataModel;



import org.ajax4jsf.component.html.HtmlAjaxRepeat;

import org.ajax4jsf.model.SequenceDataModel;



public class UIIterator extends HtmlAjaxRepeat {



   @SuppressWarnings("unchecked")

   @Override

   protected DataModel getDataModel() {

      Object current = getValue();

      if(current instanceof Set){

          return new SequenceDataModel(new ListDataModel(

                new ArrayList((Set) current)));

      }

      return super.getDataModel();

   }

}

package com.myproject.components; import java.util.ArrayList; import java.util.Set; import javax.faces.model.DataModel; import javax.faces.model.ListDataModel; import org.ajax4jsf.component.html.HtmlAjaxRepeat; import org.ajax4jsf.model.SequenceDataModel; public class UIIterator extends HtmlAjaxRepeat { @SuppressWarnings("unchecked") @Override protected DataModel getDataModel() { Object current = getValue(); if(current instanceof Set){ return new SequenceDataModel(new ListDataModel( new ArrayList((Set) current))); } return super.getDataModel(); } }

So, as we don’t care about the order of the elements, we just create a new ArrayList out of the Set. And we can now easily return the appropirate DataModel.

3. Add this to your faces-config. (I copied it from the a4j definition)

view plain copy to clipboard print ?





        Iterator

        com.myproject.Iterator

        com.myproject.components.UIIterator





            javax.faces.Data

            org.ajax4jsf.components.RepeatRenderera





Iterator com.myproject.Iterator com.myproject.components.UIIterator javax.faces.Data org.ajax4jsf.components.RepeatRenderera

4. Here is the tag definition for facelets

view plain copy to clipboard print ?



"-//Sun Microsystems, Inc.//DTD Facelet Taglib 1.0//EN"

"http://java.sun.com/dtd/facelet-taglib_1_0.dtd">



http://myproject.com/cust





repeat



com.myproject.Iterator

org.ajax4jsf.components.RepeatRenderer









http://myproject.com/cust repeat com.myproject.Iterator org.ajax4jsf.components.RepeatRenderer

Save this file as /WEB-INF/facelets/custom.taglib.xml

5. Add to your web.xml

view plain copy to clipboard print ?



facelets.LIBRARIES

/WEB-INF/facelets/custom.taglib.xml



facelets.LIBRARIES /WEB-INF/facelets/custom.taglib.xml

6. It is now ready to use
…
xmlns:cust=”http://myproject.com/cust”
…

…

I think it is way neater than other workarounds, like defining a custom EL Resolver.

seal 2009-04-01 13:47 发表评论

TagHandlers	Components	Other
c:forEach c:choose c:set c:if f:facet f:actionListener f:valueChangeListener ui:include ui:decorate ui:composition any custom tag file	ui:repeat ui:fragment ui:component f:view f:verbatim f:selectItems h:inputText h:datatable any custom UIComponent	f:validator f:converter

亚洲欧洲日本精品,亚洲VA中文字幕无码一二三区,中文字幕亚洲天堂

Setting the conversation-timeout in Seam, why it really does work

javascript CDATA的意�?

1.74. Why does Java Script conflict?

Seam扩展事务消息

解决Safari中Richfaces某些�l��g不兼容的问题

Seam中简单的checkbox操作

Seam ��目部��v�?tomcat �?�?

rich:tree中drag和drop后reRender对应的tree

SEAM的PAGE和CONVERSATION context

Concurrent calls to conversational components

7.11.1. How should we design our conversational AJAX application?

7.11.2. Dealing with errors

503 Service Unavailable (HTTP/1.1 RFC)

7.11.3. RichFaces Ajax

又一个有点变态的Seam错误�Q?Property ‘xxx�?not readable on type java.lang.Boolean

Seam错误�Q�org.jboss.seam.InstantiationException: Could not instantiate Seam component

在rich:inplaceSelect 中��用布���型的selectItem时碰到的问题

How do I set the Transaction Timeout?

Seam错误�Q�deleted entity passed to persist

提高JSF�Q�SEAM�E�序的效率（转）

Introduction

About the EDAS2 application

The editable data table

A backend supported by Seam

The performance roadblock

Page actions and component initialization

The cost of conditional rendering

Seam's managed entity interceptor

Resolving variables efficiently

Cutting costs with Ajax

Tapping into Ajax

Accessible Ajax with Ajax4jsf

Keeping the Ajax call brief

Trimming down the response

Resources

h:panelGrid 属性详�?�?

原帖地址�Q�http://odyssi.blogspot.com/2008/01/intro-to-jboss-seam-security-part-1.html

Intro to JBoss Seam Security, Part 1 - Authentication

Configuring a Seam transaction manager

JSF Validator(�?

JSF Validator入门基础��?- JSF Validator的介�l�与使用

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄���功能�Q�以帮助用户能正���输入�?/span>

validateDoubleRange

validateLongRange

validateLength

使用Method Validator

f:validator标签的��用与Validator ID

JSF Validator�q�阶��?- 自定义JSF Validator

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄���功能�Q�以帮助用户能正���输入�?/span>

SEAM中JSTL标签和ui标签的�؜合���?c:forEach vs ui:repeat)

c:forEach vs ui:repeat in Facelets

TagHandlers vs Components

When is the view built?

Common laments

Suggestions for the future

References

Selecting from a list of entities

Tips

Select from an enum

Multi-select from an enum

Richfaces�?lt;a4j:repeat>标签判断最后一个元素的�Ҏ��

How to iterate over java.util.Set in JSF

在rich:inplaceSelect 中��用布��型的selectItem时碰到的问题

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄��功能�Q�以帮助用户能正��输入�?/span>

JSF框架提供Validator机制�Q�对用户输入值的合法性进行验证。若用户输入值无效，�q�提供了错误消息昄��功能�Q�以帮助用户能正��输入�?/span>

SEAM中JSTL标签和ui标签的�؜合��?c:forEach vs ui:repeat)