Skip to main content

Faith based development

We cam up with yet another development term while converting our existing adf page to work off web services.

So if you use any of the following statements you know you are engaged in "faith" based development,
  • Have faith in the framework it will work.
  • It all happens automagically.
  • Trust the tool.
  • Just click a button and it works.
  • They will fix it in the next release.
  • I have no control over how that works.
  • The MDS will take care of that.
  • I have seen a blog post about that.
 
Very uncomfortable but apt.

Comments

Popular posts from this blog

ADF sort of generic screen for tables with the same structure

We have a couple (about a hundred) of tables with the same structure (Code, Description, Create Date, Update Date). So I wanted to do something simple so that I did not have to create all these screens 1) EO   I created the EO based on one of the tables I had that had the above columns. I then Added a transient attribute called table name to my EO based on a groovy expression. (the expression needs to change as I am reading web tier stuff from the model layer but I will fix this later) I then generated a java class for my EO. And added the following overriden method to my newly created java class. protected StringBuffer buildDMLStatement(int i, AttributeDefImpl[] attributeDefImpl,   AttributeDefImpl[] attributeDefImpl2, AttributeDefImpl[] attributeDefImpl3, boolean b) {   StringBuffer statement = super.buildDMLStatement(   i, attributeDefImpl, attributeDefImpl2, attributeDefImpl3, b); return new StringBuffer(StringUtils.replace(statement.to...

Util code

public static MethodExpression getMethodExpression( String expr, Class returnType, Class[] argTypes){ FacesContext fc = FacesContext.getCurrentInstance(); ELContext elctx = fc.getELContext(); ExpressionFactory elFactory = fc.getApplication().getExpressionFactory(); return elFactory.createMethodExpression( elctx, expr, returnType, argTypes); } public static javax.faces.el.MethodBinding getMethodBinding( String expr, Class[] argTypes){ FacesContext fc = FacesContext.getCurrentInstance(); ELContext elctx = fc.getELContext(); return fc.getApplication().createMethodBinding(expr, argTypes); } SetPropertyListener listener = new SetPropertyListener( ActionEvent.class.getName()); listener.setFrom(link.getRoute()); listener.setValueExpression("to", JSFUtils.getValueExpression("#{pageFlowScope.route}", String.class)); action.addActionListener(listener); AdfFacesContext.getCurrentInstance().getPageFlowScope() .put("route", lin...

MANIFEST.MF merge JDeveloper for an executable jar

Goto your project > properties. Then click on deployment in the menu. Edit or add a jar deployment profile. Fill in the details under jar options (select Include manifest and give it a main class name) Also remember that the merge functionality only works with a BLANK line at the end of the merge file. REALLY this caught me. My merge file contents: Class-Path: commons-codec-1.3.jar [...empty line here CRLF...]