The Incident Archive

I had a showdetailheader inside a forEach which would just not disclose/ hide. No matter what I tried the header would just not work. So I changed the for each value from a binding to a get from the backing bean and everything worked as it should. Strange...

11.1.1.5 So here is my handy list to myself of things to check if you are getting weird problems with things that should work (buttons not work, or drop downs misbehaving): Mark you table as contentDelivery="immediate" Remove partialSubmit="true" from some buttons Remove immediate="true" from buttons Use af:forEach instead of af:iterator.

So I was playing around with generics (dont love them because of type erasure - class level is ok method level gets scary) the other day and here are some examples and lessons learned: 1) Method level generics with return types are harder than they look. 2) Wildcards and when to use them confuse me. 3) My code is ugly and I must be missing something but what - who knows. What I wanted was a Singleton class with generic get and put methods (what you put in is what you get out) without the cast. Something that works a little like Collections.emptyList(); The map I was storing my generic stuff in  ignore the naming for now: What I wanted to do is something like this: CacheItem<AnItem>  someCacheItem  = new DateCacheItemImpl<AnItem>(); Cache.getInstance().register(NameCacheItem.class); Cache.getInstance().put(someCacheItem); CacheItem<AnotherItem>  anotherCacheItem  = Cache.getInstance().get(); p...

Ok so I had a bunch of filters all rendered from a backing bean using the forEach tag to render the select items. On updating the table the filters would always have the size of the initially selected item - not good. So if you fist selection had one item in the filter the filter would always be one item big. SOLUTION: Changed from a forEach to a f:SelectItems creating the Select items in my backing bean - everything worked. Nice and simple.     public List<SelectItem> listUniqueSelectItemList(List<String> items) {         List<SelectItem> itemList = new ArrayList<SelectItem>();         if (items != null) {             for (String item : items) {                 itemList.add(createSelectItem(item));             }         }         return itemL...

Ok so this is one way to break out of the region you are in and replace a parent or root region. So in your child task flow instead of calling a task flow directly using a control flow case just point your control flow case to a Parent Action (get it from the component panel). There you can specify an outcome in a parent task flow. Job done.

I have a customizable table where you can save sort orders to the database (custom not mds driven - don't ask why - you don't want to know). So everything works for me locally but upon deployment to Web Center once you have moved one column everything has that column order in the table no matter what until you close the browser and re login. Not I have no MDS configured on my local box. Turns out someone turned mds config on in my project properties thus rendering my custom ordering view useless because MDS would override my changes - so I turned MDS off in this project because I dont need it. I am not sure what you would do if you needed it on would need to customize it a bit I guess - not easy. PAIN in the arse to figure this one out. O yhea and dont think just clicking the MDS to off will remove your problem check the adf-config.xml to check if any elements have been hard set to persist.

I was missing the <message-bundle>com.test.view.props.test</message-bundle> entry in my faces-config.xml for some code that looked up a default message bundle in my faces application. And I got a  NullPointerException  java.util.ResourceBundle$CacheKey.calculateHashCode not really explanatory but hey well. .