HTMLDB_ITEM.date_popup on single row report does not work

Question

Dear HTML DB Team,
On a report wit a single( one ) row the "HTMLDB_ITEM.date_popup" does not fill the selected date to the cell. (Same for wwv_flow_item.date_popup)
On the same report with 2 or more rows HTMLDB_ITEM.date_popup works fine.
Any suggestions?
Erik
testcase:
create region:
select htmldb_item.hidden(1,empno) empno,
ename,
htmldb_item.select_list_from_query(3,job,'select distinct job, job from emp') job,
htmldb_item.popupkey_from_query(4,mgr,'select ename, empno from emp',10) mgr,
wwv_flow_item.date_popup(6,null,hiredate) hiredate,
htmldb_item.text(7,sal,10) sal,
htmldb_item.text(8,comm,10) comm,
htmldb_item.select_list_from_query(9,deptno,'select dname, deptno from dept') deptno
from emp
delete 13 rows from emp ( 1 row left ):
delete from emp
where ename <> 'KING';
=> date_pop does not work

Answer 1

Using the htmldb_item API vs. built-in multi-row update functionality:
I can't speak to the question about the date for the next HTML DB release. But I'd like to add a few comments to this discussion regarding the use of the htmldb_item API package. It is generally advisable to use the built-in multi-row update functionality instead of htmldb_item function calls when implementing tabular forms. While I do acknowledge that some display types such as date popups are not yet available, I would nevertheless recommend working with what's available on the report column attributes page (i.e. using a text field for the date columns) as opposed to using htmldb_item functions whenever possible. Please keep in mind though that they are mutually exclusive, so they can't be combined on the same report.
The reasons for my recommendation are simple: first of all, if you use htmldb_item calls as part of your SQL statement, the HTML form elements are rendered for all rows in your result set. The built-in types on the other hand only render HTML form elements for those rows shown on your current page, thus you get better performance. Secondly, htmldb_item calls make your SQL statement quite complicated, not only has the engine to jump back and forth between executing your SQL and calling the PL/SQL functions, you also need to take extra care implementing your PL/SQL processes according to the item IDs you assigned in your htmldb_item function calls. When working with e.g. popup LOVs, this gets even more complicated because that type actually results into two html form elements for each column (one storing the hidden ID, one storing the display value). And lastly, by using the multi-row update functionality, you would get lost update detection automatically built. That means, that you can't accidentally overwrite another person's changes in the event that you should both be working on the same data. Implementing this kind of functionality with your htmldb_item based tabular forms would take a lot more effort than simply go with what's already provided.
So please carefully weigh the benefits of additional display types that you'll get by using the htmldb_item API against all the functionality you'll get by using the built-in tabular form and multi-row update features.
Regards,
Marc