X-Cart forums

[totaltec]

I know this is the design webinar thread and I'm derailing it slightly: But in addition to prefixing our controller names, we also need to ensure we prefix our table names. I just realized that the table name is not automatically prefixed with the developer code. So that is another major way modules could conflict. Though most devs do this anyway...

[xim]

Originally Posted by totaltec

I know this is the design webinar thread and I'm derailing it slightly: But in addition to prefixing our controller names, we also need to ensure we prefix our table names. I just realized that the table name is not automatically prefixed with the developer code. So that is another major way modules could conflict. Though most devs do this anyway...

Yes, your right. If you want to be insure that your table will not overwrite by other modules you need to use your own prefix for new tables.

We will add it to our devs guide

[cflsystems]

Originally Posted by totaltec

I know this is the design webinar thread and I'm derailing it slightly: But in addition to prefixing our controller names, we also need to ensure we prefix our table names. I just realized that the table name is not automatically prefixed with the developer code. So that is another major way modules could conflict. Though most devs do this anyway...

I think most if not all are doing this. I do it, I know bcse, wcm do it for their mods...

[tony_sologubov]

Hi guys!

Thanks for coming to the latest webinar and for your questions.

1) About ability to overwrite the code of others through your own module.

As Carrie and Steve said above, it is all about proper coding style. X-Cart 5 allows to overwrite other module's code if you want to, but it also allows to keep the compatibility with them if you want to.

Ability to overwrite the other's code is very useful if you are a web-studio and writing a complete project. In this case, your goal is to implement the desired functionality to the client as fast as possible and you may want to force some code changes. Such ability helps with this goal.

If you are a module developer, your goal is to sell as many modules as possible and you achieve it through writing modules with rich functionality and making sure that your module does not break the store - i.e. it interacts well with other modules, otherwise nobody will use it. In this case, you want to be compatible with other modules and you should follow good code style and call parent::methodName()

Overall, X-Cart 5 serves the needs of web-studios and module developers by allowing both approaches.

2) Regarding module controllers.

Yes, Mike. At this moment, this is a problem and if there are two modules with the same controller names, one controller will be lost.

However, right now this is not a huge problem, because the number of 3rd party modules is not huge. When we start getting complaints and see that this problem becomes real, we will be able to implement needed changes within one minor release.

If you do care about this problem right now, you can name your controllers as MikeMyModuleMenu (i.e. add your dev ID and module ID right into the controller name) and it will actually solve the problem.

Surely, guys, let me know if you have any additional questions.

Tony.

[cflsystems]

Originally Posted by tony_sologubov

2) Regarding module controllers.

Yes, Mike. At this moment, this is a problem and if there are two modules with the same controller names, one controller will be lost.

However, right now this is not a huge problem, because the number of 3rd party modules is not huge. When we start getting complaints and see that this problem becomes real, we will be able to implement needed changes within one minor release.

Actually I think you should not wait until it becomes a "huge problem" but solve it before hand. When it becomes a problem and there is no solution to it you get angry devs and customers, bad words about XC, etc.
If there is a solution why not implement it right now before it gets out of hand? Why wait?

If you know there is a flow in the software you should fix it before it grows to a point when impacts stores in a negative way...

[tony_sologubov]

Originally Posted by cflsystems

Actually I think you should not wait until it becomes a "huge problem" but solve it before hand. When it becomes a problem and there is no solution to it you get angry devs and customers, bad words about XC, etc.
If there is a solution why not implement it right now before it gets out of hand? Why wait?

If you know there is a flow in the software you should fix it before it grows to a point when impacts stores in a negative way...

Well, we must make a decision in this case and this decision is between: a) implement something useful for everybody right now or b) implement something which is useful, but does not benefit anybody right now.

For instance, at this moment we are improving product attributes, import and installation process + working on responsive skin. We can start working on the controller problem, but import will be left with some crucial problems. So, choosing between import improvement or controller, we go for import improvement.

Do not worry, this controller problem is in our bug queue and it will be eventually fixed even if it does not become huge. However, if we feel that this problem becomes real pain, before we naturally come to it, we will simply increase its priority and ship a fix asap.