resources.properties

一个比较好的jsf spring hibernate的例子

background1=This demo demonstrates the use of multiple <i>RenderKits</i> in a JSF application.\n  The demo application consists of three <i>RenderKits</i>: <i>Standard HTML RenderKit,  SVG RenderKit,  XUL RenderKit</i> - used to render their respective markups.  The markup for the page you are viewing has been produced with the <i>Standard HTML RenderKit</i>.
background2=The theme of the demo is the JSF <i>Lifecycle</i>. The <i>SVG</i> page will display a diagram of the JSF <i>Lifecycle</i> phases.  Pressing any of the buttons on the lower left corner of the diagram, produces an animation that shows how a <i>request</i> flows through each of the JSF <i>Lifecycle</i> phases.   The <i>SVG</i> markup for the <i>SVG</i> page is produced from an <i>SVGRenderKit</i>.  Pressing on any of the <i>Lifecycle</i> phase boxes, performs an <i>HTTP post</i> to JSF, and the next view is returned.  The <i>response</i> that is returned is the markup (and <i>view identifier</i> for a <i>XUL</i> page that represents more detailed information about the JSF <i>Lifecycle</i> phase selected.  We'll go into more detail in the next section.   

detail1=The <i>HTTP post</i> mechanism is built into <i>HTML</i> (it happens when a form submit occurs).  Markup languages such as <i>SVG</i> or <i>XUL</i> do not have the built in <i>HTTP post</i> mechanism.  <i>JavaScript</i> is used to register an event handler, (<i>onclick</i> for example), so that when the graphic representation of the button is pressed, an event is triggered.  The <i>onclick</i> event handler collects the form input data, builds a <i>post data</i> string, and sends it to the server.  From <i>SVG</i> there are a couple of different ways to post data to a server from <i>JavaScript</i>.  This demo relies on the built in <i>SVG</i> support in <i>Mozilla Firefox</i>.  So the posting mechanism that is available is <i>XMLHttpRequest</i>. <i>XMLHttpRequest</i> is used to post to JSF.  It is also used to handle the <i>response</i> from JSF.  The <i>request</i> that is sent to JSF is a <i>postback request</i>.  The <i>request</i> flows threw the JSF <i>Lifecycle</i>, and the next view is determined in the <i>Invoke Applications Phase</i>.  A <i>PhaseListener</i>, <i>ResponsePhaseListener</i> has been registered to operate after the <i>Invoke Applications Phase</i>.  Its purpose is to propogate the new <i>view identifier</i> into the <i>response</i>.  Now the <i>JavaScript</i> callback handling the <i>response</i> from JSF knows what view to display next.
restoreHeader=Restore View Phase
restoreCaption=Restore View Detail 
restoreDescription1=Examine the <html:i>FacesContext</html:i> instance for the current request. If it already contains a <html:i>UIViewRoot</html:i>:
restoreDescription2=<html:ul><html:li>Set the locale on this UIViewRoot to the value from the request's locale.</html:li></html:ul>
restoreDescription3=Derive the <html:i>view identifier</html:i> from the request.
restoreDescription4=Determine if the request is a <html:i>postback</html:i>.
restoreDescription5=If the request is a <html:i>postback</html:i>, restore the view using the <html:i>view identifier</html:i>.
restoreDescription6=If the request is not a <html:i>postback</html:i>:
restoreDescription7=<html:ul><html:li>create a new view using the <html:i>view identifier</html:i>.</html:li><html:li>set the FacesContext.renderResponse indicator - this will signal that control should transfer to Render Response Phase.</html:li></html:ul>
restoreDescription8=Store the restored or created view in the FacesContext.

applyHeader=Apply Request Values Phase
applyCaption=Apply Request Detail 
applyDescription1=The purpose of the <html:i>Apply Request Values</html:i> phase of the request processing lifecycle is to give each component the opportunity to update its current state from the information included in the current request (parameters, headers, cookies, and so on).
applyDescription2=During the <html:i>Apply Request Values</html:i> phase, each component's <html:i>decode</html:i> method is called.  For <html:i>UIInput</html:i> components, data conversion occurs. 
applyDescription3=During the decoding of request values, some components perform special processing, including:
applyDescription4=<html:ul><html:li>Components that implement ActionSource (such as UICommand), which recognize that they were activated, will queue an <html:b>ActionEvent</html:b>. The event will be delivered at the end of <html:i>Apply Request Values</html:i> phase, or at the end of <html:i>Invoke Application</html:i> phase, depending upon the state of the immediate property on the activated component.</html:li></html:ul>
applyDescription5=<html:ul><html:li>Components that implement <html:b>EditableValueHolder</html:b> (such as UIInput), and whose <html:b>immediate</html:b> property is set to <html:b>true</html:b>, will cause the conversion and validation processing (including the potential to fire <html:b>ValueChangeEvent</html:b> events) that normally happens during <html:i>Process Validations</html:i> phase to occur during <html:i>Apply Request Values</html:i> phase instead.</html:li></html:ul>
applyDescription6=At the end of this phase, all <html:b>EditableValueHolder</html:b> components in the component tree will have been updated with new submitted values included in this request (or enough data to reproduce incorrect input will have been stored, if there were conversion errors). In addition, conversion and validation will have been performed on <html:b>EditableValueHolder</html:b> components whose <html:b>immediate</html:b> property is set to <html:b>true</html:b>. Conversions and validations that failed will have caused messages to be enqueued via calls to the addMessage() method of the FacesContext instance for the current request, and the valid property on the corresponding component(s) will be set to false.

validHeader=Process Validations Phase
validCaption=Process Validations Detail 
validDescription1=As part of the creation of the view for this request, zero or more <html:b>Validator</html:b> instances may have been registered for each component. In addition, component classes themselves may implement validation logic in their <html:i>validate()</html:i> methods.
validDescription2=During the <html:i>Process Validations</html:i> phase, each component's <html:i>processValidators()</html:i> method is called. Note that <html:b>EditableValueHolder</html:b> components whose <html:b>immediate</html:b> property is set to <html:b>true</html:b> will have had their conversion and validation processing performed during <html:i>Apply Request Values</html:i> phase. 
validDescription3=During the processing of validations, events may have been queued by the components and/or Validators whose <html:i>validate()</html:i> method was invoked.
validDescription4=At the end of this phase, all conversions and configured validations will have been completed. Conversions and Validations that failed will have caused messages to be enqueued via calls to the <html:i>addMessage()</html:i> method of the <html:i>FacesContext</html:i> instance for the current request, and the <html:b>valid</html:b> property on the corresponding components will have been set to <html:b>false</html:b>.

updateHeader=Update Model Values Phase
updateCaption=Update Model Values Detail 
updateDescription1=If this phase of the request processing lifecycle is reached, it is assumed that the incoming request is syntactically and semantically valid (according to the validations that were performed), that the local value of every component in the component tree has been updated, and that it is now appropriate to update the application's model data in preparation for performing any application events that have been enqueued.
updateDescription2=During the <html:i>Update Model Values</html:i> phase, each component's <html:i>processUpdates()</html:i> method is called.
updateDescription3=During the processing of model updates, events may have been queued by the components whose <html:i>updateModel()</html:i> method was invoked.
updateDescription4=At the end of this phase, all appropriate model data objects will have had their values updated to match the local value of the corresponding component, and the component local values will have been cleared.

invokeHeader=Invoke Applications Phase
invokeCaption=Invoke Applications Detail 
invokeDescription1=If this phase of the request processing lifecycle is reached, it is assumed that all model updates have been completed, and any remaining event broadcast to the application needs to be performed.  The <html:i>processApplication()</html:i> method of the <html:i>UIViewRoot</html:i> instance is called, and this method will broadcast any queued events that specify a phase identifier of <html:b>PhaseId.INVOKE_APPLICATION</html:b>.
invokeDescription2=The default <html:i>ActionListener</html:i> for the application will recieve the event(s) and invoke the application's <html:i>NavigationHandler</html:i>.  The application's <html:i>NavigationHandler</html:i> will determine the next view to be visited.
invokeDescription3=Advanced applications (or application frameworks) may replace the default <html:i>ActionListener</html:i> instance by calling the <html:i>setActionListener()</html:i> method on the <html:i>Application</html:i> instance for this application.

renderHeader=Render Response Phase
renderCaption=Render Response Detail 
renderDescription1=This phase accomplishes two things: 
renderDescription2=<html:ul><html:li>Causes the response to be rendered to the client.</html:li> <html:li>Causes the state of the response to be saved for processing on subsequent requests.</html:li></html:ul>
renderDescription3=The reason for bundling both of these responsibilities into this phase is that in JSP applications, the act of rendering the response may cause the view to be built, as the page renders. Thus, we can t save the state until the view is built, and we have to save the state before sending the response to the client to enable saving the state in the client.
renderDescription4=JSF supports a range of approaches that JSF implementations may utilize in creating the response text that corresponds to the contents of the response view, including:
renderDescription5=<html:ul><html:li>Deriving all of the response content directly from the results of the encoding methods (on either the components or the corresponding renderers) that are called.</html:li><html:li>Interleaving the results of component encoding with content that is dynamically generated by application programming logic.</html:li><html:li>Interleaving the results of component encoding with content that is copied from a static template resource.</html:li></html:ul>