tomahawk t:popup component

If you have to remember something about the t:popup component: remember this: if you use it on a af:commandLink (or some command component...something that submits) and you click on that component, you will get an error when your page reloads (due to postback), if you are running on IE 6 or 7. "...Operation aborted"

The cause of this error seems to be that you are trying to run javascript before the DOM is all the way loaded.

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. :-)

web.xml minutiae: SecurityContext.isUserInRole()

So...

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:

1. 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.
2. 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.

:-)

Custom Components in JSF and af:iterator

I have something to report that I did not realize about custom UI components in JSF (lots of things probably...)

Consider the following scenario: you put a custom component in a af:iterator component. Can you answer the following questions?

1. How many instances of your custom component that you included in that af:iterator loop will be created?
2. 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.

af:iterator

I was trying to use af:forEach with a custom component I made. This custom component is a bit like the declarative components in ADF Faces Rich Client components, in that it renders different components depending on what type you send it. I was trying to pass a value binding through an attributes and then trying to evaluate the value of this in the component at encode time, but the af:forEach request scope "var" variable could not be evaluated by the property resolver. af:iterator, I am happy to say, for some reason did something different however so the "var" was more accessable to the child custom component.

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