Even if there were no BC issues I would be opposed to a
sfWidgetFormInputBase class. It doesn't make semantic sense. The name
implies it is the parent class of sfWidgetFormInput, which is true.
However, one would likewise expect sfWidgetFormInputPassword to extend
sfWidgetFormInput, which
In 1.3 we can break the BC of course but not 1.0, 1.1, 1.2, etc.
- Jon
On Thu, Apr 16, 2009 at 3:25 PM, Tom Boutell wrote:
>
> That would definitely be an appropriate response for 1.2. Does it make
> sense in the 1.3 series? Isn't 1.3 supposed to be bleeding edge
> developer-only stuff right no
That would definitely be an appropriate response for 1.2. Does it make
sense in the 1.3 series? Isn't 1.3 supposed to be bleeding edge
developer-only stuff right now? We are talking about 1.3, right? (:
On Thu, Apr 16, 2009 at 1:36 PM, Jonathan Wage wrote:
> But that does not matter. Most people
But that does not matter. Most people don't pay attention to what changes
are in a point release. They simply do pear upgrade/svn update and they
expect that it isn't going to break their application. If it does, then that
person lost the little bit of trust they had in symfony and probably won't
e
I agree with Tom. In this special case I would say that the benefit of
this changes is higher than the pain you'll get to change you're code.
- Dennis
2009/4/16 Tom Boutell :
>
> I suppose it would be a BC break for anyone who is already using
> instanceof() to check whether something is one of
True. I see now. Either way it is a BC break.
- Jon
On Wed, Apr 15, 2009 at 6:13 PM, Tom Boutell wrote:
>
> I suppose it would be a BC break for anyone who is already using
> instanceof() to check whether something is one of sfWidgetFormInput's
> subclasses. But isn't this the sort of very mino
I suppose it would be a BC break for anyone who is already using
instanceof() to check whether something is one of sfWidgetFormInput's
subclasses. But isn't this the sort of very minor incompatibility that
would almost have to be allowed for 1.3 to differ meaningfully from
1.2?
On Wed, Apr 15, 20
I considered this option but I see it as a BC break because
sfWidgetFormInputPassword (for instance) would no longer extend
sfWidgetFormInput.
--
Kris Wallsmith | Community Manager
kris.wallsm...@symfony-project.com
Portland, Oregon USA
http://twitter.com/kriswallsmith
On Apr 15, 2009, at 3
So right now we can't identify a normal input field by doing instanceof
sfWidgetFormInput because all the other widget types extend that? If so,
what about this so that it maintains BC and you still use sfWidgetFormInput.
1.) Rename sfWidgetFormInput to sfWidgetFormInputBase(or something similar)
I agree, this is a smart choice.
On Wed, Apr 15, 2009 at 3:27 AM, Dennis Benkert
wrote:
>
> Nice improvement. +1 for it.
>
> - Dennis
>
> 2009/4/14 Kris Wallsmith :
>> I've just opened a ticket on Trac to add a sfWidgetFormInputText class to
>> the 1.3 branch. The addition of this class will set
Nice improvement. +1 for it.
- Dennis
2009/4/14 Kris Wallsmith :
> I've just opened a ticket on Trac to add a sfWidgetFormInputText class to
> the 1.3 branch. The addition of this class will set text fields on the same
> level as password and file upload fields and allow developers to identify
>
11 matches
Mail list logo
