Ruby on Rails' emergence in 2005 greatly influenced web app development, through innovative features such as seamless database table creations, migrations, and scaffolding of views to enable rapid application development.
Icefaces 1.8 project software#
In addition to MVC, Rails emphasizes the use of other well-known software engineering patterns and paradigms, including convention over configuration (CoC), don't repeat yourself (DRY), and the active record pattern. It encourages and facilitates the use of web standards such as JSON or XML for data transfer and HTML, CSS and JavaScript for user interfacing. Rails is a model–view–controller (MVC) framework, providing default structures for a database, a web service, and web pages. A message is shown, but there is now decoration.Īs soon as I know, which framework (myself, Seam or ICEfaces) has to fix the problem, I will open up an issue (or bang my head against the wall).Ruby on Rails (simplify as Rails) is a server-side web application framework written in Ruby under the MIT License. And thus I have a sample application that shows the same effect that I described. I also transferred my pages.xml to this sample application. The action called as soon as one clicks the button only adds a message to the decorated text field. However, I just created one using seam-gen, adding a decorated text field and a button. I don't know why I didn't create a sample application earlier. (http-localhost%2F127.0.0.1-8080-4) WARNING: FacesMessage(s) have been enqueued, but may not have been displayed. Writing this I remember such warnings in some parts of my application: Therefore it tries to transfer the messages to an empty component tree with the result that the input fields are not decorated. Unfortunately, the decorator is executed in this second pass of the JSF lifecylce. And now the ViewRoot does not contain the component tree. But in teh second pass of the JSF lifecycle the tViewRoot method is called (again in the Restore View phase). All further calls of the BridgeFacesContext.getViewRoot method return a ViewRoot with the component tree. And the given ViewRoot contains the component tree. In the first pass the tViewRoot method is called in the Restore View phase. Now I know that the JSF lifecycle is executed (at least) two times. And this should work since the decorator decorates input fields in this case.Īnd I know that the BridgeFacesContext should contain the ViewRoot.
Icefaces 1.8 project code#
That's why I wrote all the validations myself in the application code adding explanatory messages. Other parts of the application validate an entity regarding specific combinations of inputs. The problem I have with Hibernate validator is that I don't know if it can handle more complex validations. What do you think about this? Is it a mistake I made or is it a bug? Who is responsible for this bug? Should I open a JIRA issue?Īctually I could remove those s:validates since I don't use the Hibernate validator. Besides the decoration problem the application works fine. I don't know why the view root is in such a state that it doesn't know about its children. Since Seam can't find a matching id in the view root for the given component id, the messages are attached to the component null, which means that the decoration can't work. All the other object attributes like children, facets, etc. The view root is an instance of SettableLocaleViewRoot and only knows about the viewId, the renderKitId and some attributes in the attributes and pdMap members. The problem now is that the view root that BridgeFacesContext returns to the facesMessages component doesn't have a children or facet. This method recursively iterates over the facets and children of the view root comparing ids. In order to do this, Seam converts the id of the component which should be decorated to the matching id in the JSF view root by calling the private facesMessages.getClientId() method. Remember that facesMessages is a JSF version of the StatusMessages class, which abstracts messages from a specific underlying framework, in this case JSF. In the next step, after the application phase, Seam calls facesMessages.beforeRenderResponse() to transfer the internal messages to JSF. The key of this map is represented by the component's id and the value is a single message or rather a list of messages. The call on facesMessages.addToControlFromResourceBundle successfully adds a new key-value-pair in facesMessages's message map. I now know why my controls aren't decorated, but I don't know whether I have made a mistake or it's a Seam/ICEfaces bug. I spent the last hour on debugging what is going on when my application adds a messages to a component via the facesMessages component. The invalid property is automatically set by the decorate tag, at least Seam doc states it would do so.
The notification mail was identified as spam and I was on holiday.
0 kommentar(er)
