#1343: Disable failed validator's field removal.
---------------------------------+------------------------------------------
Reporter: saracen | Owner: dominik
Type: enhancement | Status: closed
Priority: normal | Milestone: 1.0.5
Component: validation | Version: 1.0.4
Severity: normal | Resolution: wontfix
Keywords: validation severity | Has_patch: 0
---------------------------------+------------------------------------------
Changes (by david):
* status: new => closed
* resolution: => wontfix
Comment:
As discussed on IRC
{{{
00:02 < Wombert> oi saracen
00:02 < saracen> lol
00:04 < Wombert> about the validator stuff
00:07 < saracen> Yeah
00:07 < saracen> Is there a way to do that?
00:07 < Wombert> it sounds like a terrible idea, saracen
00:07 < Wombert> mind explaining your use case?
00:07 < saracen> Yeah, one sec, lemme load up the codez
00:08 < Wombert> it's a can of worms I don't want to open
00:08 < Wombert> once we add that, all the clueless folks will start using
it :p
00:08 < Wombert> why don't you have a validator with low severity that
exports the value, then a second validator that validates it properly?
00:08 < Wombert> then the original would be gone, but the exported copy
would be there
00:09 < Wombert> and you get your way
00:09 < saracen> I dont see that they would, if it was a severity thing. I
always forget most of the other severities apart from "info". You could
just do a good job of not documenting it. :P
00:09 < saracen> Ok, lemme go in to what I'm doing:
00:09 < Wombert> please
00:10 < saracen> ObjectiveValidators. - Validates the objective does
indeed exist (from database) and exports the model. I use this essentially
everywhere. Now, the next validator is a validator which checks various
statuses of the Objective model, to see if can be deleted. (It's used on
the DeleteAction).
00:11 < saracen> It's not a matter of ACL. it's not about who can delete
it. It's an internal status thing on the objective "I *can* be deleted...
or not"
00:11 < saracen> I could do this in validateWrite(). But I prefer not to
00:12 < saracen> But you see, if it errors, I still want to display an
error on that page... with the objectives details (title etc.)
00:12 < Wombert> but if this fails... then why do you need the objective
instance still around?
00:12 < Wombert> ah
00:12 < Wombert> I see
00:13 < saracen> It's a rare case, but there's not even really a hack to
get around it. I've just had to pass the objective_id and fetch the object
again, which, isn't too bad, because the ORM would stop that additional
call. But i still feel like there should be a way out of it
00:29 < Wombert> saracen: it's such an edge case...
00:30 < Wombert> you might be able to cheat your way around it with
affected arguments blah blah
00:30 < Wombert> saracen: I think I'd do an internal forward to
Objectives.Objective.View or somesuch anyway
00:30 < Wombert> humm
00:33 < saracen> Is it *really* that much of an edge case? I really see it
as something I should be able to do. Export the value of a passed object,
because I'll need that, even in the error view, but also validate any
number of conditions on that object.
00:33 < Wombert> frankly, I'm not really sure if this check you're doing
really does belong into the validation part
00:35 < saracen> I thought about that too. The alternative would be to not
make any changes (delete the object), and forward to another view which
would set up a flash message/warning
00:35 < saracen> But, it's an *error* message. I like my error messages
defined where all my other ones are :(
00:36 < saracen> Stop making me break the consistancy, and create a new
severity type called "saracen".
00:36 < Wombert> well
00:36 < Wombert> what reporting severity would that have tho?
00:36 < Wombert> see, it's not that simple :)
00:36 < Wombert> error? fatal? warning? blah?
00:36 < saracen> I know, the name is the most difficult part
00:36 < Wombert> there'd have to be such a "modifier" for each level we
have
00:36 < Wombert> no, it's not just that
00:37 < saracen> But, you've got "info" and "notice", which are equally
ambigious at the moment
00:37 < Wombert> they aren't
00:37 < Wombert> you probably mean "info" and "silent"?
00:37 < saracen> Who knows. They all sound like they'd do the same thing.
00:37 < Wombert> it's that there should be a <validator keep="true" />
really, since you could combine it with various severities, but I won't
add that
00:38 < Wombert> info is just for info purposes. notice will only show up
as an error if there is another higher severity. error causes an error,
fatal causes an error and bails out of validation immediately
00:38 < saracen> If not that, it'd be nice to even put something hard
coded in the validator. It being an edge case, chances are it's because
it's a custom validator, where you know exactly what you're doing
00:39 < Wombert> let me check if that is possible
00:39 < Wombert> $this->setAffectedArguments(array());
00:39 < Wombert> that might work
00:39 * saracen checks
00:40 < Wombert> oh wait
00:40 < Wombert> $this->throwError() even supports this
00:40 < Wombert> that would be cleaner
00:40 < Wombert> let me see
00:40 < Wombert> try $this->throwError(null, array());
00:41 < saracen> didn't work
00:42 < Wombert> which?
00:42 < Wombert> what about $this->throwError(null, array(), false, true);
00:42 < saracen> Both. But when combined
00:43 < saracen> When setAffected and throwError(null etc. is combined, it
gets to the error view
00:43 < saracen> But, FPF doesnt setup the error message (assuming because
it doesnt know what field to assign it to anymore)
00:43 < Wombert> well there is no field, right?
00:44 < saracen> Oh, it's because i'm not throwing my error, we're using
null :P
00:44 < Wombert> nono
00:44 < saracen> That last one does get to the error view too
00:44 < Wombert> with null, it uses the default error message
00:44 < Wombert> <error>foo</error>, this
00:44 < saracen> Yeah, changed it to default now
00:44 < Wombert> use the last one then
00:44 < saracen> and it works, with the last version
00:44 < Wombert> okay, that works?
00:44 < Wombert> splendid
00:44 < saracen> :)
00:45 < saracen> Thank you :)
00:45 < Wombert> happy? :p
00:45 < Wombert> ok :D
00:45 < Wombert> np
}}}
--
Ticket URL: <http://trac.agavi.org/ticket/1343#comment:2>
Agavi <http://www.agavi.org/>
An MVC Framework for PHP5
_______________________________________________
Agavi Tickets Mailing List
[email protected]
http://lists.agavi.org/mailman/listinfo/tickets
