Wednesday, July 22, 2009
It also seems to mess up the wysiwyg editor in JDeveloper 10g, but I can kinda get used to that...for what this popup component brings to the tables. It allows you to hover over an element and get a popup which will stay open until you leave it. Or you can make the popup go away when when you leave the driving element.
Anyway...everything is peachy in IE 8 and in the latest version of Firefox. :-)
Tuesday, July 21, 2009
If you are using Oracle SSO, iAS 10.1.4 infra, iAS 10.1.3.4 mid-tier, and running ADF on it, and Oracle Portal on another mid-tier...here is some information that may come in handy for you:
- In ADF if you use isUserInRole() method in the SecurityContext, you will need to bounce your 10.1.3 instance every time you make a change (or a set of changes) to the OID users and groups/roles. I imagine there is a way to get my 10.1.3 to refresh from the oid explicitly, but I have not figured it out yet.
- isUserInRole also expects that particular roles that you are testing to be listed in web.xml. So just because the user has the role in OID does not mean you can test for it successfully...you must first add it to web.xml.
Tuesday, July 14, 2009
Consider the following scenario: you put a custom component in a af:iterator component. Can you answer the following questions?
- How many instances of your custom component that you included in that af:iterator loop will be created?
- If your component's function is to print a different kind of input field or widget depending on the parametric input given to the component tag, what might you need to do with any attributes in your component?
The answer to 1 is: one. One for each af:iterator. So if your iterator loop brings back 1000 records from the database, it loops 1000 times and "prints" your component 1000 times, but there is ever only one instance of the component.
For question 2...let us say that your component offers the printing of 4 different kinds of components depending on the value of its "type" tag attribute. So in that page you will have 1000 fields printed one for each af:iterator loop. If your component only rendered UIOutput components then it would suffice to have one property in your component class for each type of component.
But we are doing input components, so decode will be involved. That complicates things. JSF will generate a client id for each field that you generate with your component. If it is in the af:iterator loop it will look something like: formname:iteratorname:n:yourcomponentid -- where n is the zero-based loop index of your af:iterator.
On a JSF postback/decode, each field first runs the decode method. Then each field runs the encode methods for the component. In between the decode runs and the encode runs you need to store the submitted value of each component. I used a HashMap with client id as the key, and the component as the value. If you store everything away in decode you will have whatever you need to do the encode when it occurs for the postback.
Hope this helps someone.
Wednesday, July 8, 2009
There was another project also where af:forEach really was acting up, where I wish I had known about af:iterator.
The inspiration to try this component came from Duncan Mills blog entry http://groundside.com/blog/DuncanMills.php?blog=6&c=1&page=1&more=1&title=jsf_and_the_foreach_loop&tb=1&pb=1&disp=single