incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Lessard" <simon.lessar...@gmail.com>
Subject Some ideas
Date Fri, 15 Dec 2006 14:24:04 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message