It would be helpful to see a larger context here, because if this is running in a Rails project, then there’s a particular way you structure the page – images have to be invoked in a particular way, forms are handled in another. Anything that is in a view (the part you would be changing) is context-dependent. A view is invoked by a controller, which sets up the variables that you have to play with.
Looking at the code you have here:
<% questions.useful.each do |q| %>
<% if category %>
<%= category.name.html %><% else %>Search Results<% end %>
This could be expressed in pseudocode (fake, made-up code to describe a functional structure) like this:
given an array of questions,
take the ones with a useful parameter,
loop over them:
call each one 'q',
if q has a property called category,
print the html flavor of the category's name
otherwise
print the string 'Search Results'
end the test on q
end the loop on questions
Ruby is a very flexible and expressive language, and it doesn’t need a lot of control operators (parentheses, curly braces, dollar signs) to make a function call or to pass variables around. This makes it very terse, but once you grasp it, it also makes it very pretty (if such a thing can be said about a programming language).
So in this example, if it’s a MVC (Model View Controller) programming environment like Rails, the Controller would gather up the questions, decorate each of them with additional properties, then pass the array of objects to the View for conversion into display html. As you edit the View, you have to know what you have to play with. This code fragment you posted shows one example, but there are likely others.
For example, you might have a view that shows one question. So you wouldn’t have a loop at all, and you might not even see the keyword ‘question’ in the code, either. Your view would just “know” that it was operating on a question, and you would need to know the individual properties that this question had, so you could call them by name.
If you work on moving HTML around, and leave the erb parts more or less alone – that is, edit the parts that look familiar – then this can be a great learning experience, because you probably won’t break anything and you’ll get to see the inner workings of a template engine in a very micro way. Where this will get frustrating and complex is if your client asks you to create new views that don’t have parallels in the existing code. The first time you have to code up an erb template from scratch, it will feel like building a ship in a bottle, while blindfolded and wearing oven mitts.
Walter
dynamo mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
