September 12, 2011 at 01:54Tips for developing a bitrix-free fork of RosYama
When we opened the sources of RosYama, I expected one topic of public indignation - that we did it on Bitrix, and now, in order to deploy RosYama at home, we need to buy this very Bitrix. A second, less anticipated topic of public outrage is that developers at Greensight use mercurial rather than git. As I said, there are certain organizational difficulties with this. I will not take the dirty linen out of the hut and go into details, I will 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, through the thorny path of all kinds of testing and approval, will go to the industrial server. Someday it will be so.
And on the first point, about Bitrix, I will tell you in more detail. RosYama is made as a Bitrix module, in addition, there are also Rosyamov components and a template. Moreover, RosYama is soldered to the Bitrix admin panel as well. In general, it is quite tightly integrated there, and, as I already said, uprooting it from Bitrix in order to transfer it to some other platform will not be easy. But probably. Anyone can make a Bitrix-free fork of the project and try to transfer RosYama to another platform. And run into several difficulties.
The first difficulty is uprooting. Some of the functionality of RosYama is very tightly attached to Bitrix and will not work without it, these parts will have to be completely rewritten. 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, it is possible that some of the changes will be intolerable. Actually, for this reason, I could advise enthusiasts not to rush to rewrite RosYama first, but to write some kind of adapter that will emulate Bitrix, but in fact will work with the interface of the selected platform. Surely this adapter is useful to someone else. I would gladly render all possible assistance in the development - just call me.
The RosYama module describes classes with static functions that provide abstraction of the “hole” from the database almost everywhere (I say this because I’m not sure that any of us, Greensight developers, could resist the temptation and did not stick a call somewhere mysql_query ()) is getting a list of pits, adding, removing, and so on. There are also API functions. Everything related to the pit change - update, status change, deletion, and so on, is done through an internal API call. This is done so that it was necessary to make corrections in one place. The internal API call was implemented not very high quality, but as a fucking pillar of a rickety fence, but it happened historically. The functions described in the modules are called from the components. Inside the components, the data obtained is slightly digested and uploaded to the templates.
In order to ensure the normal functioning of the modules, it will be necessary to implement at least fake classes of $ DB objects (at least Query, StartTransaction, Rollback, Commit, LastID functions) and $ USER (at least Login, Logout, IsAdmin, Authorize, GetID, GetByID functions ), a stub for CModule :: IncludeModule () and a Fetch function for the object that will return $ DB-> Query (). I say “at least” because I’m not sure that I won’t have to do anything else.
Components are more deeply integrated into Bitrix. It is better to completely rewrite the component of the user profile, taking as a basis something similar in meaning from the target platform, the remaining components are partially, but, in my opinion, not very strong, but in some places. The public part is not so important, so you can redo it more strongly (news, faq), but here 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, there should also be no problems with component templates, just remember that Bitrix automatically connects script.js and style.css files from the template folder component. Well, the admin panel (editing the list of holes) will have to be completely rewritten,
Ugh, I almost forgot. Directories of the name of the chief of the traffic police and prosecutor's offices for the constituent entities of the Russian Federation are stored in information blocks, which means that it will still be necessary to transfer them to another storage location, you can add them to separate tables, correct the corresponding places in the code and redo the parsers, which must select the appropriate information from the websites of government agencies and update directories .
Everything seems to be, nothing seemingly supernatural, however, in fact this is dofiga.
And on the first point, about Bitrix, I will tell you in more detail. RosYama is made as a Bitrix module, in addition, there are also Rosyamov components and a template. Moreover, RosYama is soldered to the Bitrix admin panel as well. In general, it is quite tightly integrated there, and, as I already said, uprooting it from Bitrix in order to transfer it to some other platform will not be easy. But probably. Anyone can make a Bitrix-free fork of the project and try to transfer RosYama to another platform. And run into several difficulties.
The first difficulty is uprooting. Some of the functionality of RosYama is very tightly attached to Bitrix and will not work without it, these parts will have to be completely rewritten. 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, it is possible that some of the changes will be intolerable. Actually, for this reason, I could advise enthusiasts not to rush to rewrite RosYama first, but to write some kind of adapter that will emulate Bitrix, but in fact will work with the interface of the selected platform. Surely this adapter is useful to someone else. I would gladly render all possible assistance in the development - just call me.
The RosYama module describes classes with static functions that provide abstraction of the “hole” from the database almost everywhere (I say this because I’m not sure that any of us, Greensight developers, could resist the temptation and did not stick a call somewhere mysql_query ()) is getting a list of pits, adding, removing, and so on. There are also API functions. Everything related to the pit change - update, status change, deletion, and so on, is done through an internal API call. This is done so that it was necessary to make corrections in one place. The internal API call was implemented not very high quality, but as a fucking pillar of a rickety fence, but it happened historically. The functions described in the modules are called from the components. Inside the components, the data obtained is slightly digested and uploaded to the templates.
In order to ensure the normal functioning of the modules, it will be necessary to implement at least fake classes of $ DB objects (at least Query, StartTransaction, Rollback, Commit, LastID functions) and $ USER (at least Login, Logout, IsAdmin, Authorize, GetID, GetByID functions ), a stub for CModule :: IncludeModule () and a Fetch function for the object that will return $ DB-> Query (). I say “at least” because I’m not sure that I won’t have to do anything else.
Components are more deeply integrated into Bitrix. It is better to completely rewrite the component of the user profile, taking as a basis something similar in meaning from the target platform, the remaining components are partially, but, in my opinion, not very strong, but in some places. The public part is not so important, so you can redo it more strongly (news, faq), but here 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, there should also be no problems with component templates, just remember that Bitrix automatically connects script.js and style.css files from the template folder component. Well, the admin panel (editing the list of holes) will have to be completely rewritten,
Ugh, I almost forgot. Directories of the name of the chief of the traffic police and prosecutor's offices for the constituent entities of the Russian Federation are stored in information blocks, which means that it will still be necessary to transfer them to another storage location, you can add them to separate tables, correct the corresponding places in the code and redo the parsers, which must select the appropriate information from the websites of government agencies and update directories .
Everything seems to be, nothing seemingly supernatural, however, in fact this is dofiga.