search

DMKEBUSINESSGMBH / typo3-mksearch

Generic highly adjustable and extendable search engine framework, using Zend Lucene, Apache Solr or ElasticSearch. But support for other search engines can be provided easily.
https://www.dmk-ebusiness.de
13 stars 20 forks source link

Move the old Pseudonamespaces to real namespaces #51

Open rengaw83 opened 5 years ago

rengaw83 commented 5 years ago

Rector does a lot of automated refactoring stuff.
There are already a PseudoNamespace To NamespaceRector we can try to use.

Baachi commented 5 years ago

I tried to refactor this with rector, but i run into some problems. If run this rector the namespace would be as followed tx\mksearch\engine\interface and not DMK\MKsearch\Engine\Interface.

So i tried to run the RenameNamespaceRector which doesn't have any change.

I try to create PR next week, so we have a good starting point.

fchaussin commented 4 years ago

Hi @Baachi , did you managed to refactor the Classes with Namspaces? I can help...

Baachi commented 4 years ago

Hey @fchaussin,

First of all, thanks for your interest and help! :+1:

I had two main problems regarding this issue. First of all the usage of the PseudoNamespaceToNamespaceRector and RenameNamespaceRector had some bugs that the resulting namespace wasn't that what I expected. As far as I remember the result was something like this tx\mksearch\engine\interface, which isn't valid in PHP, because interface is a keyword.

The second problem which is more complex is, that the current structure doesn't match with the current state of the art. So rename the namespace isn't enough. For example, this folder/namespace should be converted to DMK\MKSearch\Indexer and the corresponding interface should be moved to this namespace/folder, too.

And last but not least, we need to provide a class map for TYPO3, so we don't introduce a BC break.

All in all, not a big issue, but requires some time and effort.

fchaussin commented 4 years ago

Hey @fchaussin,

First of all, thanks for your interest and help! 👍

I had two main problems regarding this issue. First of all the usage of the PseudoNamespaceToNamespaceRector and RenameNamespaceRector had some bugs that the resulting namespace wasn't that what I expected. As far as I remember the result was something like this tx\mksearch\engine\interface, which isn't valid in PHP, because interface is a keyword.

The second problem which is more complex is, that the current structure doesn't match with the current state of the art. So rename the namespace isn't enough. For example, this folder/namespace should be converted to DMK\MKSearch\Indexer and the corresponding interface should be moved to this namespace/folder, too.

And last but not least, we need to provide a class map for TYPO3, so we don't introduce a BC break.

All in all, not a big issue, but requires some time and effort.

Yes that is what I encourted yesterday afternoon, it is a pretty long refactoring, and I will be only able to test the Elastic side. By the way, refactoring namespace is probably the starting point of following the new TYPO3 Extension conventions, and leaving RN_Base dependency. And maybe using PSR-14 based EventDispatcher instead of Hooks...

Baachi commented 4 years ago

@fchaussin There aren't any plans for v10 but I agree with you, that we can create a better library with all the new shiny features (EventDispatcher, Middleware, DependencyInjection) that come with the new TYPO3 release.

But the main selling point for this library (at least in our opinion) is the compatibility with at least the last two LTS releases (currently it is compatible with v6 - v9). And introduce these features would mean, that we create a completely new library, which requires a bunch of work and effort.

fchaussin commented 4 years ago

@fchaussin There aren't any plans for v10 but I agree with you, that we can create a better library with all the new shiny features (EventDispatcher, Middleware, DependencyInjection) that come with the new TYPO3 release.

But the main selling point for this library (at least in our opinion) is the compatibility with at least the last two LTS releases (currently it is compatible with v6 - v9). And introduce these features would mean, that we create a completely new library, which requires a bunch of work and effort.

I totally agree with you, the good way is to keep it work even with deprececiations. The refactoring is too large to guarantee backward compatibility without too much headache! Reusing the code in a brand new project with the new TYPO3 conventions should be a little easier.

neufeind commented 1 year ago

It would be really great to get this going. Since there are several things to redo besides namespaces imho a separate major-version without the aim to provide backward-compatibility (classmap, ...) might be our best bet. Other extensions had similar factorings where a migration-help (what changed, from what to what etc.) would help. I think that's viable for integrators moving to a new major version.

hannesbochmann commented 10 months ago

In the moment there are no plans to do further development of mksearch. So a refactoring to use namespaces won't happen right now. There will be no new features too, as long as nobody sponsors the development. But we will keep mksearch alive so there will be compatible versions for future TYPO3 versions.