Child pages
  • [unit configs] Convert all unit config files from arrays to classes
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/7619c9df55557d86#

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. 

Related Tasks

INP-366 - Getting issue details... STATUS

9 Comments

  1. 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.

  2. 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.

  3. 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

    INP-366 - Getting issue details... STATUS


    DA.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.