Merge pull request #50 from PyreStudios/break-mirrors

Break mirrors follow-up
PyreStudios · Oct 20, 2023 · 7c6e198 · 7c6e198
2 parents 6c5df15 + 0325591
commit 7c6e198
Show file tree

Hide file tree

Showing 14 changed files with 9 additions and 173 deletions.
diff --git a/bin/create.dart b/bin/create.dart
diff --git a/bin/new.dart b/bin/new.dart
@@ -1,7 +1,6 @@
 import 'dart:io';
 
 import 'package:bosun/bosun.dart';
-import './new_controller.dart';
 import 'new_middleware.dart';
 import 'new_view.dart';
 
@@ -80,11 +79,9 @@ var viewTemplate = '''<!DOCTYPE html>
 
 var appTemplate = '''
 import 'package:steward/steward.dart';
-import 'package:{{{name}}}/controllers/sample_controller.dart';
 
 Future main() async {
   var router = Router();
-  router.mount(SimpleController);
   router.get('/hello', (Request request) async {
     return Response.Ok('Hello World!');
   });
@@ -107,28 +104,13 @@ Future main() async {
 }
 ''';
 
-var controllerTemplate = '''import 'package:steward/steward.dart';
-import 'package:steward/controllers/route_utils.dart';
-
-class SimpleController extends Controller {
-  @Get('/home')
-  Response home(Request request) {
-    return view('main');
-  }
-}
-''';
-
 class NewCommand extends Command {
   NewCommand()
       : super(
             command: 'new',
             description: 'Create a new steward app',
             example: 'steward new <app-name>',
-            subcommands: [
-              NewControllerCommand(),
-              NewMiddlewareCommand(),
-              NewViewCommand()
-            ]);
+            subcommands: [NewMiddlewareCommand(), NewViewCommand()]);
 
   @override
   void run(List<String> args, Map<String, dynamic> flags) {
@@ -139,7 +121,6 @@ class NewCommand extends Command {
     var config = File('./$name/config.yml');
     config.writeAsStringSync(configTemplate);
     Directory('./$name/views').createSync();
-    Directory('./$name/lib/controllers').createSync();
     Directory('./$name/assets').createSync();
 
     // remove generated files from dart tool
@@ -149,8 +130,6 @@ class NewCommand extends Command {
     // write initial files
     File('$name/lib/main.dart')
         .writeAsStringSync(appTemplate.replaceAll('{{{name}}}', name));
-    File('$name/lib/controllers/sample_controller.dart')
-        .writeAsStringSync(controllerTemplate);
     File('$name/views/main.mustache').writeAsStringSync(viewTemplate);
     Directory.current = Directory('./$name');
 

diff --git a/bin/steward.exe b/bin/steward.exe
diff --git a/doc/site/docs/app/_category_.json b/doc/site/docs/app/_category_.json
@@ -1,4 +1,4 @@
 {
   "label": "App",
-  "position": 7
+  "position": 6
 }
diff --git a/doc/site/docs/app/views.md b/doc/site/docs/app/views.md
@@ -6,6 +6,8 @@ sidebar_position: 3
 
 The app is responsible for many things, but one important task that it accomplishes is registering the views for your application. 
 
+*Note: This documentation is out of date*
+
 Views live in the `/views` folder under your Steward app and are mustache files. Most interactions with Views will come from the `view` method on the controller class, but you're free to work with them on your own as well. That being said, we strongly encourage you to either use controllers or build an abstraction around this work. This behavior may change at a later date.
 
 When the app starts, it will scan the `/views` file directory and mount those items into the DI container.

diff --git a/doc/site/docs/app/what-is-the-app.md b/doc/site/docs/app/what-is-the-app.md
@@ -7,4 +7,4 @@ The App class takes care of tying up some odds and ends that many projects may w
 
 # Why would I use it?
 
-Like mentioned above, you don't _technically_ have to use the App. In fact, you can make a steward project that **just** uses the router and container, but this is not the recommended way to use steward unless you're building a very small API. Controllers can help structure your logic in a way that can better support code reuse and provide clear intent. The App provides support for registering your view files, reading values from a config, and much more. You're free to use either path when building your app and the plan is to support both, but I'd strongly recommend starting by using the App, especially if this is your first steward project.
+Like mentioned above, you don't _technically_ have to use the App. In fact, you can make a steward project that **just** uses the router and container, but this is not the recommended way to use steward unless you're building a very small API. The App provides support for registering your view files, reading values from a config, and much more. You're free to use either path when building your app and the plan is to support both, but I'd strongly recommend starting by using the App, especially if this is your first steward project.
diff --git a/doc/site/docs/cli/cli-commands.md b/doc/site/docs/cli/cli-commands.md
@@ -9,5 +9,5 @@ The steward CLI supports the following commands:
 
 The following commands are intended to be ran from within an existing steward application:
 
-- `steward new controller $controllerName` - creates a new controller for an existing steward application
+- `steward new view $viewName` - creates a new view template for an existing steward application
 - `steward doctor` - checks and validates the steward project in your current directory
diff --git a/doc/site/docs/container/what_is_a_container.md b/doc/site/docs/container/what_is_a_container.md
@@ -9,8 +9,6 @@ A container, in the Steward sense, is simply a box that things can be stored in
 # DI in a Nutshell
 Simply put, DI (Dependency Injection) is a technique in which an object recieves other objects that it depends on. There are typically three main names used to identify DI components. A "Client" is the object that dependencies are being provided to, an injected object is often (but not always) called a "Service", and finally the code that passes the Service into the Client is called an "Injector."
 
-In Steward, the Client is typically a Controller, the Injector is controlled by the framework, and the "Service" is whatever you want to define and inject (connection pools are a common example).
-
 The intent behind DI is to provide a separation of concerns when it comes to constructing objects.
 
 # Binding a "Service" to the DI Container

diff --git a/doc/site/docs/controllers/_category_.json b/doc/site/docs/controllers/_category_.json
diff --git a/doc/site/docs/controllers/how_to_use_controllers.md b/doc/site/docs/controllers/how_to_use_controllers.md
diff --git a/doc/site/docs/deploying/_category_.json b/doc/site/docs/deploying/_category_.json
@@ -1,5 +1,5 @@
 {
     "label": "Deploying a Steward App",
-    "position": 9
+    "position": 8
   }
 
diff --git a/doc/site/docs/forms/_category_.json b/doc/site/docs/forms/_category_.json
@@ -1,5 +1,5 @@
 {
     "label": "Forms",
-    "position": 8
+    "position": 7
   }
 
diff --git a/doc/site/docs/forms/forms.md b/doc/site/docs/forms/forms.md
@@ -43,8 +43,6 @@ class _SignUpForm extends Form {
 Of course, your sign up form may have different business logic associated with it and perhaps better validation, but the general shape of your form will match the one above. You'll take in some parameters to the form constructor and then call super, passing in a function to validate the form. That function will create a list of errors and return those errors. If no errors are returned, the form is assumed to be valid. 
 
 
-Using the form in the above example, we can set up a POST binding on our controller that uses our Sign Up form:
-
 ```dart
 @Post('/')
   Future<Response> signUp(Request request) async {

diff --git a/doc/site/docs/intro.md b/doc/site/docs/intro.md
@@ -13,7 +13,6 @@ Steward is comprised of five main parts.
 - The CLI
 - The Router
 - The Container
-- Controllers
 - The App
 
 You'll learn more about each of these in their own respective documentation.
@@ -24,8 +23,7 @@ The best examples for how to use Steward are captured in the test folder. Eventu
 
 Using the Steward framework gives you the following (but not limited to) benefits:
 
-- A modular system with light Dependency Injection, Routing, Controllers, and more.
-- Automatic dependency injection into controllers when mounting into routers.
+- A modular system with light Dependency Injection, Routing, and more.
 - Easy HTTP request/response management.
 - Config parsing into the DI container at application boot.
 - Templating via the Mustache template specification.