Not sure if this is a good idea or not, but let me think out load for
second.
What if you created an additional model just for warnings? You could
create all the rules just for that model, and use vanilla form helper
error messages, controller workflow, etc.
Then you could also validate that information against the "real"
model, looking for errors. Once you have all the validation errors
from both models you can reconcile them as you wish.
$0.02
-- John
On Jan 25, 2008, at 9:28 AM, grigri wrote:
>
>> Can you tell us more about why you need warnings?
>
> Sure, no problem. It's quite simple really.
>
> I need to set up some validation rules that, when not matched, don't
> mean "the data is definitely not valid and cannot be saved" but "the
> data is probably not valid and I want to double-check if the user
> really wants to do this".
>
> A good example is in my family tree. The end-user-administrator of the
> system isn't very computer-savvy, so it needs to be as forgiving as
> possible (at his own request). It is highly unlikely that two cousins
> marry, but it CAN happen. It's much more likely that the user messed-
> up his notes and entered the wrong id, name, or whatever. But I need
> to make sure. This is just one example, there are a lot more (like
> marrying when the individual is under/over a certain age: it's more
> likely that the user typed the wrong date than someone actually
> marrying at 13, but again, it is possible).
>
> I can easily implement these as validation rules, but then these edge-
> cases would not be allowed at all. So if I do, I get a lot of emails/
> phone calls from the client complaining that it's not flexible, and I
> have to manually update the database. If I don't, the wrong data is
> input and can potentially screw up the entire display (the dynamic
> timeline and whatnot), and I eventually get an email / phone call from
> the client and I have to check every entry in the database and fix it.
> Either way, it makes the system (and therefore the company) look bad.
>
> So, I'd like to implement a warnings system. Personally, I hate being
> second-guessed by a computer ("Are you sure you want to rename
> this .txt file to a .php file? It could really damage your system...",
> etc...), but the end-users this system is for (and probably a lot of
> future clients) need more handholding.
>
> -----
>
> Oh, and I've just realized I've contradicted myself here (controllers
> should be agnostic / double-check if the user really wants to do
> this).
>
> Perhaps a rethink is in order...
>
>
>
> On Jan 25, 4:04 pm, "John David Anderson (_psychic_)"
> <[EMAIL PROTECTED]> wrote:
>> Can you tell us more about why you need warnings? The simplest
>> alternative might be a completely alternate approach.
>>
>> -- John
>>
>> On Jan 25, 2008, at 8:19 AM, grigri wrote:
>>
>>
>>
>>> I am using 1.2 (have been for a while), and I'm very impressed by
>>> its
>>> validation system. But I can't see how I can do what I need without
>>> more code. I'll try and explain.
>>
>>> The basic system of "warnings" could be implemented by having a
>>> beforeValidate() method (in a Behavior or Model) which enumerates
>>> the
>>> $validate array [*], checks for entries with a specific option (such
>>> as 'warning' => true), then cross-checks that against a different
>>> key
>>> in the data (corresponding to the 'ignore warning' checkbox), and if
>>> present, temporarily removes it from the validation array (setting
>>> 'on' to any value other that 'create', 'update' or null would
>>> accomplish this).
>>
>>> [ * The orderings of validation and warning entries would be crucial
>>> for this to work properly, because an error must always override a
>>> warning. ]
>>
>>> At this point, it can flag the field as failing, but when the form
>>> helper outputs the error message, I need it to output an extra
>>> checkbox dynamically with a specific name and value. Although I
>>> could
>>> code this directly in the beforeValidate() [a bit messy, but still
>>> possible], the FormHelper::input() method, when calling
>>> FormHelper::error(), ALWAYS escapes the HTML, so I'd be rendering
>>> HTML
>>> code not real working HTML.
>>
>>> I could of course code the "error message" in a specific way (like
>>> "{{{WARNINGDATA:encoded_data_here}}}") then do a
>>> preg_replace_callback
>>> in a helper afterRender() method, but it's quite a messy way of
>>> doing
>>> things, with a possible performance hit. Plus I'd have to add the
>>> helper in the controller; which should really be agnostic to this
>>> information.
>>
>>> I'm wondering if I'm making this more complicated than it needs to
>>> be.
>>> Based on what I've explained I'd like to achieve, can you see a
>>> different (possibly simpler) way of doing it?
>>
>>> Thanks
>>
>>> On Jan 25, 2:20 pm, "John David Anderson (_psychic_)"
>>> <[EMAIL PROTECTED]> wrote:
>>>> On Jan 25, 2008, at 6:38 AM, grigri wrote:
>>
>>>>> I'd like to hear some suggestions on cakeifying an existing
>>>>> system.
>>
>>>>> Cake's validation is wonderful, but it only allows "yes this is
>>>>> good"
>>>>> and "no it isn't". I've got an application I need to port that has
>>>>> automated warnings built in for some fields.
>>
>>>> Have you checked out validation in 1.2? Multiple rules, pre build
>>>> validators, easy custom rules.. I think you can easily do what you
>>>> need in 1.2.
>>
>>>> -- John
>>
>>>>> Although my system is quite specific (it's a historic family tree,
>>>>> so
>>>>> most of the warnings are like "Warning: this marriage is between
>>>>> two
>>>>> cousins / brother and sister, are you sure?), I could see a
>>>>> generic
>>>>> application, for example for URLs (warning: this URL returns a
>>>>> 404,
>>>>> are you sure you want to add it?) or passwords (this is a crappy
>>>>> password choice, use it at your own risk...).
>>
>>>>> My old system gave each warning generated a session-level id and
>>>>> presented an appropriate checkbox in the field 'error' position.
>>>>> The
>>>>> validation routine checked if the checkbox was checked for each
>>>>> registered warning and ignored it if appropriate. If there were no
>>>>> errors, and no unchecked warnings, the form went through.
>>
>>>>> My old system was not very flexible, a mish-mash of php includes
>>>>> and
>>>>> whatnot, and I need to cakeify it.
>>
>>>>> So, any suggestions on how to introduce this functionality to
>>>>> cake,
>>>>> without rewriting the form helper or model validations? I've got a
>>>>> few
>>>>> ideas but I'd like to hear input.
>>
>>>>> (Once I've got a solid "normal" foundation for it, I'd like to
>>>>> extend
>>>>> to js/ajax too, but this is definitely for later)
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---
