|
Smarty
WARNING: All discussion is moving to https://reddit.com/r/smarty, please go there! This forum will be closing soon. |
|
View previous topic :: View next topic |
Author |
Message |
schoenung Smarty Rookie
Joined: 05 Apr 2004 Posts: 28
|
Posted: Thu Oct 21, 2004 2:49 am Post subject: transforms |
|
|
I understand that transforms are applied first then the field is validated. I was wondering if there might be a solution to convert dates to mysql native format from US std.
A transform can be easily written for this. My problem is figuring a good way of transforming the data for inclusion of a database.
For example a user enters:
12/31/2004 as a date
A transform can convert this to 2004-12-31 and a validator can valid it. On an error however 2004-12-31 would be echoed back to the form. This would confuse the user.
Another transform that would act this way is something that escapes data, like mysq_escape_string as the escaped string would be echoed back to the form on error.
Maybe Smarty Validate should not be used this way and the data convertion and/or prep for db insertion should be handled in the php code.
Thoughts? |
|
Back to top |
|
boots Administrator
Joined: 16 Apr 2003 Posts: 5611 Location: Toronto, Canada
|
Posted: Thu Oct 21, 2004 4:38 am Post subject: |
|
|
Ack! I see this as one of the dangers of SmartyValidate--it is tempting to use it in this way but I for one wouldn't want my data layer to rely on my display layer to provide valdiation and transformation. I see SmartyValidate still working at the "logical" level of data validation. There is absolutely no reason that the display layer should even be aware of the implementation details of the back-end storage let-alone provide the data transforms to meet the needs of the back-end storage layer.
I agree with Monte's comments that he made in another recent thread: SmartyValidate is definately useful and leads to a very usable workflow. I just think that (presently) it does not encompass enough to be an end-to-end validation/transform mechanism. I think I might be more enthusiastic if the actual "template" code for the validation specifications were not contained in the display template but rather were isolated in their own separate template/layer. This probably does not fit in with the "ease" of SmartyValidate's current implementation, but IMVHO, that is all for the better.
Never-the-less, I do think SmartyValidate is some really nice code and is indeed a powerful tool. I'm just giving my 2c because I think it is already crossing some "boundaries" (though advisedly); pushing the model too far may not be a great idea.
Feel free to bitch-slap me if you disagree -- I'm sure I deserve it |
|
Back to top |
|
mohrt Administrator
Joined: 16 Apr 2003 Posts: 7368 Location: Lincoln Nebraska, USA
|
Posted: Thu Oct 21, 2004 1:57 pm Post subject: |
|
|
I think transform functions should only be used in a way that does not interfere with the presentation of the form content in a negative way. For instance, the trim transform function "cleans up" the data in a way the user probably should have entered it anyways. However, changing the date (presentation) format is not a good idea. You are better off changing the format just before the database insertion, not during form validation. |
|
Back to top |
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|