Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#76 Make YYYY-mm-dd default for dateboxes when no date passed

XOOPS_2.2
closed
Jan Pedersen
5
2012-09-25
2004-12-01
Julian Egelstaff
No

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

Discussion

  • 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

     
  • Jan Pedersen
    Jan Pedersen
    2005-03-14

    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