Henner Kollmann wrote:
>
> >
> > But the code is also within NavNewButton with effect that you
> > can insert a new row only if there are already rows. I think
> > that makes no sense and would suggest to delete this condition.
>
> But what's if the body has set allowNew and you have an empty recordset?
> Then the NavNewButton will be rendered but you have already an new
> record?
> Does this make sense?
Hmmm, that is true, I would then would have an extra button not needed,
but that would not make the application unusable.
The bugtracker application has a read-only list form with a single
navNew button in footer. I think that is a very common design: show rows
in list form, allowing to see details when selecting them and allowing
to enter a new row by clicking a 'New' button. Such a ro form has never a
allowNew set to 'true'. Now the application cannot be used at all if there
is no bug within the db or the last one gets deleted.
We cannot easily check the allowNew from within
the navNewButton, because is is an attribute of the body tag that we might have
already left. Surely would easily be possible to pass it from body to dbform tag
to have it then later available, but that makes the code anything but
readable and easy ...
The example appl. can easily be fixed, simply put it within header instead footer.
But what I am a bit afraid of is that this behaviour (maybe because of another bug)
was not so in previous versions...Why was the navNewButton placed within footer?
Do we break compatibility with millions of applications out there? E.g. the
generate_lists.xsl stylesheet also puts such a button within footer.
Just made a test with an old application using an old dbforms version, the
navnewButton is still shown when I delete all rows. It was also shown when having
a empty entry form.
We surely could add something like another 'showAlwaysInFooter' attribute, then do
if (parentForm.getFooterReached() &&
ResultSetVector.isEmptyOrNull(parentForm.getResultSetVector()) &&
"false".equalsIgnoreCase(showAlwaysInFooter) )
{
return EVAL_PAGE;
}
but the default behaviour should be as it was in previous versions, so default value
would
be "true". However, I'm not so sure if we really need another attribute or if it would
be better to keep the tag simpler with same behaviour as before...
Regards
Dirk
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
DbForms Mailing List
http://www.wap-force.net/dbforms
