Re: Several notices about undefined constants during installation

[Alexander Obuhovich]

Ping

On Tue, Jul 20, 2010 at 1:28 PM, Alexander Obuhovich <aik....@gmail.com> wrote:

In-Portal installation is divided into several steps. Because of In-Portal is module-based, then each of the modules can have it's own specific installation php code. Each of In-Portal modules can have it's "constants.php", where module developers can define module-specific constants to be used throughout the module.

While In-Portal isn't completely installed, then unit config files of all modules are included, but not module "constants.php" files. This isn't a bad thing to to, but isn't a good one either. One side effect of this is that, when we are using module-specific constants in it's unit config files, then we will get php notices about each used constant, while module is being installed.

Unit config files of all not-yet installed modules are included because they can be used in module-specific "install.php" file. Since we don't know are they used or not, then we include them in any case.

File "constants.php" of each module are only included for installed modules and this raises such a problem. Because of such file contains a constant definition, then we can't include same file twice, so I propose, that we also include "constants.php" files from all modules during installation.

This is hard piece of knowledge to understand, since developers usually don't care about how installation system of In-Portal works until their module suddenly stops installing correctly :)

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Phil -- wbtc.fr --]

Should I understand this could also prevent any problem during update? If I've well understoud you, constant.php is present for installed modules, then how does it works when we do an update process, does it involves the sames files and install?

2010/7/23 Alexander Obuhovich <aik....@gmail.com>

--
You received this message because you are subscribed to the Google Groups "In-Portal Bugs Team" group.
To post to this group, send email to in-port...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-bug...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/in-portal-bugs?hl=en.

[Dmitry Andrejev]

Reviewed and agreed to include these constants on installation process too - I see no harm with this.

Let me know if we good to create task for this.

DA.

On Fri, Jul 23, 2010 at 2:04 PM, Alexander Obuhovich <aik....@gmail.com> wrote:

This doesn't break anything for now. This is just not good to have notices/warnings if we could prevent them from happening.

[Alexander Obuhovich]

Task: http://tracker.in-portal.org/view.php?id=846

[Dmitry Andrejev]

Please test the patch.

Note that I thought it's going to be more straight forward if we do include_once directly in install.php right before the Application object is created instead of hacking the way out to add more modules to ModulesInfo array which is handled inside of the Application itself.

DA

Best regards,

Dmitry A.

[Alexander Obuhovich]

Why you added duplicate code? Doesn't kApplication class do what we need in registerModuleConstants method?

Also how it could happen, that all units are accessed, but their constants are not loaded first?

[Dmitry Andrejev]

Hi Alex,

Well, it's not entirely a duplicate code. I have tried to explain the reason WHY I am not doing it (including the constants) with Application class. Yes, I saw that method in the App class, but believed it's going to be less mess if we going to add some additional logic related ONLY to the installation, but again I might wrong. If you feel so please care to explain what's wrong and suggest a better plan of action.

Also, this task describes (by you) why all units are scanned and constants are not loaded.

http://tracker.in-portal.org/view.php?id=846

DA