• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 4.x Series
    • Feature
    • Utilize the VaultWiki Install System Elsewhere

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Utilize the VaultWiki Install System Elsewhere

    • Issue Tools
      • View Changes
    1. issueid=2526 November 10, 2011 4:46 AM
      pegasus pegasus is offline
      VaultWiki Team
      Utilize the VaultWiki Install System Elsewhere

      First, the install system should be made even more generic than it already is. Each step should be an array of sub-steps that we can apply a generic iterator to, and easily calculate the total sub-steps without having to code it manually.

      Also the system should be available outside the install/upgrade process for the core product --

      Specifically, it would be beneficial to use the Progress Indicator / Output when uploading XML files or using the Import/Export system. This is a second fundamental change to the install system and should be pushed back until Alpha 2 so we can get some other things tested publicly first.
    Issue Details
    Issue Number 2526
    Issue Type Feature
    Project VaultWiki 4.x Series
    Category Importing
    Status Implemented
    Priority 8 - Major Features / Enhancements
    Suggested Version 4.0.0 Alpha 1
    Implemented Version 4.0.0 Alpha 1
    Milestone VaultWiki 4 Alpha X
    Software DependencyAny
    License TypePaid
    Votes for this feature 1
    Votes against this feature 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. November 23, 2011 6:20 AM
      pegasus pegasus is offline
      VaultWiki Team
      Couldn't handle waiting for this. Working on this currently.

      Already made the changes to the Javascript for infinite levels of sub-steps which are now counted automatically as long as the version/step files are written correctly. The changes raise the PHP requirement to 5.3 since it requires using anonymous functions (even nested anonymous functions).

      The changes also assist in making upgrade scripts easier for developers to write and maintain, since the functions don't have to be named by step-number, and the functions don't need the step-number hard-coded any more.

      However, now I have to go back and make sure all the old upgrade scripts are properly updated. Unfortunately, there's no regular expression replacement that I would trust to make these rather fundamental changes.
      Reply Reply  
    2. November 23, 2011 5:30 PM
      pegasus pegasus is offline
      VaultWiki Team
      Finished updating the upgradepath folder to reflect the changes to the step format. Attempted manually for a while, then wrote a bunch of regular expressions and fixed the errors manually.

      On another note, good thing I decided not to wait on this. There were a number of bugs in the system and some version scripts as I converted them last year.

      Up next:
      • move the install/upgrade system into the MVC locations
      • make a generic progress indicator class
      Reply Reply  
    3. November 24, 2011 5:24 AM
      pegasus pegasus is offline
      VaultWiki Team
      Finished moving the install files into the appropriate MVC folders. The classes and calls all had to be renamed to fit the rest of the naming conventions, and vw_Hard_Core was updated to reflect the changes. Further, back-references were created between the phrases, views, controllers, and the various levels in order for each class to know the current progress. This fixed some issues with version tracking when the page refreshed and is better suited for CLI extension. There are still some issues where certain functions might be best moved for better MVC organization, and other functions should be proxied for CLI extension in the future.
      Reply Reply  
    4. November 24, 2011 6:28 AM
      pegasus pegasus is offline
      VaultWiki Team
      Just had a thought.

      Current the upgrade system works like this:
      1. Installer calls generic upgrade instance (upgrader).
      2. Upgrader finds the appropriate next version and initializes a version instance which extends the upgrader.
      3. The initialization of the version instance populates an internal this->steps array containing anonymous functions that do the work.
      4. The upgrader calls the step from the version instance, if the array key of the function in version->steps matches the requested step.

      A problem arises now when we want to extend the upgrader for CLI or something like that when we may have extended the upgrader already based on the dependency. Extending the CLI likewise would be inefficient in terms of code maintenance.

      But what if it worked like this:
      1. Installer calls generic upgrade instance (upgrader).
      2. Upgrader finds the appropriate next version and gets the needed steps from the version class via its own get_steps function.
      3. The upgrader calls the step from its own instance, if the array key of the function in this->steps matches the requested step.

      The difference is that the version instance does no work on its own, it just contains the function definitions. So it doesn't need to be an extension of the upgrade class. Also, we don't need to construct so many version instances. This also succeeds in keeping the current version and step information accessible because the work is done at the upgrade-instance level.

      It may not sound like much of a change but it requires a rewrite to a lot of things yet again, and it will result in both smoother functioning of the installer/upgrader and more straightforward code design than the existing implementation.

      For tomorrow.
      Reply Reply  
    5. November 24, 2011 4:45 PM
      pegasus pegasus is offline
      VaultWiki Team
      All steps moved to a separate steps class and sub-classes. Upgrader no longer calls itself recursively. This also allowed removing about 60 files whose only step was to update the current version (version is now handled separately from the steps).

      After dinner, now to somehow make the progress indicator its own generic class.
      Reply Reply  
    6. November 25, 2011 4:09 AM
      pegasus pegasus is offline
      VaultWiki Team
      Probably not perfect, but definitely enough to be usable again in the future. Closing this issue.
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 12:28 PM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.