I have a problem with the integration of the Versionable behaviour.
Had a baseclass "Member", with some custom validation, i.e. just a
method to "pre"validate before submit.
One of the fields has minlength=4 .
When disabling the behaviour everything works fine.
But when enabling Versionable it shows me
"Validation failed in class MemberVersion 1 field had validation
error:
* 1 validator failed on password (minlength) "
Huh?
Another point is: the options of the behaviours are all documented but
not
for Versionable, so often one has to guess what the options are for.
Is there a documentation?
> I have a problem with the integration of the Versionable behaviour.
> Had a baseclass "Member", with some custom validation, i.e. just a
> method to "pre"validate before submit.
> One of the fields has minlength=4 .
> When disabling the behaviour everything works fine.
> But when enabling Versionable it shows me
> "Validation failed in class MemberVersion 1 field had validation
> error:
> * 1 validator failed on password (minlength) "
> Huh?
> Another point is: the options of the behaviours are all documented but
> not
> for Versionable, so often one has to guess what the options are for.
> Is there a documentation?
One solution that I have been able to come up with is to wrap the
isValid in a try and catch the Validator exception. Example:
try {
$rec->isValid();
} # end try
catch (Doctrine_Validator_Exception $e) {
# Process all the invalid records encountered.
foreach ($e->getInvalidRecords() as $rec) {
foreach ($rec->getErrorStack() as $fld => $rulefailedon) {
# Process the invalid fields encountered for the record.
...
} # end foreach
} # end foreach
} # end catch
But to determine the root cause I traced through the source to try to
determine the reason isValid throws an exception and it is because in
the preUpdate call in Listener.php for AuditLog it attempts to save
the version record without any try/catch around it. It does the
saving of the version record prior to saving the final record. So a
solution to this is to replace the save() call with a saveTry() since
if it fails the saving of the live version will fail too since they
use the same validation rules.
I hope this helps.
On Nov 5, 7:01 am, Nino Martincevic <d...@zampano.com> wrote:
> Has anyone a solution or hint for this?
> Otherwise couldn't use that feature, which would be very sad ...
> Thx!
> zampano schrieb:
> > Hi Folks!
> > I have a problem with the integration of theVersionablebehaviour.
> > Had a baseclass "Member", with some custom validation, i.e. just a
> > method to "pre"validate before submit.
> > One of the fields has minlength=4 .
> > When disabling the behaviour everything works fine.
> > But when enablingVersionableit shows me
> > "Validation failed in class MemberVersion 1 field had validation
> > error:
> > * 1 validator failed on password (minlength) "
> > Huh?
> > Another point is: the options of the behaviours are all documented but
> > not
> > forVersionable, so often one has to guess what the options are for.
> > Is there a documentation?
On Thu, Nov 19, 2009 at 3:23 PM, David Engeset <froggy...@gmail.com> wrote:
> One solution that I have been able to come up with is to wrap the
> isValid in a try and catch the Validator exception. Example:
> try {
> $rec->isValid();
> } # end try
> catch (Doctrine_Validator_Exception $e) {
> # Process all the invalid records encountered.
> foreach ($e->getInvalidRecords() as $rec) {
> foreach ($rec->getErrorStack() as $fld => $rulefailedon) {
> # Process the invalid fields encountered for the record.
> ...
> } # end foreach
> } # end foreach
> } # end catch
> But to determine the root cause I traced through the source to try to
> determine the reason isValid throws an exception and it is because in
> the preUpdate call in Listener.php for AuditLog it attempts to save
> the version record without any try/catch around it. It does the
> saving of the version record prior to saving the final record. So a
> solution to this is to replace the save() call with a saveTry() since
> if it fails the saving of the live version will fail too since they
> use the same validation rules.
> I hope this helps.
> On Nov 5, 7:01 am, Nino Martincevic <d...@zampano.com> wrote:
>> Has anyone a solution or hint for this?
>> Otherwise couldn't use that feature, which would be very sad ...
>> Thx!
>> zampano schrieb:
>> > Hi Folks!
>> > I have a problem with the integration of theVersionablebehaviour.
>> > Had a baseclass "Member", with some custom validation, i.e. just a
>> > method to "pre"validate before submit.
>> > One of the fields has minlength=4 .
>> > When disabling the behaviour everything works fine.
>> > But when enablingVersionableit shows me
>> > "Validation failed in class MemberVersion 1 field had validation
>> > error:
>> > * 1 validator failed on password (minlength) "
>> > Huh?
>> > Another point is: the options of the behaviours are all documented but
>> > not
>> > forVersionable, so often one has to guess what the options are for.
>> > Is there a documentation?
> --
> You received this message because you are subscribed to the Google Groups "doctrine-user" group.
> To post to this group, send email to doctrine-user@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/doctrine-user?hl=.
My understanding of the original post is they did use the built-in min
length validator and that works fine but the issue is an exception is
thrown when you call isValid which should not happen.
On Nov 19, 2:23 pm, "A.J. Brown" <a...@ajbrown.org> wrote:
> On Thu, Nov 19, 2009 at 3:23 PM, David Engeset <froggy...@gmail.com> wrote:
> > One solution that I have been able to come up with is to wrap the
> > isValid in a try and catch the Validator exception. Example:
> > try {
> > $rec->isValid();
> > } # end try
> > catch (Doctrine_Validator_Exception $e) {
> > # Process all the invalid records encountered.
> > foreach ($e->getInvalidRecords() as $rec) {
> > foreach ($rec->getErrorStack() as $fld => $rulefailedon) {
> > # Process the invalid fields encountered for the record.
> > ...
> > } # end foreach
> > } # end foreach
> > } # end catch
> > But to determine the root cause I traced through the source to try to
> > determine the reason isValid throws an exception and it is because in
> > the preUpdate call in Listener.php for AuditLog it attempts to save
> > the version record without any try/catch around it. It does the
> > saving of the version record prior to saving the final record. So a
> > solution to this is to replace the save() call with a saveTry() since
> > if it fails the saving of the live version will fail too since they
> > use the same validation rules.
> > I hope this helps.
> > On Nov 5, 7:01 am, Nino Martincevic <d...@zampano.com> wrote:
> >> Has anyone a solution or hint for this?
> >> Otherwise couldn't use that feature, which would be very sad ...
> >> Thx!
> >> zampano schrieb:
> >> > Hi Folks!
> >> > I have a problem with the integration of theVersionablebehaviour.
> >> > Had a baseclass "Member", with some custom validation, i.e. just a
> >> > method to "pre"validate before submit.
> >> > One of the fields has minlength=4 .
> >> > When disabling the behaviour everything works fine.
> >> > But when enablingVersionableit shows me
> >> > "Validation failed in class MemberVersion 1 field had validation
> >> > error:
> >> > * 1 validator failed on password (minlength) "
> >> > Huh?
> >> > Another point is: the options of the behaviours are all documented but
> >> > not
> >> > forVersionable, so often one has to guess what the options are for.
> >> > Is there a documentation?
> > --
> > You received this message because you are subscribed to the Google Groups "doctrine-user" group.
> > To post to this group, send email to doctrine-user@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/doctrine-user?hl=.
David Engeset wrote:
> My understanding of the original post is they did use the built-in min
> length validator and that works fine but the issue is an exception is
> thrown when you call isValid which should not happen.
Yes, that's right.
Thanks for your workaround.
But what I ask myself, am I the only one using that feature?
I don't think what I'm doing here is very exoctic, is it?
And the second part of my question was if there is a doc/faq/blog-entry for versionable options.
> On Nov 19, 2:23 pm, "A.J. Brown" <a...@ajbrown.org> wrote:
>> Have you tried using the built-in validation methods instead of your
>> custom validaiton?
>> On Thu, Nov 19, 2009 at 3:23 PM, David Engeset <froggy...@gmail.com> wrote:
>>> One solution that I have been able to come up with is to wrap the
>>> isValid in a try and catch the Validator exception. Example:
>>> try {
>>> $rec->isValid();
>>> } # end try
>>> catch (Doctrine_Validator_Exception $e) {
>>> # Process all the invalid records encountered.
>>> foreach ($e->getInvalidRecords() as $rec) {
>>> foreach ($rec->getErrorStack() as $fld => $rulefailedon) {
>>> # Process the invalid fields encountered for the record.
>>> ...
>>> } # end foreach
>>> } # end foreach
>>> } # end catch
>>> But to determine the root cause I traced through the source to try to
>>> determine the reason isValid throws an exception and it is because in
>>> the preUpdate call in Listener.php for AuditLog it attempts to save
>>> the version record without any try/catch around it. It does the
>>> saving of the version record prior to saving the final record. So a
>>> solution to this is to replace the save() call with a saveTry() since
>>> if it fails the saving of the live version will fail too since they
>>> use the same validation rules.
>>> I hope this helps.
>>> On Nov 5, 7:01 am, Nino Martincevic <d...@zampano.com> wrote:
>>>> Has anyone a solution or hint for this?
>>>> Otherwise couldn't use that feature, which would be very sad ...
>>>> Thx!
>>>> zampano schrieb:
>>>>> Hi Folks!
>>>>> I have a problem with the integration of theVersionablebehaviour.
>>>>> Had a baseclass "Member", with some custom validation, i.e. just a
>>>>> method to "pre"validate before submit.
>>>>> One of the fields has minlength=4 .
>>>>> When disabling the behaviour everything works fine.
>>>>> But when enablingVersionableit shows me
>>>>> "Validation failed in class MemberVersion 1 field had validation
>>>>> error:
>>>>> * 1 validator failed on password (minlength) "
>>>>> Huh?
>>>>> Another point is: the options of the behaviours are all documented but
>>>>> not
>>>>> forVersionable, so often one has to guess what the options are for.
>>>>> Is there a documentation?
I agree that what you are trying to do is not exotic as I am looking
to do the same thing. I opened a bug report on the issue and per Jon
Wage's question back to me I think a proper work around for now is to
call isValid with the parameters (false, false) which the key is the
second parameter which tells it to not call any preUpdate or the like
hooks, otherwise as I discovered calling isValid will cause
Versionable to create a new version record, if no error is
encountered, before a save is done. As for documentation the only
information I could find on the parameters was to look at the
Versionable class itself and see the options array and decipher from
that what you want to do.
I hope that helps.
On Nov 24, 9:51 am, Nino Martincevic <d...@zampano.com> wrote:
> David Engeset wrote:
> > My understanding of the original post is they did use the built-in min
> > length validator and that works fine but the issue is an exception is
> > thrown when you call isValid which should not happen.
> Yes, that's right.
> Thanks for your workaround.
> But what I ask myself, am I the only one using that feature?
> I don't think what I'm doing here is very exoctic, is it?
> And the second part of my question was if there is a doc/faq/blog-entry
> for versionable options.
> Thx!
> > On Nov 19, 2:23 pm, "A.J. Brown" <a...@ajbrown.org> wrote:
> >> Have you tried using the built-in validation methods instead of your
> >> custom validaiton?
> >> On Thu, Nov 19, 2009 at 3:23 PM, David Engeset <froggy...@gmail.com> wrote:
> >>> One solution that I have been able to come up with is to wrap the
> >>> isValid in a try and catch the Validator exception. Example:
> >>> try {
> >>> $rec->isValid();
> >>> } # end try
> >>> catch (Doctrine_Validator_Exception $e) {
> >>> # Process all the invalid records encountered.
> >>> foreach ($e->getInvalidRecords() as $rec) {
> >>> foreach ($rec->getErrorStack() as $fld => $rulefailedon) {
> >>> # Process the invalid fields encountered for the record.
> >>> ...
> >>> } # end foreach
> >>> } # end foreach
> >>> } # end catch
> >>> But to determine the root cause I traced through the source to try to
> >>> determine the reason isValid throws an exception and it is because in
> >>> the preUpdate call in Listener.php for AuditLog it attempts to save
> >>> the version record without any try/catch around it. It does the
> >>> saving of the version record prior to saving the final record. So a
> >>> solution to this is to replace the save() call with a saveTry() since
> >>> if it fails the saving of the live version will fail too since they
> >>> use the same validation rules.
> >>> I hope this helps.
> >>> On Nov 5, 7:01 am, Nino Martincevic <d...@zampano.com> wrote:
> >>>> Has anyone a solution or hint for this?
> >>>> Otherwise couldn't use that feature, which would be very sad ...
> >>>> Thx!
> >>>> zampano schrieb:
> >>>>> Hi Folks!
> >>>>> I have a problem with the integration of theVersionablebehaviour.
> >>>>> Had a baseclass "Member", with some custom validation, i.e. just a
> >>>>> method to "pre"validate before submit.
> >>>>> One of the fields has minlength=4 .
> >>>>> When disabling the behaviour everything works fine.
> >>>>> But when enablingVersionableit shows me
> >>>>> "Validation failed in class MemberVersion 1 field had validation
> >>>>> error:
> >>>>> * 1 validator failed on password (minlength) "
> >>>>> Huh?
> >>>>> Another point is: the options of the behaviours are all documented but
> >>>>> not
> >>>>> forVersionable, so often one has to guess what the options are for.
> >>>>> Is there a documentation?
|
