[TYPO3-v4] TCA Valueslider Wizard

[Ernesto Baschny [cron IT]]

Tolleiv.Nietsch schrieb am 14.03.2011 21:03:

> Am 14.03.2011 18:30, schrieb Ernesto Baschny [cron IT]:

>> Now that's in the core, this is *the API* and noone needs to feel the
>> need to risk their stable extensions by depending on some third party
>> extension which has an unclear future.

> Sorry I've to disagree - it's just a feature which you can turn on/off
> if needed, it's not an API.

The TCA for me is an "API", even if its just an array. The Core API
documentation defines what keys and values are available.

> If we had a clean API within the tceforms
> the "pain" for extensions to get to the point and implement such wizards
> would not be so big, we would see more of them in the TER and it would
> be less problematic during updates etc.

You can have a wizard coming from an extension, provided by a userFunc,
isn't this the API already? I agree that it would be cool to have an PHP
interface for wizards which register themselves as wizards through a
wizard Manager class and TCEforms fetching them through a wizard Factory
object... But that's probably noone's "itch" right now. Maybe yours? ;)

> We're putting it in the Core to avoid that we've to think about a proper
> (generic) API for wizards and because we're Core members and we don't
> want to depend on anyone(anything else than the Core. I'm fine with that
> - as I said I won't block this since it's anyways relatively small
> compared to other stuff we put in. But my concern is that things like
> this just blow up the size of the Core which is in the end not good for
> anyone of us. And once it's in, we're not able to get rid of it later
> on, because people start to depend on it.

That's a good thing here. We won't get "rid" of it, and people *can*
depend on that. That's not bad. Imagine a TER extension where you don't
know if it will still be there 2 months from now (after for example a
security issue)?

> I'd personally prefer to have some kind of "feature" competition (e.g.
> compare extension downloads) before we push stuff into the Core.

You can argue about that with all features we add to the core. This is
an unrealistic way of getting things done. Would you work on some issue
just because the majority "voted" for it?

It's up to you (core developer) to decide what do you want to work on
and what you feel is missing (your "own itch"). If its a tiny
improvement, and you get through the review process with proper amount
of votes => its in. If its a major big feature, you most probably have a
team endorsed by the release team and will also get it in, if you finish
it in time.

I understand and I agree with you that at some point in time we should
try to outsource more and more "optional" components to external
extensions, but without any working concept ("A-class extensions",
"Incubation", "Core Extensions in TER" ...) around it, it cannot happen.

Cheers,
Ernesto