This content has been marked as final. Show 4 replies
actually it seems that it is easier to use a dynamic list than a model driven list. However, see if the following code can be changed by you to meet your requirements
Reason being we dont have associations and view links in our project and we have to make do without them - (well unless there is NO OTHER option). Even our database doesnthave pk-fk fields.
BindingContext bctx = BindingContext.getCurrent(); BindingContainer bindings = bctx.getCurrentBindingsEntry(); JUCtrlListBinding lov = (JUCtrlListBinding)bindings.get("DepartmentId"); ViewCriteriaManager vcm = lov.getListIterBinding().getViewObject().getViewCriteriaManager(); //*************** this is where you customize this solution as you obviously only need to *************** set a bind variable and execute the query *********************/ //SAMPLE uses dynamic view criteria make sure the view criteria is cleared vcm.removeViewCriteria(vcm.DFLT_VIEW_CRITERIA_NAME); //create a new view criteria ViewCriteria vc = new ViewCriteria(lov.getListIterBinding().getViewObject()); //use the default view criteria name //"__DefaultViewCriteria__" vc.setName(vcm.DFLT_VIEW_CRITERIA_NAME); //create a view criteria row for all queryable attributes ViewCriteriaRow vcr = new ViewCriteriaRow(vc); //for this sample I set the query filter to DepartmentId 60. //You may determine it at runtime by reading it from a managed bean //or binding layer vcr.setAttribute("DepartmentId", 60); //also note that the view criteria row consists of all attributes //that belong to the LOV list view object, which means that you can //filter on multiple attributes vc.addRow(vcr); lov.getListIterBinding().getViewObject().applyViewCriteria(vc);
Adding view links or associations add no harm to an ADF BC model project and instead simplify stuff greatly. I guess you have a reason for not using PK/FK constraints in the database - its no good design though.
Thanks Frank! I havent tried yur suggestion yet, but thought I'd clarify something here. I did not mention this.
the 2 lovs are 2 separate LOV viewobjects. So Job is a JobCodeLOV with instance JobCodeLOV1, and CustomStartDate is a PayStartLOV with instance PayStartLOV1. Both these are member instances in application module which also has the COREVo viewobject which is the jsff page that populates all db columns as a form, of which the above 2 lovs are part of and mapped by transient attributes.
Let me know if the code above is suits this caveat.
Regarding, the db design; this is a migration project from the forms world , so yea I agree.