Are there universal framework for actively using PHP OOP to parse, import and export tables?

We have for example a table word and is, for example, we have "noname" cms
I can write a script to deal with excel, and in accordance with what we see in the analysis, to perform various methods provided to us by "noname" cms. We will footcloth that nearly not necessary in order to quickly apply it, for example, another cms.
I wonder whether there are solutions where smart people have thought and invented such a thing, which offers a highly efficient organization of imports and exports, allows you to handle dependencies between tables, conversion, processing, etc. in Short do wonders. If you don't know about those decisions, we are interested in your opinion about this idea. What problems do you face constantly, and that in your opinion should decide such a framework. Thank you!
July 9th 19 at 13:42
4 answers
July 9th 19 at 13:44
We will footcloth that nearly not necessary in order to quickly apply it, for example, another cms.

Write a solution that will easily integrate into any CMS impossible. Usually write some kind of library for specific tasks, and then complement it with plugins that allows to integrate it in different CMS. Moreover, under each CMS its own plugin.

The library should not depend on the specific CMS, on the other hand when writing a library you can use anything. I would take PHPExcel, individual components from any of the popular framework (e.g. EventManager from ZF2). Would have written their own ORM, is tuned for working with Excel, based on the experience and architecture of the Doctrine. If you need to work not only with Excel, then implement additional adapters for different data sources.

Ready decisions for similar tasks are not met.
July 9th 19 at 13:46
The problem, actually, is not that different CMS.
The problem is that Excel is not data. It's just the table.
And in order to "work miracles" at the entrance still need to get the data.
So the only path that even leads somewhere is dropping the crutches and exclusion Eksele from the process technology in principle.
Until it's done - the foot bindings and a headache is inevitable.
I like the idea to exclude from the production of Excel, however, the question remains relevant, even for xml - Juana95 commented on July 9th 19 at 13:49
: well, I'm not that stupid to convert the table to a different format. And that the idea of the training data in the form of the stupid table without semantics is a dead end and inevitable overhead.

Need to fix the distance between the data collection and processing - this is it forces you to fence crutches. If these table will be initially filled in on the site and not in the office package and the problem disappears in principle. - chelsea13 commented on July 9th 19 at 13:52
: customers are not always teachable. They have that there, so you have to work with ( - Juana95 commented on July 9th 19 at 13:55
: Tell that to Yandex.Real estate, for example.
They did not have to fence the universal parser Eksele and PowerPoint.
As a result, their system remained sane, and flexible. - chelsea13 commented on July 9th 19 at 13:58
July 9th 19 at 13:48
This is not met.
What I would like:
1. To create a unified integration/migration "tires" on the basis of different types of data need to unify these data and easy creation of dependencies (data schema) based on unified data.
2. Also, need the ability to work with these data through the ORM (this "tire"), i.e. the ability to operate on information objects and flows).
3. Also should be configurable intervals to automatically collect information from sources.
4. System events/triggers, knows how to "pull" the external API (GET/POST etc.) in controlled events (for example, to signal one of the systems "bus" that came about her, you can begin to disassemble).
--------------------------------------------
Addon:
Manual import/export Excel:
https://dev.mysql.com/doc/mysql-for-excel/en/mysql...
https://sqlizer.io/
www.sqlmanager.net/ru/products/mysql/manager
Sorry, but your response is very far from my question. First, I pointed out to CMS (or even PHP) as an example is not just because data management and the organization of these data occurs at the level of CMS is a common practice, as far as I know. This allows you to not be tied to a specific database (as a minimum), to implement the necessary paradigm based on events in the system. Secondly, not a "how to put Exel", the challenge is a systematic approach to export and import. Or, please explain your answer, or I will not be able to accept it, because I do not understand how it related to the question. Thank you! - Juana95 commented on July 9th 19 at 13:51
: well I thought You were going to parse Excel. In General, the schema of the data is not done via PHP and through specialized visual tools. For example, EMS Mysql Manager: www.sqlmanager.net/ru/products/mysql/manager
If we are talking about automatic migration of data between different storage formats, then this algorithm is written using the ORM specific API for CMS system and creates a migration "bus", through which data are standardized within the entire infrastructure. - chelsea13 commented on July 9th 19 at 13:54
: updated the answer. - Juana95 commented on July 9th 19 at 13:57
: Yes, the design of the organization of data is not done via the CMS, I might just not accurately explained the idea, I was just mentioning ORM, in fact she has to work and the CMS if normal, direct requests do not have to do. Thanks for your updated response and showed interest in my question. - chelsea13 commented on July 9th 19 at 14:00
July 9th 19 at 13:50
I would have not implemented the tool for a cms, a self-contained service. Under the hood with all of the necessary tools for working with Excel and other formats you can produce not only the markup but also for example to upload the data to CMS on a dedicated API for a specific event/frequency, such as once a day.

Find more questions by tags CSVExcelPHPXML