Bug #3395
rewrithe to use date2cal
| Status: | New | Start date: | 2009-05-20 | |
|---|---|---|---|---|
| Priority: | Should have | Due date: | ||
| Assignee: | - | % Done: | 0% |
|
| Category: | - | |||
| Target version: | - | |||
| Votes: | 0 |
Description
The exension should be rewrithen to use date2cal...
This way old extensions which use rlmp_dateselector don't have to be changed, but only one date extension has to be managed.
Associated revisions
[Bug 3395] Add a function for limiting the seminar bag to a certain age,r=oliver
History
Updated by Clemens Riccabona about 4 years ago
But date2cal should be moved to core (and i think there has been some discussion already), as it uses ux-classes (at least one afair), which is sometimes bad enough.
And while this is going on, won't it be great to have some updates for the old version of this extension?
Jonas, is this your way to tell me, that my reports/suggestions (which are all including a solution!) are completely unwanted and for that reason just ignored?
I use this extension NOW, in several other extensions.
I don't want to re-write my own extensions later, and nevertheless I want NOW some quality of code.
Updated by Stefan Galinski almost 5 years ago
Clemens Riccabona wrote:
But date2cal should be moved to core (and i think there has been some discussion already), as it uses ux-classes (at least one afair), which is sometimes bad enough.
Hi Clemens,
I just want to note that the XCLASS is only used in older TYPO3 versions.
--
Stefan
Updated by Clemens Riccabona almost 5 years ago
Nice to hear. I never used the date2cal API, as I never felt happy about adding dependencies to xclassing extensions .. ;)
2 Questions left on my side:
- What about the integration to core? Is this planned any longer?
- If yes, will it change the API?
Updated by Jonas Felix almost 5 years ago
Clemens Riccabona wrote:
2 Questions left on my side: - What about the integration to core? Is this planned any longer?
I don't know, but that would be best!
- If yes, will it change the API?
I don't know, but the best thing would be to support both APIs, the one for date2cal and the one for rlmp_dateselector.
Updated by Clemens Riccabona almost 5 years ago
Jonas Dübi wrote:
- If yes, will it change the API?
I don't know, but the best thing would be to support both APIs, the one for date2cal and the one for rlmp_dateselector.
My idea would have been, that the rlmp_dateselector should be re-written, that it uses date2cal in den background.
Something like an 'API-wrapper'.
Here my personal pro and cons:
pros:
- everyone can use the new rlmp_dateselector, without updating own extensions - high compat
- only one date extension has to be maintained.
cons:
- if api of date2cal changes, also rlmp_dateselector has to be changed.
- rlmp_dateselector then then depends on date2cal (and some extensions are depending on rlmp_dateselector, -> sounds a little bit like 'dll-hell' on win ... ;))