Added by Ralph Schindler, last edited by Ralph Schindler on Jul 16, 2008

Labels

 
(None)
Requirement Practical Use Case
Ability to issue "tooling system" requests via the command line to
facilitate:
  • rapid application development of php based applications
  • jump starting application structures with include the creation
    and alteration of
  • directories
  • files (classes, html, view scripts, etc.)
  • database schemas
  • config files
  • xml files
  • wsdl generation
  • etc.
  
Ability of the "tooling system" to describe its full set of capabilities from the command line "zf show help" or "zf --help"
Ability to issue "tooling system" requests from multiple clients to interact with this "tooling system"
  • Zend Studio
  • Command Line
  • Other IDE (example: textmate via perhaps XML-RPC)
  
Ability to extend the "tooling system" as simply as creating a php class.
, done
Ability to attach metadata to "tooling capabilities (provider)" and/or arbitrary "tooling" data to the system This is a crucial one. And, I am not sure I can simplify it any further, but let me give you the for-instance.
.
When talking about some capability of this tooling system, it should be known that it is called by some name. In code, you might have a "class CustomAuthProvider {}". This provider provides the "custom authentication" related tasks/capabilities to the tooling system. The system will actually infer that this system capability is called "CustomAuth" from the class name itself. (Lets not bog down in what this provider actually does, only that it exists.)
.
SO - considering that, there needs to be a way for the command line environment to get the name of this provider in a way which is consistent to what is generally accepted in the command line environment. That said, the CLI part of the tooling system will create "metadata" for this capability that makes it readable in the CLI environment (lowercase-dashed instead of CamelCased). This means that when you are referring to it from the command line, you might use "custom-auth" instead of "CustomAuth", thus a more consistent experience.
.
That's a pretty gross simplification of the idea, but lets take it a step further. The Zend Studio guys create a set of icons for all of the tooling providers that make sense for Zend Studio to support. This icons would be accessible (via the tooling system) to other IDE's to utilize (if they so wish), and can be found inside the registry of metadata that has been built. Its even conceivable that these icons end up on a web interface to this tooling system.
Ability for this "tooling system" to be bootstrapped automatically by detecting "capabilities" inside the php include-path.  
Ability to customize and use a "project profiling" system to facilitate:
  • defining project structures to be used in rapid application
    development
  • ability to serialize a "live" project profile inside a project
  • ability to keep project "artifacts" and the project profile in
    synchronization
  
Ability to construct php based files, classes, methods, properties via an OO interface  
Ability to deconstruct and alter the contents of existing PHP files and classes