Menu
▾
▴
#76 Make YYYY-mm-dd default for dateboxes when no date passed
Attached are two files that we have modified from XOOPS
2.0.7. 2.0.9 Beta did not modify these files, so these
changes should work fine in 2.0.9 too.
What do they do?
They allow emtpy strings (or more particularly,
non-numeric strings) to be passed to the date select
box created by the xoopsform class, and for those empty
strings to result in YYYY-mm-dd being placed in the box
instead of the current date.
Without this change, the current date is written into a
date select box if the box is initialized with a
non-numeric string, and we feel this is a mistake
because it results in situations where a user just
submits a form but forgets or neglects to enter an
accurate date, so the default value, current date, just
gets passed back from the form, but in fact no date was
actually specified by the user.
Module developers have no way of knowing if the user
actually picked the current date or just ignored the
date box.
With this change, or a similar one, a true "null" value
is reflected in the initial state of the box, and so
can be identified accurately as a "no-entry" situation
by a module's own logic when processing the submissions
from the form.
What is changed?
in class/xoopsform/formtextdateselect.php:
-The line that converts a non-numeric initial value to
the current date is commented.
-A conditional has been added to the render function to
check whether there is a valid initial value for the
box, and if so, sets the initial date in the correct
format, and if not, sets the initial value to be
YYYY-mm-dd.
-The value of $jstime is set in a slightly different
manner, though I'm not certain this makes a significant
difference to the logic of the files (the change was
the result of other "dead-end" attempts to complete
this overall change to the data select box behaviour).
-In the return line, the HTML value variable is set
according to the outcome of the new conditional above.
in include/calendarjs.php:
-A conditional has been added to the ShowCalendar
function around where it parses the value of the box in
order to highlight the correct date in the popup
calendar. The conditional checks to see if the value
in the box is either empty or "YYYY-mm-dd" and if NOT,
parses the date in the box to determine the initial
date selected in the popup calendar, or if so, parses
the current date ($jstime from the previous file).
I would love to see these changes added to 2.0.9 or
2.1. We think these additions make the behaviour of
the date select box a lot more robust, without having
an adverse affect on existing modules (but allow module
developers to handle dates from boxes better if they
want to write their code to take advantage of the
identifiable YYYY-mm-dd default value).
Thanks for reading,
--Julian
Logged In: YES
user_id=1109439
We have modified one of the two files in this patch. The
.zip file attached to this posting has been updated to
include the new file.
formtextdateselect.php which belongs in the class/xoopsform
folder, has been modified to include all of the code
contained in include/calendarjs.php.
Formerly, this file used an "include" call to get that code,
but the result of that was that the code appeared at the
very top of the resulting HTML file that got sent to the
browser, before the actual HTML code for the page had begun.
This was a bad thing because having all that code outside
the actual HTML text stream resulted in the menu section of
the page being drawn with a lot of extra padding in place,
thus screwing up the appearance of your site.
This recent change to the formtextdateselect.php file causes
that code to be gathered right within this file itself, so
it is not "included" any longer. The code is then sent to
the XOOPS template in a variable called $calendarjs. This
variable is then available for inclusion in the proper part
of the page template.
Therein is the "catch" with this patch: to make the [...]
popup buttons for date select boxes work, you need to modify
your theme.html template file so that it will insert
$calendarjs in the correct spot (and thereby have the menus
on your site drawn correctly). The modification is very
simple. Just add the following text:
<{$calendarjs}>
to your theme.html file on the line immediately after the
title (in the HEAD section of the page). It is recommended
that you put this text on a line all by itself so it doesn't
interfere with any other part of the template.
You will then have to upload your modified theme.html file
and then delete all the files in templates_c so that the
change in theme.html is picked up by your XOOPS site (if you
don't clear templates_c then a compiled version of the
theme.html file, without this change, will be used).
If you do not make the above change to your theme.html file,
then the [...] button that pops up the calendar for date
select boxes will simply be non-functional. There will be
no other adverse affects to your site.
--Julian
Logged In: YES
user_id=1109439
This file updated 3:10 pm Eastern time March 11 2005
The update corrects a problem that caused the date select
boxes to not work when rendered in pages that did not use
the XOOPS template, such as pages in the Admin side of XOOPS.
--Julian
Logged In: YES
user_id=841117
I tried your fix with a small change, where I added the
javascript string to the returned value instead of as a
template variable.
This works fine for me, however I have a problem with
multiple date input fields in the same form where they got
the same value no matter what (or there were problems
collecting them.. I don't know for sure, but it worked
correctly after applying the javascript but not after your
YYYY-MM-DD fix).
Could you double-check whether you have this as well?
A fix for rendering pages correctly will be included. Thanks
for your work so far.
Logged In: YES
user_id=1109439
Sorry for the delay in getting back to you....
It sounds like you have used the code of calendarjs.php that
comes with 2.0.x and not the version from the patch. I
recall having a problem like this when doing the first
version of this patch, and it was solved by modifying/adding
this check in calendarjs.php:
if (el.value != "" && el.value != "YYYY-mm-dd") {
calendar.parseDate(el.value);
} else {
calendar.parseDate(<?php echo "'$jstime'"; ?>);
}
That basically says that if there's a real value in the
current date box, then use it to initialize the calendar.
Otherwise, initialize with the default value sent by the
xoops form class.
I was finding that without this, all boxes were initializing
with the date of the first box, as I recall. I hate
(coding) javascript.
I believe the YYYY-mm-dd text should be a language constant
for the official version of this fix, for obvious reasons.
--Julian
Logged In: YES
user_id=1109439
Another thought about why multiple date selection boxes may
have malfunction for your Mith...if the javascript were
inserted more than once, then I would expect things to go
haywire. You would only want one copy of the javascript
inserted in the page, but if you have it being inserted with
every box that the xoopsformclass draws in, then that might
be the problem.
I expect you ahve sorted all this out in 2.2 already. I
will be looking at that sometime soon I hope.
--Julian
Logged In: YES
user_id=1109439
We are about to release version 2.0 beta of Formulize, our
form creation and reporting module. There has been one
further change to both files in this patch. We have added
one line of javascript that interacts with some checking
logic in each Formulize form in order to determine if the
user has made changes to the values in a form, and then
tries to leave the form without saving their changes. The
user gets a warning message in that case so they don't
accidentally lose their work.
This change will have no effect at all on anything except
Formulize (where if the patch is not updated, then the
no-save-warning will not happen in the event of a change to
a date box).
I'm adding the update here to keep this patch up to date
with the latest version that will be distributed with
Formulize. (ie: this is an attempt to minimize the number
of different versions of this patch that are available.)
The default code in xoops 2.0.13 has not been changed from
how it was in 2.0.7 (and earlier), so this patch should be
effective for all versions of XOOPS up to and including
2.0.13. We have not examined 2.2 to know the status there.
The change is immediately after line 98 in
formtextdateselect.php. We add a new line 99 right after
the if statement. The new line is this:
formulizechanged=1;
This change has been made to calendarjs.php too in the same
relative place.
--Julian
Contains two files that patch the xoops core, so that a true default value can be identified in date select boxes after submission