Joerg Heinicke dijo:
> Antonio Gallardo <agallardo <at> agssa.net> writes:
>
>> > The main visible result of this is that <fd:validation> is now a
>> > direct child of <fd:field> (or other widget-defining element), and no
>> > more a child of <fd:datatype>.
>> >
>> > Validation as a child of <fd:datatype> is still supported as a legacy
>> > behaviour, but I would like to remove it to drive people towards the
>> new
>> > generalized validation. My plan to ease the migration is to raise a
>> > meaningful exception ("fd:validation has moved") whenever we encounter
>> a
>> > fd:validation inside a fd:datatype.
>> >
>> > Thoughts?
>
> +1 As long we don't have a first final release of CForms I would like to
> see
> everything being cleaned up immediately. I also cleaned up
> @unique-row-(id|path)
> at repeaters, what Antonio did not like that much.

No concerns at all, ...maybe it hurts a little just for the time I spent
to write the code. But it is gone now. :-D

>
>> +1 - Why care about legacy, when the block is still unstable? :-D
>
> And therefore Antonio is getting sarcastic on his old days ;-)

No sarcastic. I truly believe that. I agreed with you POV before. Reading
in the in the block.properties I think this is the same feeling:

<snip>
Unstable blocks are currently under development and do not guarantee that the
# contracts they expose (API, xml schema, properties, behavior) will remain
# constant in time. Developers are not committed to back-compatibility
just yet.
# This doesn't necessarily mean the blocks implementation is unstable or
# the code can't be trusted for production, but use with care and watch
# its development as things might change over time before they are marked
# stable.
</snip>

WDYT?

Best Regards,

Antonio Gallardo

Reply via email to