Development Tips for bitrix-free fork of RosYam
When we opened the source code for RosYam, I was expecting one topic of public outrage - that we did it on Bitrix, and that now, in order to expand it, we need to buy this very same Bitrix. The second, less expected topic of public outrage is that the developers at Greensite use mercurial, not git. As I said, there are certain organizational difficulties with this. I will not take rubbish out of the hut and go into details, I’ll just clarify that sooner or later all these issues will be resolved, and everything will be nishtyak. Rosyama will have one official repository on github.com, from where the changes proposed by the community will go to the industrial server through the thorny path of every kind of testing and approval. Someday it will be.
And on the first point, about Bitrix, I will tell you in more detail. Rosyam is made as a Bitrix module, in addition, there are also Rosyamov components and a template. Moreover, RosYam is soldered to the Bitrix admin panel. In general, it is rather tightly integrated there, and, as I have already said, it will not be easy to uproot it from Beatrix in order to transfer it to any other platform. But probably. Anyone can do the bitrix-free fork of the project and try to transfer Russia to another platform. And face several difficulties.
The first difficulty is exactly the uprooting. Some of the functionality of RosYam is very tightly bound to Bitrix and will not work without it, these parts will have to be rewritten completely. The second difficulty is to merge changes from the main branch of the project and changes in the fork. Since some pieces of code will be rewritten, then perhaps some of the changes will be intolerable. Actually, for this reason, I could advise enthusiasts not to rush to rewrite RosRyam first, but to write an adapter that will emulate Beatrix, but in fact it will work with the interface of the chosen platform. Surely this adapter is still useful to someone. I would love to do whatever I can in the development - just call me.
The ROSEM module describes classes with static functions that provide an abstraction of the “pit” from the database almost everywhere (I say that because I’m not sure that any of us Greensite developers could resist the temptation and didn’t stick somewhere) mysql_query ()) is getting the list of holes, adding, deleting, and so on. There are also API functions. Everything related to changing the pit — update, change of status, deletion, and so on, is done via an internal API call. This is done in order to make corrections in one place. The internal API call is not implemented very well, but as a fucking backup of a leaning fence, but historically it happened. The functions described in the modules are called from the components. Inside components, the resulting data is slightly digested and uploaded to templates.
')
In order to ensure the normal functioning of the modules, you need to implement at least the dummy classes of $ DB objects (at least the Query, StartTransaction, Rollback, Commit, LastID) and $ USER functions (at least the Login, Logout, IsAdmin, Authorize, GetID, GetByID functions) ), a stub for CModule :: IncludeModule () and the function Fetch of an object that will return $ DB-> Query (). I say “at least” because I am not sure that I will not have to do anything else.
Components are more deeply integrated into Bitrix. It is better to completely rewrite the user profile component, taking as a basis something similar in meaning from the target platform, the remaining components - partially, but, in my opinion, not very much, but in some places. The public part is not so important, so you can redo it more (news, faq), but then you still have to implement your version of $ APPLICATION-> IncludeCompoment (). There will be no problems with the integration of the template, there is only a header, footer, a couple of scripts and css, and there should be no problems with the component templates, you just have to remember that Bitrix automatically connects the script.js and style.css files from the template folder component. Well, the admin panel (editing the list of holes) will have to be rewritten completely, if it is necessary at all - the administrator can delete the holes in batches directly from the public part.
Ugh, I almost forgot. The directories of the full names of traffic police chiefs and prosecution offices for subjects of the Russian Federation are stored in information blocks, which means that they will need to be transferred to another storage location, you can separate tables, fix the corresponding places in the code and redo the parsers that need to select relevant information from government websites and update directories .
It seems everything, nothing, it would seem, supernatural, however, in fact it is dofiga.
And on the first point, about Bitrix, I will tell you in more detail. Rosyam is made as a Bitrix module, in addition, there are also Rosyamov components and a template. Moreover, RosYam is soldered to the Bitrix admin panel. In general, it is rather tightly integrated there, and, as I have already said, it will not be easy to uproot it from Beatrix in order to transfer it to any other platform. But probably. Anyone can do the bitrix-free fork of the project and try to transfer Russia to another platform. And face several difficulties.
The first difficulty is exactly the uprooting. Some of the functionality of RosYam is very tightly bound to Bitrix and will not work without it, these parts will have to be rewritten completely. The second difficulty is to merge changes from the main branch of the project and changes in the fork. Since some pieces of code will be rewritten, then perhaps some of the changes will be intolerable. Actually, for this reason, I could advise enthusiasts not to rush to rewrite RosRyam first, but to write an adapter that will emulate Beatrix, but in fact it will work with the interface of the chosen platform. Surely this adapter is still useful to someone. I would love to do whatever I can in the development - just call me.
The ROSEM module describes classes with static functions that provide an abstraction of the “pit” from the database almost everywhere (I say that because I’m not sure that any of us Greensite developers could resist the temptation and didn’t stick somewhere) mysql_query ()) is getting the list of holes, adding, deleting, and so on. There are also API functions. Everything related to changing the pit — update, change of status, deletion, and so on, is done via an internal API call. This is done in order to make corrections in one place. The internal API call is not implemented very well, but as a fucking backup of a leaning fence, but historically it happened. The functions described in the modules are called from the components. Inside components, the resulting data is slightly digested and uploaded to templates.
')
In order to ensure the normal functioning of the modules, you need to implement at least the dummy classes of $ DB objects (at least the Query, StartTransaction, Rollback, Commit, LastID) and $ USER functions (at least the Login, Logout, IsAdmin, Authorize, GetID, GetByID functions) ), a stub for CModule :: IncludeModule () and the function Fetch of an object that will return $ DB-> Query (). I say “at least” because I am not sure that I will not have to do anything else.
Components are more deeply integrated into Bitrix. It is better to completely rewrite the user profile component, taking as a basis something similar in meaning from the target platform, the remaining components - partially, but, in my opinion, not very much, but in some places. The public part is not so important, so you can redo it more (news, faq), but then you still have to implement your version of $ APPLICATION-> IncludeCompoment (). There will be no problems with the integration of the template, there is only a header, footer, a couple of scripts and css, and there should be no problems with the component templates, you just have to remember that Bitrix automatically connects the script.js and style.css files from the template folder component. Well, the admin panel (editing the list of holes) will have to be rewritten completely, if it is necessary at all - the administrator can delete the holes in batches directly from the public part.
Ugh, I almost forgot. The directories of the full names of traffic police chiefs and prosecution offices for subjects of the Russian Federation are stored in information blocks, which means that they will need to be transferred to another storage location, you can separate tables, fix the corresponding places in the code and redo the parsers that need to select relevant information from government websites and update directories .
It seems everything, nothing, it would seem, supernatural, however, in fact it is dofiga.
Source: https://habr.com/ru/post/128221/
All Articles