I have a textarea in a wiki application where users can write things in
the way “{{property value}}”. These thing will be later transformed in
Annotations (a table in the DB)
I’ll do all the scanning of the content and then save these annotations
in the “def create” and “def edit” of my wiki controller. My question
is, where should I put this scanning and stuff better, in the wiki
controller as I was gonna do, in the annotation controller, or in the
annotation model?
My first though was putting it as a method of the model “Annotation”,
but is something related with an input from the view, and I think a
model hasn’t have to manage this. But…if not… the controller will have
to do all the stuff so… do I have to add any class in between?
On Tue, Dec 19, 2006 at 04:12:54PM +0100, Damaris F. wrote:
annotation model?
My first though was putting it as a method of the model “Annotation”,
but is something related with an input from the view, and I think a
model hasn’t have to manage this. But…if not??? the controller will have
to do all the stuff so??? do I have to add any class in between?
I’m not sure I understand your resistance to putting things in the
model. Maybe you can think about it this way:
Would you like to be able to do the same kind of insertion in the
console
or in another controller, like:
The model must be agnostic. It should accept (require) a specific type
of
input and your views / controllers should respect that format. This
allows
you to keep your code simple.
User.new() accepts a hash. It just so happens that Rails takes
parameters
from a view and stores them as a hash.
I believe this is called “programming to an interface.” That said, Ruby
does
make it more interesting by allowing you to determine what was passed
into
the method,.
I’m not sure I understand your resistance to putting things in the
model. Maybe you can think about it this way:
Would you like to be able to do the same kind of insertion in the
console
or in another controller, like:
some_model.set_text("{{foo}}")
The it should most likely be on the model.
Um, the thing is that the model will have to “analyze” the data between
brackets.
What if tomorrow I change the annotation way and there is no more text
in brackets, but…I dunno…selecting checkboxes? Has the model to
manage the changes in the app View? has to be aware if the annotations
are coming to it in form of text in brackets or in checkboxes?
On Tue, Dec 19, 2006 at 07:23:23PM +0100, Damaris F. wrote:
Um, the thing is that the model will have to “analyze” the data between
brackets.
Yes, that’s what model’s do, they “analyze” or in other ways handle
data. Some might even say, that the model is the data. The controller
is simply a way of manipulating the model.
What if tomorrow I change the annotation way and there is no more text
in brackets, but…I dunno…selecting checkboxes? Has the model to
manage the changes in the app View? has to be aware if the annotations
are coming to it in form of text in brackets or in checkboxes?
If you are really doing the same thing you could either update the model
to account for an alternative way of setting the same attribute or you
could make the controller convert the checkbox input into a string for
your model, though I would probably go for the former in most cases.