Developing using cbUpdater

[Guido1982]

So far I've done some hacks that I need for a custom installation. Which is not the most preferred way of course. I want to get some better insight in how to do this while being able to keep up with the master branch development and still use cbupdater for my custom adjustments. Let me clarify by uding an example:

I've modified the calendar module because some specific needs were there, that the calendar module did not provide. For instance, I created an autocomplete that links calendar events to sales orders. This requires some database changes as well as some file changes. The database changes are quite straightforward I think:

• Create an XML file in the 'modules/cbupdater/cbupdates' folder that describes the update and the path to the update file.
• Create custom folder in the 'build' folder that holds the specific script (the XML file should point here).
• Following both steps would allow me to alter the database. But would it also allow me to alter files? Or maybe, rename an original file and replace it with one that being pulled in through an update server?
  

The problem with altering files apart from the master branch is that you cannot just update from the coreBOS master branch anymore. It will force you to fork the master branch. Then, you can merge the main upstream from coreBOS, and merge commits from your synced master branch into the altered branch (can you even do that)?

[joebordes]

The way we work here is more or less like this:

- we create a repository for all installs
- we start the repository by pulling in all commits from coreBOS, this links both projects together
- we aork on the new project and commit any specific project files (for example, it's changesets which are only for this project) to it's repository
- if we need to modify the base code two things can happen:

1.- the change is something that coreBOS should have or we can enhance coreBOS (global variable, corebos event, ....) so that this project can simply configure or add the functionality without changing base code. In this case we modify coreBOS (if needed), commi the change there and do a new pull into this project. We adapt accordingly.

2.- the change is really something specific to this project and enhancing coreBOS to support it really doesn't benefit anybody. In this case we simply make the change and commit it inside this project. That way we always have it documented and under code control. When we pull again from the base coreBOS, we will fix the conflicts manually.

So, look at it this way:

- if you need to modify base code: think about enhancing coreBOS so you won't have to change it again in the future. In fact it is an opportinity to make the applicationmore flexible.

- if you get a code conflict while doing a pull, it is an opportunity to learn something new about the application. Most probably something that you had hard coded can now be customized, take the opportunity to learn how and eliminate a dependency from your code

HTH

[Guido1982]

Hey Joe,

Yes. I thought about this some more and basically I would like to improve on the base code as much as possible. The changes we need are sometimes quite radical, but I've been thinking about implementing in such a way that it's intergrated into the core system and people can pick the options they need from the ones I add. Learning more and more about the app, (and yes, developing for it does help a lot and I will be coming here asking a lot as well) is a good thing. I've just synced my corebos fork with your master branch on github. I still have my 'updateCSS' and 'updateJS' branches that are needed for the theme I'm (still) creating. I'll create PR's for these when I have the time to finish the theme.

[joebordes]

Feel free to ask whatever you need.
The way I see it one of my tasks here is to give you the means to modify the application's behavior without having to modify the base code. Thus the effort we have put into workflows, events, global variables and, recently, bussiness mappings (which are incredibly powerful!).

http://corebos.org/documentation/doku.php?id=en:adminmanual:businessmappings

[Guido1982]

Business mapping seems to be a great step, reading the doc quickly I can see that it creates a large means of flexibility. I agree that the structure should be modular flexibility without hardcoding into the base code too much. One thing I am thinking about is changing the inventory module in such a way that a user can link entities to lines, and choose (in the settings) which relations should be available (or none, keeping the behaviour standard). I'd like to start a better discussion on this so we can maybe implement this into the product, scanning the business mapping I don't see how this could be done or am I judging too quickly here?

[joebordes]

You are judging too quickly. I have a Master-Detail mapping in progress.
Business mappings have changed the way I think about adapting the product :-)

[Guido1982]

Ah, great. I shall read the docs again (and again) to get a more firm understanding of what Business mapping does. I will start a separate thread on a different issue. Main focus here is I have an installation running in which I hacked quite a bit and am looking for a way to keep functionality I hacked in without making updates difficult. But I guess this is the main focus of the Business Mapping module.