Hello everyones, Soon my semester will end and I'll be back up and running for the project. During the semester I was working on an ADF Faces project and we found some issues that still hold true in Trinidad so here are some ideas I was thinking about for Trinidad:
1. Currently Trinidad gives top priority to its internal resource bundle. That is, when a request for a Trinidad text resource is made, it first check if the bundle exists in the JAR (which will be true like 99.9% of the times) and then check for defined JSF message bundle. So, the only way around to override the message is to know the internal message bundle path (which is private if I remember well) and copy that package structure in your own project. That hack requires that you override every single Trinidad message though. So my first suggestion would be to change the logic to: - Check if a JSF message bundle was specified for the application. If so, check if the requested key exists within it. If it exists, return the resource. - Otherwise go for the internal resource bundle. 2. My second idea might be more for the sandbox that anything else at first. In our project we wanted to apply a security strategy on component level. There's only one way to achieve this atm which is to specify the rendered attribute for every component. However, I think it could be interesting to have a kind of attribute evaluation hook specified in trinidad-config.xml. In our case this would be especially easy to implement because of the FacesBean architecture. The hook could be applied to all components for attributes specified in the configuration. The default hook could simply do some default evaluation that would allow child classes to get the normally returned value. Most of the time I guess that method would only be used for the rendered attribute, but I don't see any reason to not offer it for any attribute. The memory footprint should not be too high, especially if we have a cached map of singleton hook instances used to attach hooks on PropertyKey creation, and the processing time overhaul would only represent an additional method call when no hook was specified and an undefined cost when one is. Hook method signature could look like - public Object evaluateAttribute(FacesContext context, UIComponent component, FacesBean bean, PropertyKey attribute); I will have some more idea to come with pretty soon. Regards, ~ Simon
