Tuesday, May 29, 2012

ADF Bug or Feature? Non-Breaking Space outside required icon style

Tested with JDeveloper: 11.1.2.1.0

In this post I am going to describe a limitation I hit while skinning the alignment and positioning of the required Icon.

The desired end result should be as following

0002@2916_2916-41266b4770fa4fa5

To get there we have an ADF weapon called skinning. So we create a skin css file and style the following selectors

0003@2916_2916-41266b47722b3c4d

Having done that we start the application and will notice that in case of required fields the result is still not really what expected:

0004@2916_2916-41266b4773240796

OK, since the required icon container (span) can be referenced by css selector we should be able to move that required icon on the left side. This can be done by the following css

0005@2916_2916-41266b47757fcf74

Refreshing the page in the browser the form layout looks close to the target result

0006@2916_2916-41266b4777b2a190

Except the blank before Lastname. Did you notice? Having those blanks in forms with more fields the overall design looks pretty poor / messed up! So where does the blank comes from?

Inspecting through Firebug (1.9.0), everything seems OK. I cannot see any pointer for the blank.

0007@2916_2916-41266b4cb3ae147b

BUT, looking on the raw HTML code you will see a non-breaking space in case the required="true" or showRequired="true" is set on the components

0010@2916_2916-41266b4cb681b4e8

This nbsp is really annoying since  it is not possible to select this one by CSS. At least I have not find a way to remove that by CSS.

So is it a bug or a feature? I would say it is a bug since it is not easy (or even not possible) to influence the position of the nbsp. It is not enclosed e.g. in the span for the required icon style and therefore not selectabl by CSS. Why isn't it generated like

0011@2916_2916-41266b4cbb34b790

Everything would be fine.

WORKAROUND

In order to get the desired alignment

0001@2916_2916-41266b4770cccccd

I wrote a ServletFilter, wrapped the HTTPServletResponse to buffer the response, process the filter chain and filter the buffered response like

public void doFilter(ServletRequest request, ServletResponse response,
FilterChain chain) throws IOException,
ServletException {

HttpResponseCharBufferWrapper wrapper =
new HttpResponseCharBufferWrapper((HttpServletResponse)response);

chain.doFilter(request, wrapper);


String filteredResult = wrapper.toString();
filteredResult = filteredResult.replaceAll("> ", ">");

response.getWriter().write(filteredResult);
}


(Don't forget to register the filter in web.xml)



The nice thing about that workaround is, that you can implement what ever content filter rules you want/need. On the con side there is for sure more memory consumption.



TO SUMMARIZE



0012@2916_2916-41266b4cc1b4e81b



DISCLOSURE



I know that the provided workaround is really dirty and I personally do not like it! I will file an ER/SR at My Oracle Support and the ADF EMG Defect tracker (http://java.net/projects/adfemg)



If anyone knows of a cleaner and better workaround, let me know. Maybe some niffty CSS Hack (I have not found yet) could do the trick. (:after? content?) Any comments are welcome.



DOWNLOAD



(Jdev 11.1.2.1 workspace)



https://www.box.com/s/c93ca49d34e42746491b

Thursday, May 17, 2012

Java Heap Monitor in JDeveloper

Tested with JDeveloper Version 11.1.1.5, 11.1.2.1

Short post, but hopefully a useful productivity tip. Recently I thought if there isn't such a feature as I was used from some other IDEs
0000@2933_2933-41266b5f570d462a

Monitoring of the java heap size + the ability to force garbage collection.

Finally I found it as you can see from the screen shot above which shows my right bottom of JDeveloper Statusbar.

So how to activate this one? Well it is quite easy. Locate $MW_HOME/jdeveloper/jdev/bin/jdev.conf and add the following line at the bottom

AddVMOption -DMainWindow.MemoryMonitorOn=true

Restart JDeveloper and you should be able to see the java heap size monitor. Clicking on the recycle bin will force garbage collection.
0001@2933_2933-41266b5f592f684c

After garbage collection (in my just started jdeveloper) the used memory dropped from 200M to 105M
0002@2933_2933-41266b5f59d7cc6c

Conclusion
That might save you from restarting Jdeveloper to often a day;)

Further Reading
http://docs.oracle.com/cd/E25178_01/fusionapps.1111/e15524/gs_install_e.htm#CDEFEDGC