Issue with having too many files under Units/Sections in Custom module

8 views
Skip to first unread message

Dmitry Andrejev

unread,
Nov 28, 2010, 8:06:46 PM11/28/10
to In-Portal Development Team
Hi everyone,


We have recently came across the issue when in some projects we have too many PHP files in a single Units/Sections folder of Custom module.  As you might know this folder contains Extended classes which are used to override default functionality of  In-Portal. As a result it's getting very hard to quickly locate necessary files once you reach 20+ files in there, plus they all start with e_OriginalFileName.php

At this point, we should throughly discussion all options of making this simpler to work with. I ask everyone (including Intechnic employees) to participate in this critical decision making process.


For now we see 3 options here, but ready to look at other options too:

1. under Units/Sections we create a sub-folders for each corresponding Unit name (that are extending) and put replacement files inside (ie. /modules/custom/units/sections/orders/e_order_eh.php, now it is /modules/custom/units/sections/e_order_eh.php)

2. create sub-folders for each corresponding Units name (that are extending)  the same way as in #1, but on the level up (ie. /modules/custom/units/orders/e_order_eh.php)

3. do the same way as in #2, but re-create original module structure (ie. /modules/custom/units/in-commerce/orders/e_order_eh.php) similar to what we do with Replacement Templates now.


Again, the goal of this change is to quickly locate required file by folder tree and logically. Of course, these change will be backwards compatible.


Please speak up on what you like or don't like in the above, or propose new ideas!

--


Best regards,

Dmitry A.

Alexander Obuhovich

unread,
Nov 29, 2010, 2:13:01 AM11/29/10
to in-por...@googlegroups.com
In 2. and 3. approaches we need to create new simple unit config file (like in "custom/units/sections/sections_config.php"). This should be done to avoid class file path specifying during class extending.
--
Best Regards,

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

Dmitry Andrejev

unread,
Nov 29, 2010, 11:28:13 AM11/29/10
to in-por...@googlegroups.com
Hi everyone,


I have thought over over this again - I am for 1st option (/modules/custom/units/sections/[ORDERS]/e_order_eh.php), here is why:

1. We need to know which Units being replaced, the best way is to look for them in Custom/Units/Sections folder. In case if they are all together in custom/units folder - it's going to take an extra moment to recall which ones were replaced. This will save time.

2. We need to escape the need of adding Config files for these replacement classes - it's just additional work for no reason. I believe it's easy enough to specify additional folder in the path of class definition, plus we know that all replacements are defined in a single sections_config.php which good - single place to go. This will save time.

3. Even though it adds another folder level, but it's clearly better in terms of time spend locating the files in case of large customization projects.

4. I believe, no system changes will be required, plus it's 100% backwards compatible.


Let us know what you think!


DA.

Dmitry Andrejev

unread,
Dec 2, 2010, 4:52:34 PM12/2/10
to in-por...@googlegroups.com
Sad, but looks like Gleb, Erik, Nikita and other developers have nothing to add here...


Alex what do you think on my previous post? Makes sense to you?


-- 


Best regards,

Dmitry A.

Alexander Obuhovich

unread,
Dec 3, 2010, 2:26:00 AM12/3/10
to in-por...@googlegroups.com
It makes, sense. Let's try this approach one a new project, when we'll got one to see how it goes.

S.G.

unread,
Dec 3, 2010, 2:45:17 AM12/3/10
to In-Portal Development Team
I agree with you, Dmitry. 1st approach seems to be best of these 3.

Additionally, I suggest to rename "sections" folder under ALL modules,
respectively, also rename "sections_config.php" file. Word "sections"
reflects only one of several functions of this file & folder. I would
rename it to "module" folder and "module_config.php" file. It would be
more clear to people starting to use In-Portal, because folder & file
contain module-vice code & files.


On Nov 29, 6:28 pm, Dmitry Andrejev <dandre...@gmail.com> wrote:
> Hi everyone,
>
> I have thought over over this again - I am for 1st option (
> /modules/custom/units/sections/[ORDERS]/e_order_eh.php), here is why:
>
> 1. We need to know which Units being replaced, the best way is to look for
> them in Custom/Units/Sections folder. In case if they are all together in
> custom/units folder - it's going to take an extra moment to recall which
> ones were replaced. This will save time.
>
> 2. We need to escape the need of adding Config files for these replacement
> classes - it's just additional work for no reason. I believe it's easy
> enough to specify additional folder in the path of class definition, plus we
> know that all replacements are defined in a single sections_config.php which
> good - single place to go. This will save time.
>
> 3. Even though it adds another folder level, but it's clearly better in
> terms of time spend locating the files in case of large customization
> projects.
>
> 4. I believe, no system changes will be required, plus it's 100% backwards
> compatible.
>
> Let us know what you think!
>
> DA.
>
> On Mon, Nov 29, 2010 at 1:13 AM, Alexander Obuhovich <aik.b...@gmail.com>wrote:
>
>
>
> > In 2. and 3. approaches we need to create new simple unit config file (like
> > in "custom/units/sections/sections_config.php"). This should be done to
> > avoid class file path specifying during class extending.
>
> > On Mon, Nov 29, 2010 at 3:06 AM, Dmitry Andrejev <dandre...@gmail.com>wrote:
>
> >> Hi everyone,
>
> >> We have recently came across the issue when in some projects we have too
> >> many PHP files in a single Units/Sections folder of Custom module.  As you
> >> might know this folder contains Extended classes which are used to override
> >> default functionality of  In-Portal. As a result it's getting very hard to
> >> quickly locate necessary files once you reach 20+ files in there, plus they
> >> all start with e_OriginalFileName.php
>
> >> At this point, we should throughly discussion all options of making this
> >> simpler to work with. I ask everyone (including Intechnic employees) to
> >> participate in this critical decision making process.
>
> >> *
> >> *
> >> *For now we see 3 options here, but ready to look at other options too:*
>
> >> *1.* under Units/Sections we create a sub-folders for each corresponding
> >> Unit name (that are extending) and put replacement files inside (ie.
> >> /modules/custom/units/sections/orders/e_order_eh.php, now it
> >> is /modules/custom/units/sections/e_order_eh.php)
>
> >> *2.* create sub-folders for each corresponding Units name (that are
> >> extending)  the same way as in #1, but on the level up
> >> (ie. /modules/custom/units/orders/e_order_eh.php)
>
> >> *3.* do the same way as in #2, but re-create original module structure

Dmitry Andrejev

unread,
Dec 3, 2010, 11:35:42 AM12/3/10
to in-por...@googlegroups.com
Yes, I believe Sergey is right here.

I gave some some serious thoughts to this and see "module_config.php" telling us know then just "sections_config.php".

The only issue is that we have "modules" folder (Unit) in CORE which can add some confusion for new developers, plus they will be next to each other.


Alex, what are your thought on this?


DA

Alexander Obuhovich

unread,
Dec 3, 2010, 3:27:46 PM12/3/10
to in-por...@googlegroups.com
Since we use "section" term for naming 4 absolutely different aspects of In-Portal usage:
  • permission section
  • section (as category)
  • configuration section
  • tree section
then this won't create more mess, then we already have.

Dmitry Andrejev

unread,
Dec 3, 2010, 4:34:30 PM12/3/10
to in-por...@googlegroups.com
Ok, then we need to create a Task and Decide on Version for this change - 5.1.x or 5.2.0?


DA.

Alexander Obuhovich

unread,
Dec 4, 2010, 5:38:27 AM12/4/10
to in-por...@googlegroups.com
This just an approach. But, since we have some extended units in "custom" (Development Kit) module, then we can do it in 5.1.2 if you want.

Dmitry A.

unread,
Feb 19, 2011, 9:44:16 PM2/19/11
to in-por...@googlegroups.com
Okay, just wanted to see if we are up to doing this in 5.1.2 since it's heading our way soon!

Alex, other guys?


DA

Alexander Obuhovich

unread,
Feb 20, 2011, 6:33:11 AM2/20/11
to in-por...@googlegroups.com
No need to do it soon. It's just an idea even without implementation.

Dmitry A.

unread,
Feb 20, 2011, 1:53:21 PM2/20/11
to in-por...@googlegroups.com
Well, I would actually like to have it implemented into the Custom module for 5.1.2 if it's okay with you.


DA

Alexander Obuhovich

unread,
Feb 20, 2011, 1:55:27 PM2/20/11
to in-por...@googlegroups.com
Yes, you can do that.


On Sun, Feb 20, 2011 at 8:53 PM, Dmitry A. <dand...@gmail.com> wrote:
Well, I would actually like to have it implemented into the Custom module for 5.1.2 if it's okay with you.


DA



Dmitry A.

unread,
Feb 21, 2011, 4:10:10 PM2/21/11
to in-por...@googlegroups.com
Here is a task:

1007: Minimize number of Extended Units in Sections folder



DA

Dmitry A.

unread,
Feb 28, 2011, 2:34:29 PM2/28/11
to in-por...@googlegroups.com
This change has been committed into Custom Module 1.1.x branch and will be available starting Custom 1.1.2-RC1 and Custom 1.1.2 releases.

DA
Reply all
Reply to author
Forward
0 new messages