Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Resource - Requirement Tool Component Proposal

Proposed Component Name Resource - Requirement Tool
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Resource - Requirement Tool
Proposers Thomas Weidner
Zend Liaison TBD
Revision 1.0 - 01 August 2010: Initial Draft (wiki revision: 5)

Table of Contents

1. Overview

The "Resource Requirements" tool or RRT is a tool for Zend Framework which checks the actual installation and helps the developer to see if there are missing extensions or ZF components.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will check the actual installation of PHP and it's extensions.
  • This component will not do installations or changes in the configuration.
  • This component will be available for different GUIs (commandline, web)

4. Dependencies on Other Framework Components

None

5. Theory of Operation

The RRT for Zend Framework is a tool which aids the developer or installer of Zend Framework to see which components work with the actual php settings and extensions.
There are multiple modes in which this tool can be used.

1.) command line
Using this tool on command line a user can detect if the framework or single components of the framework are working in the given php installation.
When there are problems the tool will return them and give a hint to see what is necessary.

2.) web
This tool should also be usable in a web-mode. In this mode it will check the installation and return the problems and display them in a nice visual way.

Optionally RRT can also be used to check if possible security configurations are met and return possible problems. For example is register_globals is turned off.

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: Proposal accepted
  • Milestone 3: Working implementation
  • Milestone 4: Unit tests
  • Milestone 5: Documentation
  • Milestone 6: Moved to core

7. Class Index

  • no classes to use... a single contained tool

8. Use Cases

UC-01

See if the whole framework works without problems

Returns a list of components and possible problems

UC-02

See if a single component works without problems

Returns

UC-03

Web-Mode

Returns a list of all components like UC1 but with a proper look

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

8 Comments

comments.show.hide

  1. Apr 25, 2010

    Benoît Durand

    <p>This is a great idea, I like it !</p>

    1. Apr 25, 2010

      Alexandr Iline

      <p>But maybe It will be better to make an official PEAR channel for this purposes?</p>

      1. Apr 25, 2010

        Wil Moore III (wilmoore)

        <p>I like the PEAR channel idea; however, would it not be wise to lower barrier to entry by making a tool that doesn't require the use of PEAR but do also build a PEAR channel that uses the base tool to build upon?</p>

  2. Jun 01, 2010

    Vincent de Lau

    <p>Good idea, I had a similar plan (and maybe some code already).</p>

    <p>What are you thinking in terms of dependencies and coding style? </p>

    <p>My initial plan was to create a single PHP file that will check:</p>
    <ul class="alternate">
    <li>php.ini settings</li>
    <li>Installed PHP modules</li>
    <li>Installed Apache modules (if running Apache)</li>
    <li>mod_rewrite configuration, although I'm not sure if this can be done properly</li>
    </ul>

    <p>In my opinion it should not be dependent on Zend Framework, but it should be a self contained, single file utility.</p>

    <p>I can imagine this single file being build from multiple source files.</p>

  3. Jun 02, 2010

    Thomas Weidner

    <p>I have not finished my proposal for now.<br />
    It is not abaddoned nor have I forgotten about it.</p>

    <p>So I would appreciate if my proposal is not changed without a small note to my person.</p>

    <p>There are some pre-requisits which I am actually collecting to get this proposal finished.</p>

    <p>I have no code for public for now.<br />
    The actual result can be seen within the requirements-tables from the manual.</p>

  4. Jul 31, 2010

    Marc Bennewitz (private)

    <p>What are your plans to keep the requirements table up-to-date?</p>
    <ul class="alternate">
    <li>I think there have to be only one file to change if some requirements has been updated.</li>
    <li>Can it automatically detected by annotations of component?</li>
    </ul>

    <p>Only a small note:<br />
    If we make ZF splitting into component packages we also need requirements of component to component.</p>

    1. Jul 31, 2010

      Thomas Weidner

      <p>As you can see by the reference tables in the manual component dependency is already done by me. It was the initial idea for this component.</p>

      <p>I don't think that it's a good idea to read file annotations from components to get the necessary information. As written the RRT will be self contained. This means that it should even work BEFORE ZF is installed to see which changes have to be made until ZF runs without problems. So it must have all informations independently from ZF.</p>

  5. Feb 05, 2011

    Dolf Schimmel (Freeaqingme)

    <p>Archiving this proposal, feel free to recover it when you want to work on it again. For more details see <a href="http://framework.zend.com/wiki/display/ZFDEV/Archiving+of+abandoned+proposals+(Feb+5+2011)">this email</a>.</p>