aboutsummaryrefslogtreecommitdiffstats
path: root/railties/guides
diff options
context:
space:
mode:
authorRyan Bigg <radarlistener@gmail.com>2011-10-16 09:53:26 +1100
committerRyan Bigg <radarlistener@gmail.com>2011-10-16 20:17:53 +1100
commit434148024d742ec50662bf72c5cbb8e5664985e5 (patch)
treec71cf80453348150ad4a2d909edec079fcd1bd66 /railties/guides
parent0f87cc1486e2b7f95fff69ead9e6c74344c89496 (diff)
downloadrails-434148024d742ec50662bf72c5cbb8e5664985e5.tar.gz
rails-434148024d742ec50662bf72c5cbb8e5664985e5.tar.bz2
rails-434148024d742ec50662bf72c5cbb8e5664985e5.zip
[engines guide] beginning to cover using application's classes
Diffstat (limited to 'railties/guides')
-rw-r--r--railties/guides/source/engines.textile24
1 files changed, 23 insertions, 1 deletions
diff --git a/railties/guides/source/engines.textile b/railties/guides/source/engines.textile
index 8d5c231124..9cdca25329 100644
--- a/railties/guides/source/engines.textile
+++ b/railties/guides/source/engines.textile
@@ -404,7 +404,29 @@ The first timestamp (+\[timestamp_1\]+) will be the current time and the second
To run these migrations within the context of the application, simply run +rake db:migrate+. When accessing the engine through +http://localhost:3000/blog+, the posts will be empty. This is because the table created inside the application is different from the one created within the engine. Go ahead, play around with the newly mounted engine. You'll find that it's the same as when it was only an engine.
-TODO: Application will provide a User foundation class which the engine hooks into through a configuration setting, configurable in the application's initializers. The engine will be mounted at the +/blog+ path in the application.
+h4. Using an application's classes
+
+When an engine is created, it may want to use specific classes from an application to provide links between the pieces of the engine and the pieces of the application. In the case of the +blorgh+ engine, making posts and comments have authors would make a lot of sense.
+
+Usually, an application would have a +User+ class that would provide the objects that would represent the posts' and comments' authors, but there could be a case where the application calls this class something different, such as +Person+. It's because of this reason that the engine should not hardcode the associations to be exactly for a +User+ class, but should allow for some flexibility around what the class is called.
+
+To keep it simple in this case, the application will have a class called +User+ which will represent the users of the application. It can be generated using this command:
+
+<shell>
+rails g model user name:string
+</shell>
+
+Also to keep it simple, the posts form will have a new text field called +author+ where users can elect to put their name. The engine will then take this name and create a new +User+ object from it or find one that already has that name, and then associate the post with it.
+
+First, the +author+ text field needs to be added to the +app/views/blorgh/posts/_form.html.erb+ partial inside the engine. This can be added above the +title+ field with this code:
+
+<erb>
+<div class="field">
+ <%= f.label :author %><br />
+ <%= f.text_field :author %>
+</div>
+</erb>
+
h3. Overriding engine functionality