== Server Programming === Including New Rack Middleware Additional methods can be added as part of the core Helix Web Services server. Adding new HTTP methods to the API should probably be done in a module specific to your extension, which forms a kind of namespace. By convention, we create a `MyModule::App` class that inherits from `Sinatra::Base`, to define the API to your module. Also, by convention, we prefix methods to your module with a simple string path, e.g., `my_module`. Say we want the ability to fetch "stuff" from your module. You would create a Sinatra modular app in a `my_module/app.rb` file: [source,ruby] .my_module/app.rb ---- module MyModule class App < Sinatra::Base get '/my_module/v1/stuff` # We use p4, so make sure you have a p4 connection available require_p4 # If there's a problem, we'll actually handle exceptions for you results = env['p4'].run_print('-o', '//depot/stuff') # Right now, we only produce JSON. results.to_json end end end ---- Typically, you'd reference this in a `my_module.rb` file, which imports your App, and possibly defines helper methods in your namespace. [source,ruby] .my_module.rb ---- require 'my_module/app' module MyModule def helper_method # do something end end ---- The final step is to include your modular app in the top level `HelixWebServices` application. [source,ruby] .helix_web_services.rb ---- # ... truncated other things require 'my_module' module HelixWebServices class Master < Sinatra::Base # ... lots of things are truncated register_app(MyModule::App) end end ---- === Registering Configuration Variables If your application requires new configuration, you should: 1. Declare your variables in `hws_settings.rb` 2. Document your variables in `doc/03_configuration.asc` If you follow these steps, your configuration variables will be a part of the `env['hws_settings']` hashes available to each Sinatra method. [[project_extensions]] === Adding Project Extensions A project extension is a combination of JSON metadata and logic that can be used for product-specific integrations, or optional features. Creating a project extension involves the following tasks: 1. Define the JSON extension, typically by documenting it 2. Assign a simple extension ID and versioned MIME-style content type. 3. Implement logic and assign to callbacks of the link:./helix_web_services/Projects/ProjectService.html[ProjectService] class Your extension should probably append handlers to the following methods: - link:./helix_web_services/Projects/ProjectService.html#append_to_list-class_method[Projects::ProjectService.append_to_list] - link:./helix_web_services/Projects/ProjectService.html#fetch_project-class_method[Projects::ProjectService.fetch_project]
# | Change | User | Description | Committed | |
---|---|---|---|---|---|
#1 | 15741 | ptomiak | Branch HWS for my use. | ||
//guest/perforce_software/helix-web-services/main/source/doc/07_serverprog.asc | |||||
#1 | 15622 | tjuricek |
Move source code to 'source/' subdirectory of branch. build/ will remain where it is. |
||
//guest/perforce_software/helix-web-services/main/doc/07_serverprog.asc | |||||
#4 | 15099 | tjuricek | Revise project services to be our simple 'container' for other systems. | ||
#3 | 15098 | tjuricek |
Revised project services to GET-only forms. With Helix Sync revising to integrate purely with Helix Cloud, this is the only thing we can reasonably define. |
||
#2 | 15090 | tjuricek |
Update _proposed_ API for project services. This is *very likely* to change, and will not be implemented until reviewed. |
||
#1 | 15038 | tjuricek | Document 'login' auth method and client programming overview. | ||
//guest/perforce_software/helix-web-services/main/doc/06_serverprog.asc | |||||
#1 | 15032 | tjuricek |
Starting config and doc revisions. System is now broken while revisions underway. Configuration of the p4d connection is now done via a single HWSSettings middleware object injected into the Rack env. The HWSP4Cleanup middleware now cleans up any p4 injected into the Rack env. The Auth::App class now mostly just contains one method to generate a p4 ticket. /auth/v1/login. Added yard documentation for the main project. Yard docs have been reconfigured to dump into build/ directories. This should probably be done with each release. Hm... The top level rake file contains a task, 'all:doc', to update our documentation. This should probably be run for each checkin. Hm... Specs are now using Rack::Test on top of a 'live' p4d. I'd suggest you still use the p4util mechanism, which now dumps to a /tmp folder, so we can safely add P4IGNORE rules back into your local .p4config file. Old 'perforce' application now called 'helix_versioning_engine'. Removing cache data. Helix Sync may be slow. It may also get axed. We'll see. |