Documents
Resources
Learning Center
Upload
Plans & pricing Sign in
Sign Out
Get this document free

hack 61

VIEWS: 113 PAGES: 12

									

Custom format to _enter_ dates
yched - August 18, 2006 - 22:52 Project: Date Version: 4.7.x-1.x-dev Component: User interface Category: feature Priority: normal Assigned: Unassigned Status: closed Description Maybe the module already allows this and it's just me missing it. Feel free to flame if that is the case :-) I need the dates to be entered as dd/mm/yyyy (Xmas = 24/12/2006), as opposed to mm/dd/yyyy. It is the format that's commonly used in France (an probably other countries ?) I can see where to set the output format, but cannot find anything about the input format and quickly browsing through the code didn't raise any evidence of this being possible. This really is a showstopper to me (hence my setting this to 'critical') : I can't ask my users to twist their minds and enter dates in the mm/dd format -it's just like being forced to use your left hand when you're right-handed. I feel all the more sorry about it than, aside from that, this module is quite a precious work :-)

Updates
#1 submitted by KarenS on August 18, 2006 - 23:40 Well, here's what's currently available: 1) the drop-down select list which is pretty highly configurable (year, month, and day can either be textfields or select lists, the hours and minutes can be incremented in various ways, and you can choose whether or not to add am/pm and/or a timezone selector. The only other possible gee whiz thing to add to that would be the ability to re-arrange the fields, but I'm not really up for taking that one on at the moment :-) 2) the js pop-up calendar widget which brings up a calendar display that you can use to select a date which gives users a familiar calendar interface. 3) the plain textfield. I improved on the original module somewhat, since the original required that the input be in iso date format and I switched it around so it would accept

anything that strtotime allows. That covers a lot of territory, but not, I realize, various nonamerican shortcut versions of things. I *think* (not absolutely sure) that you can put date parts in any order so long as you spell them out, just not in shortcut formats -- 8/1/06 is ambiguous otherwise, so the strtotime function assumes it is in the month/day/year format the US uses. I can see that it would be nice to have some sort of ability to use something like the date format string to indicate that the field should look for input as dd/mm/yyyy then use a regex or something to pull the parts out when the form is submitted. This would probably have to be created as another widget patterned on the strtotime widget. I don't have time to try to create something like that right now (and I never can get regexes working right anyway), but if you are interested and want to try to create a way to do it, I'd certainly be willing to add that feature in to the module. I don't think there is anything else out there that will do this, so I'm not sure what you would use as an alternative, but if you need it and the first two options are not viable for some reason, you might as well take this as an opportunity to create something that works the way you want it to. If you have other ideas for how to approach it, at least ideas that don't involve me spending a whole bunch of time trying to figure out how to get it to work, I'm all ears :-) #2 submitted by yched on August 22, 2006 - 00:07 Thanks for this extensive answer :-) The js-calendar widget does soften the pain, but it remains puzzling to see dates "twisted" when you open a node edit form. Googling a little more on the subject, It seems that 'mm/dd' vs 'dd/mm' is more or less 'US' vs 'about the rest of the world', so I do think this is a critical feature. As you pointed out, the original cck-bundled date.module had the same limitations on this issue (I currently use a highly hacked version as a workaround). But your date.module being what it is (the killer-highly-customizable-date-management-solution ?), it would be a real pity to have it US-centered. This being said, I can of course perfectly understand if you don't have too much spare time for that - I'll try to come up with a patch in the next few ... days ... weeks ... ? I'll probably need your help / advice / validation on some points, though (user settings UI, for instance...) #3 submitted by yched on August 25, 2006 - 21:39 Status: active » patch (code needs review) Attachment: input-format.patch (5.29 KB) OK, It's probably wiser to tackle this step by step. So let's start slowly : This first patch deals with the select list widget (easiest one...) It simply relies on the site-wide short date format to set the order of the day/month/year fields (I can't remember where I stole the idea) What do you think ? #4 submitted by yched on August 25, 2006 - 21:40

Version: HEAD » 4.7.x-1.x-dev patch is against 4.7, BTW #5 submitted by KarenS on August 25, 2006 - 23:00 Interesting approach! The rest of this is just thinking out loud. Jump in with your ideas... You could use this to grab the separator, too (slash, dot, dash, whatever). Don't need the separator here, but might be handy in other places, i.e. use it to explode text entered in the textfield. My original idea on the selector was to just change the weight on each element to rearrange the order. Will we need the ability to parse the format in more than one place (probably, esp if we want to do something with the textfield format). If so, would it make sense to make a function to rip apart the short format into its parts, then call it whenever it is needed instead of doing this kind of iteration in several places? It might need to be evaluated over and over for the same user. Should we do it once and store the results somewhere as the user's preferred input format? If so, where? Would any of these be any more efficient than doing it as you've done here? I'm not sure. #6 submitted by yched on August 26, 2006 - 12:34 You could use this to grab the separator, too (slash, dot, dash, whatever). Don't need the separator here, but might be handy in other places, i.e. use it to explode text entered in the textfield. Yes, I thought about that, but ATM I can't think of a good way to do that. Here are a few short date formats defined in Drupal : Y-m-d H:i, m/d/Y - H:i, Y M j - H:i, ... How can we recognize the date separator form the whitespace or the '-' separating date part and time part ? Will we need the ability to parse the format in more than one place (probably, esp if we want to do something with the textfield format). If so, would it make sense to make a function to rip apart the short format into its parts, then call it whenever it is needed instead of doing this kind of iteration in several places? I guess as we move along, we'll have to see about that and try to 'factorize' when possible. I'm not sure we can abstract that, though. Even if the 'string walking / switch structure' is the same, we'll do different things in the switch cases. It might need to be evaluated over and over for the same user. Should we do it once and store the results somewhere as the user's preferred input format? If so, where? As a matter of fact, I don't think drupal currently lets user set their preferred date format. The [short|medium|long]_date_format variables are all-users site-wide values, set by the admin. #7 submitted by dodazzi on August 26, 2006 - 17:04

I tested the patch and works perfectly. I think is a first important step for us not US users. Thanks. Dodo #8 submitted by KarenS on August 28, 2006 - 11:59 @yched, you're right, users can't set formats. I was thinking when they set their timezones they also were selecting formats, but I see I remembered wrong. For the separator, I was just thinking about using the first encountered non-numeric item as a separator (which might be a space), I wasn't going to use the dash separating the time. Anyway, that has given me some ideas about a way to make the jscalendar widget more useful by changing the format to something that matches the short date format. I'll play with that when I have time. The rest was just thinking out loud about trying to keep things as efficient as possible. I'm happy with this patch and I'll try to get it committed later today. Thanks yched! #9 submitted by KarenS on August 28, 2006 - 12:05 getting rid of the italics :-) #10 submitted by yched on August 28, 2006 - 14:17 Er, seems like I definitely broke something with this thread display in one of my previous posts... Karen, thanks for your appreciation. I see this current patch more like an incomplete proof-of-concept hack ATM, so I'm not sure it deserves to be committed as is. I have some more things to come : - dealing with input formats in the other widget types (textfield and jscalendar) - flexible input format settings on the field's settings page (plus maybe harmonizing those with the current "display" settings) I'm working on this, it's not quite ready to submit here yet. Just to let you know. Committing the current patch or not is your call :-) #11 submitted by KarenS on August 28, 2006 - 14:36 I didn't realize you had anything else done. If you've got some things in process, I'll just wait to see what you have. FYI, I'm in the process of adding a function to convert date() formats to strftime() formats. I strongly considered using striftime() instead of date() in this module in the first place and still think it might be needed in various places. I held back because striftime is so broken on windows and because it didn't match up with Drupal core date formatting. Anyway, my first step is to add a function to do a conversion, then I'll think about where it might be useful to use (one place may be in the jscalendar widget which uses a format that is very similar to striftime). Thanks for your help!

#12 submitted by yched on August 28, 2006 - 15:47 As a matter of fact, in the next version of the patch I'm working on, I did add a function to convert date() formats to jscalendar formats... I was not aware of the strftime/jscalendar similarity, though. Anyway, I'm going forward with my patch, and I'll adapt to the changes you may get in in the meantime :-) #13 submitted by KarenS on August 28, 2006 - 17:23 The new function date_date2strftime($format) has been committed. It will convert a date() format string to a strftime() format string. #14 submitted by dodazzi on August 28, 2006 - 17:35 Hope I closed the ems #15 submitted by KarenS on August 28, 2006 - 17:58 Whew! Thanks dodazzi. I was closing italics, but that obviously wasn't helping :-) #16 submitted by yched on August 28, 2006 - 19:14 Thanks indeed dodazzi :-) BTW, Karen, is there a way you could remove all the trailing white spaces in date.module files (some setting in your editor, maybe ?). There's really a lot of them, and they do get in the way when trying to do a patch / file comparison... #17 submitted by yched on August 29, 2006 - 21:48 Attachment: input-format_0.patch (30.17 KB) I'll be away from code (not offline, though) for about the next two weeks, so I post what I have so far. The job is only half done : in short, I have dealt with node forms display, but not their validation / submission (except maybe for select widget ?). Let me just repeat that : this patch is currently not functionnal, node forms won't validate Please also note that the jscalendar part requires this patch for jstools/jcalendar. What this patch does (or should do...) : - input format selection on field setting form - generation of the actual formats used by the select / textfield / jscalendar widgets, based on the selected input format, and the field granularity - (per-widget) caching of these formats - display the values in the node creation / edition forms according to the expected input format What still has to be done : - parse entered values on node form submission - possibly timezone handling stuff ? (I did not really delve into this) - harmonize input and output settings on field settings form - ... maybe some cleanup / refactoring ?

I wish I could have taken things further before leaving. I of course plan to go on with this when I come back, but anyone please feel free to relay the effort before that :-) (FWIW, this might be of some help : http://fr2.php.net/manual/fr/function.strtotime.php#65368 and / or http://fr2.php.net/manual/fr/function.strtotime.php#62180 ) #18 submitted by KarenS on September 5, 2006 - 10:37 Yched, Thanks for all this work! I am going to take what you've got and work with it more (and mesh in some recent changes I've made to date views handlers and arguments). I think at least some of this could be committed, but I'll look through it more carefully. And I'd be delighted to get further input when you have time again. As to the line ending problem you mentioned earlier, I'm trying a new way to commit my changes, so hopefully it will work better. I was using a program to strip windows line endings out before committing changes, but in reading further I think it was actually conflicting with the program I was using to handle the cvs commit and checkout, so maybe that was the issue. #19 submitted by KarenS on September 15, 2006 - 20:24 I've been working with this patch and it works great for populating the input selectors the right way. However, you changed the names of the form elements in the selector which completely breaks all the validation and storage of the values. You are creating something that returns this:
Array ( [date] => Array ( [mday] => 15 [mon] => 9 [year] => 2006 ) [time] => Array ( [hours] => 11 [minutes] => 44 [seconds] => 49 ) [ampm] => am [timezone] => US/Eastern )

while the code used to return something like this:
Array ( [mday] => 15 [mon] => 9 [year] => 2006 [hours] => 11 [minutes] => 44

[seconds] => 49 [ampm] => am [timezone] => US/Eastern )

I either have to go through the code and find every place that assumes the latter array structure and change it, or change your $form code back to create the array the validation is expecting. I tried to see if there is some reason why you did it that way and I can't tell that it makes any difference. If that is the case, I'm included to change the $form field names back to what they were so the rest of the code still works. But, if there is some reason you need to change that array that I'm not seeing, I need to go through the code and find all the places that I work with the array and change the logic. Is that altered structure important for some reason I'm not seeing?? #20 submitted by KarenS on September 15, 2006 - 22:32 I'm getting close now. I figured out the answer to my previous question (the forms api creates better looking html with yched's array than with the plain array). I can get almost everything working now with one exception, and here's where I need some input. For the jscalendar widget, the input format originally was essentially an ISO date (YYYYMM-DD HH:MM:SS). The module could take the returned value and make a couple minor changes to turn it into a proper ISO date (and from an ISO date into a UNIX date, if necessary), then validate and save it. However, if you change the input format of the jscalendar field, it is no longer returning an ISO date, it is returning a formatted date that has lots of different possible formats. I need to find a way to take that formatted date and turn it into an ISO date. We can't use strtotime for this because jscalendar handles dates back to 1900 and strtotime only works back to 1970, and also because strtotime does not recognize shorthand dates in non-American formats. The function that does this work is called date_jscalendar2iso(). Any ideas on how that function can turn the formatted date back into an ISO date?? #21 submitted by KarenS on September 15, 2006 - 23:18 Or turn the formatted date into a unix date, but without using strtotime(). #22 submitted by yched on September 16, 2006 - 01:02 Thanks for riding along :-)


About selector forms : I can't really remember why I altered the original selector form structure... I think it was in order to be able to play with weights in the "date" area separately from the "time" area.

I must have thought it was okay that it should break form validation / processing, since I intended to deal with these steps myself later on (I still do...), and did not plan being interrupted before getting to it, and posting a "half-done" work... Sorry about that.  About validation / processing : Well, this had to be the tricky part. I kept it for the last part of my effort, being quite

confident that it should be doable, but not knowing precisely how :-) (er, right, I probably should have "proof-of-concepted" this to begin with...) About the jscal widget :
date_get_formats($field) gives you an array of the computed formats for the field,

(PHP date() format and the corresponding jscal format). I guess it should be possible to build an "iso date" string from this. Actually, I thought the validation / processing functions for jscal widget and plain textfield widget could be the same (both now have to deal with similar input). Reading your post, though, I think I overlooked the 'pre-1970' issue (not much of my concern in the beginning...) You wrote I can get almost everything working now with one exception #23 submitted by yched on September 16, 2006 - 01:15 Crap, looks like my last paragraph got truncated. It was : You wrote I can get almost everything working now with one exception (which would be the jscal widget ?). Does that mean you got the textfield running ? #24 submitted by KarenS on September 16, 2006 - 12:26 The text input works, sort of. It creates a date format that matches the site preference. Since it is advertised as a field that uses strtotime, it already has the 1970 limitation and the strtotime conversion works. But it still has the strtotime limitations, i.e. it will misunderstand DD/MM/YYYY and think it is MM/DD/YYYY. What I ended up doing is committing the formats functions and the changes to the date selector because those all work. I kept your other changes and commented them out. That will retain most of the work you are doing so you don't have to try to keep a patch up with my changes (and I have some bugfixes to get committed so you would have to start chasing after me). Then, if you want to and when you have time, you can try to keep working on this to get the text and jscalendar fields working. One change I made is to split your formats function between date.module and date.inc. The way I have things set up, everything that is specific to CCK happens in date.module while date.inc is an API that can be used outside of CCK that doesn't know anything about CCK fields. So I store field-specific format info in date.module, but put the function that analyzes the format string into date.inc because that needs to be available to other date.inc functions. As you said, there is still work to be done to clean up various other things. As you notice things that need work, why don't you start an issue for them that someone can work on (me or you or anyone else). And again, thanks for all your efforts!! #25 submitted by yched on September 21, 2006 - 02:20 Attachment: date_1.patch (23.07 KB) OK, think this is about ready :-) I had to implement 2 functions to convert dates between "custom" format and iso. This

was, well, not _that_ easy (some naughty regexp lifting...), but I think this works. I'm only having troubles with custom input formats that would contain a '\' (backslash) character, but I guess those are not recommended anyway. I left in this patch a "test page" for those two functions (at ?q=date/test), this should probably go if this ghets commited. For the plain "strtotime" widget, I implemented the following behaviour : - if the entered date is ISO, we keep that - (new) if previous step failed, try to parse the input using the "input format" specified for the field - if previous steps failed, go through strtotime, to allow for "power" strtotime features like "next monday 3pm" Karen please tell me what you think - and anyone interested : please test :-) #26 submitted by KarenS on September 21, 2006 - 10:37 Yched, thanks!! I would really like to get this working, in particular to have 'friendlier' input formats for the jscalendar widget than the ISO date format that everyone dislikes. I'm going to spend some time going through this today. #27 submitted by KarenS on September 21, 2006 - 10:58 @yched, I can't get the patch to apply. Can you try again? #28 submitted by yched on September 21, 2006 - 11:51 Attachment: date_2.patch (23.16 KB) I don't understand why you couldn't apply this... it is against date 4.7. Here it is rerolled, just in case. PS : the numerous trailing spaces dont't make it esay to create patches :-) They are not recommended in drupal coding guidelines. Do you think there's a setting in your editor that could automatically remove them on saving ? #29 submitted by yched on September 21, 2006 - 11:53 Attachment: date_2.zip (21.84 KB) And here's a zip files containing the full date.module and date.inc files, in case the previous patch does not apply #30 submitted by KarenS on September 21, 2006 - 13:49 I'm using Visual SlickEdit to do my edits and I don't see anything about trailing spaces anywhere, so I'm not sure what to do about that... #31 submitted by yched on September 21, 2006 - 14:10 I didn't know about SlickEdit. It seems it has macro support, so I guess there has to be a way even if it's not in the built-in options - but I don't know more... #32 submitted by KarenS on September 21, 2006 - 16:06

Awesome!!! Great job. I really pushed your date conversion functions and tested all kinds of pre-1970 dates and it seems to work fine. I see a few other things that need to be changed, minor issues compared to getting the date conversions to work. When using a date with am/pm it was putting a colon between the time and ampm (easily fixed), and it does not quite seem to be handling the jscalendar conversion on the timestamp date right. Everything else seems to work great, and I think I can figure out the rest of it. I also see it is trying to add time to some dates that should not have time, which is unrelated to your work, it was a bug in the original module, so I'll try to get this fixed, too. Hopefully I'll have something to commit pretty soon. #33 submitted by KarenS on September 21, 2006 - 16:32 Found the remaining problem -- a variable with the wrong name in the jscalendar2iso function. Committed these changes to cvs. I'll hold off on committing them to the 4.7 branch in case anyone runs into unexpected problems. The cvs version is still compatible with 4.7, so you can test it in a 4.7 environment. Please report back if you have problems, otherwise I'll commit the 4.7 version, too. @yched, I owe you a huge thank you for all this work!! It's so nice to have the jscalendar widget using a more normal looking date format. #34 submitted by bdragon on September 26, 2006 - 01:45 Date_views.inc has a call to date_jscalendar2iso on line 86. Need to fix that.... #35 submitted by bdragon on September 26, 2006 - 06:17 After staring at the code for a while, I have realized I have absolutely no clue how to fix this. :-/ What changes would need to be made to views_filter_handler to get it working with these changes? (Additionally, what would the string be to select "Last 24 hours"? @P-24H? The documentation isn't very clear on ranges ENDING with NOW().... Also, is there a way to specify the range "TODAY 00:00:00.00 to NOW()?") Is the "Date Range Argument" documentation in date_views_help() still accurate with this new way of storing dates? Sorry I couldn't provide a patch, but I don't know this module very well yet... :-( --Brandon #36 submitted by KarenS on September 26, 2006 - 10:52 @bdragon - yes, I missed the fixes needed for date_views.inc. Working on that now. The date range question is unrelated to this issue, but basically the 'period to now' condition

isn't yet working, but I hope to add that soon (that's noted in the documentation in the file). All the 'period from now' possibilities should be OK. #37 submitted by KarenS on September 30, 2006 - 14:20 These changes have now been committed both to cvs and 4.7. @bdragon you also asked about using the new format in the jscalendar widget in views. I spent some time and wasn't able to get that working, but just ran across another issue that gave me an idea how it might work, so when/if I get time I'll work on it, but that's another issue. #38 submitted by KarenS on September 30, 2006 - 14:21 Status: patch (code needs review) » fixed Oops, meant to mark it fixed. #39 submitted by Anonymous (not verified) on October 14, 2006 - 14:30 Status: fixed » closed

User login
Username: * Password: *
Log in

 

Create new account Request new password

New forum topics
               

menus formular upgrade ecommerce fatal error Howto change code & tekst in content area? Drupal + CivicRM + Civinode Need help with forms! (new to drupal and php) basic module question i18n language depedant variables Require Theme designer for drupal based websites Is it possible to see how many posts a user has made after the posts have been deleted? fields arrangement References for node_access, please! Regarding my problem to use my own PHP Code in Drupal 5.X Recent Links (Node) Problem How do I show a block only when navigating within a certain term? Module for classified ads no uploads > 1MB even though upload limit is 2MB

   

Fatal error: Call to undefined function: product_form_is_product() in /usr/local/home/httpd/vhtdocs/foo.co.uk/new1/module Taxonomy Grouping More control with taxonomy menu Can Drupal handle big sites? 25.000 - 100.000 content items / nodes

more


								
To top