Issues

ZF-2898: Zend_Validate / Zend_Filter $namespaces search order

Issue Type: Improvement Created: 2008-03-17T07:27:02.000+0000 Last Updated: 2009-03-31T14:46:44.000+0000 Status: Resolved Fix version(s): - 1.8.0 (30/Apr/09)

Reporter: James Dempster (letssurf) Assignee: Thomas Weidner (thomas) Tags: - Zend_Filter

  • Zend_Validate

Related issues: Attachments: - zend_filter_changed_search_order.patch

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

Posted by James Dempster (letssurf) on 2008-03-17T07:52:17.000+0000

Quick example of just swapping the array_merge

Posted by Darby Felton (darby) on 2008-04-02T14:48:26.000+0000

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).

Posted by James Dempster (letssurf) on 2008-04-04T11:16:46.000+0000

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?

Posted by Darby Felton (darby) on 2008-04-07T08:50:08.000+0000

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.

Posted by James Dempster (letssurf) on 2008-04-14T08:09:23.000+0000

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}

Posted by Darby Felton (darby) on 2008-04-21T13:05:13.000+0000

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.

Posted by Wil Sinclair (wil) on 2009-01-20T17:22:46.000+0000

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.

Posted by James Dempster (letssurf) on 2009-01-23T09:14:46.000+0000

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?

Posted by Thomas Weidner (thomas) on 2009-03-31T14:46:39.000+0000

Fixed with r14567 for r1.8

Have you found an issue?

See the Overview section for more details.

Copyright

© 2006-2016 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.

Contacts