[TYPO3-dev] Deprecation strategy for BE viewhelpers

[Frans Saris]

Hi all,

tnx for the feedback.

So general viewhelpers should go in ext:fluid an these are "available"  for
the extensions (part of public api).

I think for ext:media we will create our own viewhelper just to keep
backward compatible between 6.1 and 6.2.

One other question. Are there guidelines for what could/should be added to
the ext:fluid viewhelpers? Because currently there is a new viewhelper in
ext:documentation (Be\Security\IfAdminViewHelper) that imho should go in
ext:fluid.

gr. Frans


2013/8/5 Helmut Hummel <helmut.hummel at typo3.org>

> Hi!
>
>
> On 05.08.13 11:37, Steffen Müller wrote:
>
>  On 05.08.2013 10:07 Christian Kuhn wrote:
>>
>>> You create a dependency to a foreign extension just because of a single
>>> view helper this way. This is tight coupling for no good reason, we
>>> shouldn't do this:
>>>
>>
> Exactly. Full ACK.
>
>
>  The view helpers in extension manager, belog, beuser
>>> and so on are dedicated to this extension only and can be changed at
>>> will.
>>>
>>
>> This is hard to understand for those who have not deep insight to the
>> core structure:
>>
>
> Well, there are a lot of things which are hard to understand without deep
> insight ;)
>
>
>  We have sysext:core, which contains the core API, then we have
>> sysext:extensionmanager which is part of the core, but VH are non-API,
>> then we have sysext:fluid which VH are API.
>> IMHO chances are high to misunderstand this concept and rely on VH from
>> extensionmanager, because they have public keypwrd and are shipped with
>> the core.
>>
>
> There are a *lot* of places, which can be (and are) "abused" by extension
> developers to achieve sth. ...
>
>
>  To keep our developers happy, we'd better deprecate UNTIL we
>> have @internal notation.
>>
>
> ... marking everything as @internal (like global arrays, public properties
> etc. could be useful, but there will always be things that break and only
> experience will tell you as a developer how to do things in a proper way to
> be as decoupled as possible and as compatible as possible with future
> versions.
>
>
>  We should imho state somewhere: "Only view helpers in ext:fluid are
>>> public API and are part of the usual deprecation strategy, view helpers
>>> in other core extensions are not public API and can change without
>>> further notice." Maybe we can also annotate the other extensions view
>>> helpers with @internal to make this clear when reading the code.
>>>
>>
>> +1
>>
>
> -1 to mark things as @internal but +1 to mark public API with @api like
> Flow does and documenting this fact somewhere.
>
> It is better to have everything private by default and explicitly making
> things public than the other way around.
>
> By doing so, forgetting an annotation would then mean this entity is
> private and likely to change.
>
> Kind regards,
> Helmut
>
> --
> Helmut Hummel
> Release Manager TYPO3 6.0
> TYPO3 Core Developer, TYPO3 Security Team Member
>
>
> TYPO3 .... inspiring people to share!
> Get involved: typo3.org
>
> ______________________________**_________________
> TYPO3-dev mailing list
> TYPO3-dev at lists.typo3.org
> http://lists.typo3.org/cgi-**bin/mailman/listinfo/typo3-dev<http://lists.typo3.org/cgi-bin/mailman/listinfo/typo3-dev>
>