Convert all unit config files from arrays to classes

[Alexander Obuhovich]

I think, that we should convert all unit configs from array to classes form. This will give us such immediate benefits:

• all common unit config settings, that are copied from one unit config to another will be located in parent class (saves space);
• all unit config setting names will be automatically suggested by Zend, and this will eliminate most of setting name typing errors;
• we will have a list of all possible unit config settings with their description, purpose and usage examples.

We should create base class for unit configs where all mentioned above. I think, that all unit configs (system and user-made) should be named the same way and need to use some prefix (along with suffix as usual), that will prevent them from appearing in class-name auto-complete dialogs at least user really wants them to be there.

Unit config class name could be formed by coding standards using prefix-name, declared in this config. For example "ucUserConfig" (for prefix "user"), "ucAgentConfig" (for prefix "agent"), "ucCustomSection" (for prefix "custom-section") and so on.

--
Best Regards,

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

[Dmitry A.]

I think this is interesting idea, but I am a bit concerned about the
Memory and Performance lose if we do this.

How about we file a task for this as Feature Request and would start
with research and tests before we solidly move forward?


Cheers!


DA.

On Dec 5, 9:29 am, Alexander Obuhovich <aik.b...@gmail.com> wrote:
> I think, that we should convert all unit configs from array to classes form.
> This will give us such immediate benefits:
>

>    - all common unit config settings, that are copied from one unit config

>    to another will be located in parent class (saves space);

>    - all unit config setting names will be automatically suggested by Zend,

>    and this will eliminate most of setting name typing errors;

>    - we will have a list of all possible unit config settings with their

[Alexander Obuhovich]

Task is good, but I doesn't know how to test performance loss without implementing my proposal. Because how we gonna know how slow this thing will be if we won't implement it for all code. This is like you've placed "die" statements in all files in case if they are executed directly.

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

--

You received this message because you are subscribed to the Google Groups "In-Portal Development" group.
To post to this group, send email to in-por...@googlegroups.com.
To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

[Dmitry A.]

Well, I mean to say before we convert ALL Unit Configs we probably
should do a couple and compare. Tests can be done with Zend Profiler.


New task has been filed for this:


441: Converting "Unit Config" files from Arrays to Classes

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


DA.

> > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsu...@googlegroups.com>
> > .

[Dmitry A.]

Just a quick note here.

I have recently ran a Profiler on one of the pages and noticed number
of times GetUnitOptions method is called and especially time share it
took from the whole script execution - a lot.

We definitely can improve here!


DA.

> > > in-portal-de...@googlegroups.com<in-portal-dev%2Bunsubscribe@goog­legroups.com>

[Alexander Obuhovich]

This looks like related to discussion, where OnAfterConfigRead was called multiple times for same prefix during script run. Also GetUnitOptions is not so popular method, because it returns a lot of stuff and it's used mostly during mod-rewrite url parsing to get two options from unit config at once. By my opinion I that code should be replaced with two getUnitOption calls instead. Maybe you've got on big server load and this affected the results or there was a big unit config cache rebuild, but that guy doesn't use GetUnitOptions at all.

To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

[Dmitry A.]

Actually I meant to say GetUnitOption instead.

I think if we have all prefix data SET as Class Properties and get rid
of tons of GetUnitOption call this would save is execution time.

DA.

[Alexander Obuhovich]

This might not work, because getUnitOption accesses unit config option by it's prefix, like "u" (user), "c" (category) and so on, but it can't guess unit config containing file and proper class name without unit config reader class. So we need to class something. Unit config class will converted to array anyway, for easier access for unit config reader itself. All idea about storing unit configs in classes doesn't provide any benefits, except of easier defining of that unit configs. Whole unit config processing code will not benefit for it, at least I don't know how exactly for now.

To unsubscribe from this group, send email to in-portal-de...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/in-portal-dev?hl=en.

[Dmitry Andrejev]

Then we should list our Goals here and start thinking and discussion hard:

1. Better access to Preifx properties

2. Speed improvements

3. Compatibility with Unit Config Builder in the future?

I doubt it's worth to rich goal 1 and skip other 2.

DA.

[Alexander Obuhovich]

For 1 point we could document all unit config properties and place wiki link to that article in each unit config file. This is at least something for developers, who are not familiar with unit configs at all. Speed in unit configs is directly proportional to unit confg count, because each unit config is located in separate file and dependent on template complexity we need to include at least one unit config file for each prefix and this is slow. We could totally cache all unit configs in database and perform one query per each unit config, but this is no good in any case. Memcaching all unit configs should theoretically create performance improvement.