Valentino Lun wrote:

 > In the MVC architecture framework, the Model is actually communicate
 > with database. In my rails project, there is a model/ssh.rb that is not
 > connect with database. Is it a good practice for this arrangement in my
 > project? Am I violate the rules of MVC architecture? Or is it better to
 > move all the codes from models to controllers? What do you think? Thank
 > you.

MVC has two meanings. The most important meaning is a set of Guidelines (_not_ 
"Rules") for where to put what logic. For example, if you put HTML code in the 
Controller or Model, you had better be prepared to answer why.

MVC's other meaning is the answer to these questions for most GUIs:

  1. do all your tests pass?
  2. is your code simple and easy to read?
  3. are you as DRY as possible without violating 2 (or 1)?
  4. is your code minimal, without run-on modules?

The game is to apply each item, in order, while not breaking the previous 
items. 
Don't DRY your code (meaning Don't Repeat Yourself) if you break tests, or make 
your code unreadable. Don't remove lines of code if tests break? (That is 
"refactoring".)

The ideal of MVC is that a good design that follows those guidelines ought to 
automatically fall out as three layers, with the data accessors in one layer; 
the "switchboard operators" in another layer, plugging everything together, and 
the views in another layer, stretching it all out for the users. So, in theory, 
if you apply those Simplicity Guidelines an MVC pattern ought to emerge for you.

Put anything you like in the models folder, so long as it's something that 
controllers mix and match together.

 > models/ssh.rb
 > $LOADED_FEATURES[$LOADED_FEATURES.length] =
 > 'net/ssh/authentication/pageant.rb'
 > require 'net/ssh'
 >
 > class Ssh
 >
 >   def self.execute(cmd)
 >     ssh=Net::SSH.start("ahnibm71", "testlib", :port => 19207, :paranoid
 > => false, :auth_methods => ["publickey"], :passphrase => "hellokitty",
 > :keys => ["C:/testing/id_rsa"])
 >     output = ssh.exec!(cmd)
 >     ssh.close
 >     if output.nil?
 >       return "NULL"
 >     else
 >       return output.gsub("\n", "<br>")

Firstly, this mixes HTML and Model. That <br> is not DRY, because it repeats 
the 
concept of a view down here. Remove that gsub, and render your output like this:

  <pre><%=h output %></pre>

Nextly, all your code should be pure XHTML (google assert_xpath for more on 
this 
subject!), so you should have used <br/>. XHTML makes your pages super-easy to 
test, and this, in turn, keeps your code quality extremely high. Lack of tests 
is a much, much bigger problem than any variations in MVC ideals!

 >     end
 >   end
 >
 > end
 >
 > controllers/ssh_controller.rb
 > class SshController < ApplicationController

Does this control SSHs? What is the concept on the SSH wire that's so 
important? 
Is this a "RemoteCommandController"?

 >   def main

If you have a main.html.erb file, and if it takes care of itself, you don't 
need 
this action in here.

 >   end
 >
 >   def test
 >     render :text => Ssh.execute(params[:command])

Exactly. Models are typically things that respond to Hash options, and yours 
does. But put the <pre> tag up here, like this:

      render :inline => "<pre><%=h Ssh.execute(params[:command]) %></pre>"

Why did I use :inline, instead of :text with a #{} masher? Because h() is not 
visible at this level, and :inline opens up a little bitty View inside your 
Controller.

Yet your existing design was already very DRY, so these are only suggestions. 
The only technical fix is the h().

Further, shouldn't some other Model object intermediate between the raw SSH 
layer and the Controller? What concept is is the SSH object?

-- 
   Phlip


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to