Issues

ZF-2898: Zend_Validate / Zend_Filter $namespaces search order

Description

When providing Zend_Validate or Zend_Filter with a classBasename with the same name as a Zend_Validate or Zend_Filter class but different namespaces Zend_Validate / Zend_Filter class is a higher priority in the include list.

e.g. Zend_Validate::is('123asd', 'Int', null, array('MyWeb_Validate'));

This would include the Zend_Validate_Int before it would include MyWeb_Validate_Int I think this should be changed to make the users vaildate be included first.

Comments

Quick example of just swapping the array_merge

The desired change would be a backward compatibility break, so I'm marking to be fixed for next major release, pending demonstration that the original behavior is broken (e.g., documentation states otherwise intended behavior).

Hi Darby,

So if this seems like a dumb question. But fixes that have been okayed for the next major release, does this make them safe to be committed to trunk and not merged into branch? or is it best to leave it?

As this would not be a strictly backward-compatible change, I must say to leave it as is for now, but I do support making the change as an improvement for the next major release (the upgrade path will need to be well-documented). If instead it can be demonstrated that this is truly a bug (e.g., violating documented behavior), then we should be able to fix it with less regard for keeping backward compatibility.

I agree with you regarding the BC change.

I am somewhat concerned that a script that could work today with no problems with namespace could break tomorrow due to the ZF adding a Filter or Validation calss of the same type.

e.g. Zend_Validate::is('123', 'Number', null, array('MyWeb_Validate'));

Might be fine right now, but lets say ZF adds a Zend_Validate_Number it would now not see my namespace as important as it uses the ZF's class not mine. Quite a big problem as I see it.

It is expected that in the rest of the ZF we use a LIFO (stack) approach for things. I certainly expected the same behavior here.

Lets take view scripts as an example, Quoted from the mailing list. {quote} Script paths added later get searched first, script paths added earlier get searched last, LIFO. This is so that you can have later script paths override defaults. If we did this as a FIFO, you would never be able to override default paths with local paths. {quote}

The current behavior is decidedly broken, so I've marked it as to fix for next mini-release. Documentation should be updated to cover the change.

Ralph, are you in agreement with Darby that the behavior is broken? Should we fix this in the next minor release? I don't want to make a backwards incompatible fix in a mini release.

I've been thinking about this one abit more. Find it hard to see how anyone could be using this in a way that could BC? Thoughts?

Fixed with r14567 for r1.8