That’s great that you’re trying to learn from a real world example, but
IMHO, I would start even simpler. Just create a hello world app and
play around with that until you understand MVC a bit more.
/app/controllers/first_controller.rb:
class FirstController < ActionController::Base
def helloworld @my_output = “Hello World!”
end
end
/app/views/first/helloworld.rhtml:
Message from controller: <%= @my_output %>
Start there, learn the core concepts, and your email application will
become much easier.
Get number of emails on server (easy using pop or imap .mails.size
Parse the header to get Subject, Date, and From (I figured out the
code to do this)
Put that in a class along with the message contents (pretty simple)
Display all that info line by line (I have that ready, looks ugly,
but works
I understand that ruby uses a MVC model, so I am supposed to put all
display logic in app/views, all code that receives actions from the
user in app/controllers, and the app/models directory would hold the
logic that brings this all together.
So the 4 steps above would probably need to placed in the app/models
directory and code in app/views will need to call it. If I want the
user to go to webserveraddress:3000/inbox, what would I need to call
the files I place in each subdirectory? Is there a command that takes
care of this for me?
Sorry for the very basic questions. Your help is appreciated.
So this is what I have been busy doing. Looks pretty ugly, but it
works.
I will add reply, forward and delete buttons once I figure out how to
obtain the message body itself. You can check it out at http://eldaly.com:3000/inbox
This is what I did so far:
rails mailclient
ruby script/generate controller Inbox index
create lib/email.rb (created an email class)
ruby script/generate controller View index
If I post the code here (and I would love to, to get feedback. I am
pretty sure there is some much better way of doing what I did and would
love to get some feedback) the post would be too long, is there an
alternative way, or is it OK to just go ahead an post the code?
Thank you very much for your responsiveness. That seems to be a design
decision, and I am not proficient in that yet. What decision would you
take to create a controller, or use an existing one? Also, where can I
post my code so that you and others can critique it?
Your time in answering all my questions is very much appreciated.
You probably don’t need a separate controller for view… just take
your index action from the view controller, put it in the inbox
controller, and rename it to the “view” action. Then you’ll access the
email like this: http://eldaly.com:3000/inbox/view/2
I am half-way through the
Agile book, and now would like to start learning using a different
example.
I would suggest that you finish going through the book before you start
working on another full-blown project. I stopped half-way through the
book to start coding my own project, and after going back to finish the
book, I wish I would of never stopped.
For what you’ve described, your entire app could consist of two
controllers:
application controller and inbox controller.
The inbox controller is where most of your business logic will reside
(processing users requests, manipulating models, etc.)
Just another opinion on this…
The way I see it, a Rails app would normally consist of:
one model for each type of information the app deals with
one controller for each thing the app does (inbox, view message,
compose message)
one view for each “page” or “type of screen” shown to the user (in
this case, maybe same three as mentioned for controller above, but not
always the case)
I think this is a great “first big project”. As for starting it before
you’re done reading, I don’t think you will ever be done reading. I’ve
read the Agile Rails book cover to cover a couple of times and feel like
I’m just starting to “get it”. Each time I go back and re-read a
section, I get something new out of it (besides just jogging my
middle-aged memory). Read early, read often – try to do it early,
start over often.
There is nothing like trying to do something to point out which parts of
the book you “didn’t quite get”.
I see many posts about this, but not too many answers. I stumbled upon
Ruby Mail which seemed like a good solution, but getting the body of
the message seems to be broken. There have been others that have also
reported this. Doen’t help when the code has not been updated in 2
years.
Thanks Ryan. I did just that and realized that the part I did not
continue with because I got tired of all the code had some very
important information.
A most excellent reply. Thank you very much. I agree that one is never
done reading. I skimmed through the parts I found most relevant to the
now, but know that I will need to go back when I will be stuck with
something that needs sessions for example.
The way I see it, a Rails app would normally consist of:
one model for each type of information the app deals with
one controller for each thing the app does (inbox, view message,
compose message)
Actually you generally want one controller per model, to perform all the
standard CRUD (Create, Read, Update, Delete) actions on one model.
Each controller should generally have 7 standard actions:
index (the list view)
show (view an existing item, no edit ability)
new (a form to create a new item)
create (the action the new form submits to, which actually creates
the
item - no view file)
edit (a form to update an existing item)
update (the action the edit form submits to, which actually updates
the
item - no view file)
destroy (the action which destroys an item and redirects to the list)
In your email app, you could have one Message model (doesn’t have to be
a
database model), and one Message controller. The seven standard actions
above apply. It doesn’t need to be any more complex than that in most
cases.
(As in, not 100%, but close to 95).
If you try to generally follow this convention throughout your Rails
apps,
things will be easier, and you’ll get a REST compliant API for free
(with
ActiveResource).
One more thing, you should really play with the “scaffold_resource”
generator to generate an example of the kind of code you should be
writing.
It’s not meant to be a crutch or something that’s just going to generate
your app for you, it’s a learning tool to use once or twice to
demonstrate
good patterns.
I proceeded to create to controllers inbox and message. Inbox just
displays a list of messages, and message can show, create, reply, reply
all, forward and delete. I think this falls well within what you were
saying above, as showing a message is different than showing a mailbox.
Also, I imagine the inbox controller will have other functionality such
as mark some messages for group operations (such as delete).
Thanks for the link.
Regards,
Ahmed
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
The MVC concept is