Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
C config
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1
    • Issues 1
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • aaha
  • config
  • Issues
  • #2

Closed
Open
Created Apr 12, 2017 by Aaron@aaron3Owner

Add support for nesting config directories.

Right now, files hierarchy is flat. This means individual files are large. We want to be able to break files into heirachies so that the following works:

Right now, a variable is accessed as "filename.arrayLevel1.arrayLevel2...", I'd like to change this so we can have folder1.folder2.file.arrayLevel1.arrayLevel2 etc.

Therefore, for a given variable: entities.seo.robots.archives.type.category, we can support any of the following:

File path: /entities.php

Contents of entities.php: [seo => ['robots' => [archives => ['type' => 'category' => 'something]]]]]

File path: /entities/seo.php

Contents of seo.php: ['robots' => [archives => ['type' => 'category' => 'something]]]]

File path: /entities/seo/robots.php

Contents of robots.php: [archives => ['type' => 'category' => 'something]]]

File path: /entities/seo/robots/archives.php

Contents of archives.php: ['type' => 'category' => 'something]]

Etc. All of these are exactly equivalent and abase/editorial should not care what format the developer uses. (THE DEVELOPER SHOULD USE THE MOST SIMPLE VERSION)

One special case, for a config like:

Variable call: ab_var('timelines.post_types')

FilePath: /timelines.php

Contents of timelines.php:

return [
    'post_types' => ['post', 'opinion'],
];

It can ALSO be structured as:

FilePath: /timelines/timelines.php

Contents of timelines.php:

return [
    'post_types' => ['post', 'opinion'],
];

This is to allow making nesting simple when we have general options and more specific ones:

For example, we might have:

  • ab_var('entities.seo.robots.archives.type.category');
  • ab_var('entities.seo.keywords.archives.type.category');
  • ab_var('entities.seo.titles.archives.type.category');

Where it makes sense to have the following directory structure:

- entities
     - seo
           - robots.php
           - keywords.php
           - titles.php

However, we may need: ab_var('entities.enabled'); ab_var('entities.seo.enabled');, ab_var('entities.seo.strict'); we do not want to have to create enabled.php, and strict.php for simple bool values, so we can do:

- entities
     - entities.php
     - seo
           - seo.php
           - robots.php
           - keywords.php
           - titles.php

Where entities.php is only:

['enabled' => true]

and seo.php is only:

['enabled' => true, 'strict' => true]

Deeper nesting always overrides!

if entities.php has

['enabled' => true, 'seo' => ['enabled' => false, 'strict' => false]]

it is overridden by seo/seo.php

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking