Skinny Controller, Fat View?

My Web application has several contexts where a collection of ActiveRecords is
rendered. If the URL contained the partial and/or layout, the several
controller methods could be collapsed into one. What hazards, etc. lie that
way?

TIA,
  Jeffrey

I, for one, do not understand what you mean. Could you give a more
detailed description, with example?

Colin

Quoting Colin Law <clanlaw@googlemail.com>:

>
> My Web application has several contexts where a collection of ActiveRecords is
> rendered. If the URL contained the partial and/or layout, the several
> controller methods could be collapsed into one. What hazards, etc. lie that
> way?

I, for one, do not understand what you mean. Could you give a more
detailed description, with example?

It's an RSS readers. Users have feeds that have articles. A list of articles
can appear in about four contexts: a paginated flat list of all unread
articles, a flat list of articles found by a search. list of all unread
articles indented under a feed (with collapse/expand icons), a list of all
read articles under another type of header. Currently all of these have their
own action method under two different controllers.

I think it is feasible to have one action method that is passed the selection
criteria (unread, read, etc. articles) and a layout or partial template to
render thru the URL. Beyond the obvious SQL injection protection and
restricting the template/layout to a known set of reasonable values, what
hazards (security, maintenance, etc.) lie this way?

I think I can move towards and possibly achieve a RESTful API with a bit of
squeezing state and context into the URL.

Does this way lie madness/dragons?

TIA,
  Jeffrey

Hello--

Quoting Colin Law <clanlaw@googlemail.com>:

My Web application has several contexts where a collection of ActiveRecords is
rendered. If the URL contained the partial and/or layout, the several
controller methods could be collapsed into one. What hazards, etc. lie that
way?

I, for one, do not understand what you mean. Could you give a more
detailed description, with example?

It's an RSS readers. Users have feeds that have articles. A list of articles
can appear in about four contexts: a paginated flat list of all unread
articles, a flat list of articles found by a search. list of all unread
articles indented under a feed (with collapse/expand icons), a list of all
read articles under another type of header. Currently all of these have their
own action method under two different controllers.

I think it is feasible to have one action method that is passed the selection
criteria (unread, read, etc. articles) and a layout or partial template to
render thru the URL. Beyond the obvious SQL injection protection and
restricting the template/layout to a known set of reasonable values, what
hazards (security, maintenance, etc.) lie this way?

I think I can move towards and possibly achieve a RESTful API with a bit of
squeezing state and context into the URL.

Does this way lie madness/dragons?

TIA,
Jeffrey

If you embed that information in the URL, you wouldn't be the first (nor probably the last) to do it, but you are then tying your URL to your implementation. Littering URLs with implementation details can break bookmarks and also be confusing to search engines, which may or may not matter to you.

Why is the querystring not sufficient? E.g. http://my.domain.com/keenview?view=flat. That exposes a bit of the implementation but probably won't break if the view key is left off.

Quoting s.ross <cwdinfo@gmail.com>:

Hello--

>
> Quoting Colin Law <clanlaw@googlemail.com>:
>>
>>>
>>> My Web application has several contexts where a collection of
>>> ActiveRecords is
>>> rendered. If the URL contained the partial and/or layout, the
>>> several
>>> controller methods could be collapsed into one. What hazards,
>>> etc. lie that
>>> way?
>>
>> I, for one, do not understand what you mean. Could you give a more
>> detailed description, with example?
>>
> It's an RSS readers. Users have feeds that have articles. A list
> of articles
> can appear in about four contexts: a paginated flat list of all unread
> articles, a flat list of articles found by a search. list of all
> unread
> articles indented under a feed (with collapse/expand icons), a list
> of all
> read articles under another type of header. Currently all of these
> have their
> own action method under two different controllers.
>
> I think it is feasible to have one action method that is passed the
> selection
> criteria (unread, read, etc. articles) and a layout or partial
> template to
> render thru the URL. Beyond the obvious SQL injection protection and
> restricting the template/layout to a known set of reasonable values,
> what
> hazards (security, maintenance, etc.) lie this way?
>
> I think I can move towards and possibly achieve a RESTful API with a
> bit of
> squeezing state and context into the URL.
>
> Does this way lie madness/dragons?
>
> TIA,
> Jeffrey

If you embed that information in the URL, you wouldn't be the first
(nor probably the last) to do it, but you are then tying your URL to
your implementation. Littering URLs with implementation details can
break bookmarks and also be confusing to search engines, which may or
may not matter to you.

Why is the querystring not sufficient? E.g. http://my.domain.com/keenview?view=flat
. That exposes a bit of the implementation but probably won't break if
the view key is left off.

Most of these contexts are AJAX responses so bookmarkability is not relevant,
but I will keep it in mind. In fact, search results are currently not
bookmarkable because only POST requests are actually searches, any GET request
to the URL is expected to be a pagination request. Thank you for pointing
that out. Currently too much state is in the session, so not bookmarkable.

I will think on this,
  Jeffrey

Check out the Presenter pattern. This might help out a bit: http://blog.jayfields.com/2007/03/rails-presenter-pattern.html

Several years ago when I first heard about the Presenter, it didn't make
sense. Unneeded complexity. But now maybe I've encountered the problem(s) it
is a solution to. I'll look at it.

Thanks,
  Jeffrey

Quoting s.ross <cwdinfo@gmail.com>:

Check out the Presenter pattern. This might help out a bit: http://blog.jayfields.com/2007/03/rails-presenter-pattern.html

>
> Quoting s.ross <cwdinfo@gmail.com>:
>>
>> Hello--
>>
>>
>>
>>>
>>> Quoting Colin Law <clanlaw@googlemail.com>:
>>>>
>>>>>
>>>>> My Web application has several contexts where a collection of
>>>>> ActiveRecords is
>>>>> rendered. If the URL contained the partial and/or layout, the
>>>>> several
>>>>> controller methods could be collapsed into one. What hazards,
>>>>> etc. lie that
>>>>> way?
>>>>
>>>> I, for one, do not understand what you mean. Could you give a more
>>>> detailed description, with example?
>>>>
>>> It's an RSS readers. Users have feeds that have articles. A list
>>> of articles
>>> can appear in about four contexts: a paginated flat list of all
>>> unread
>>> articles, a flat list of articles found by a search. list of all
>>> unread
>>> articles indented under a feed (with collapse/expand icons), a list
>>> of all
>>> read articles under another type of header. Currently all of these
>>> have their
>>> own action method under two different controllers.
>>>
>>> I think it is feasible to have one action method that is passed the
>>> selection
>>> criteria (unread, read, etc. articles) and a layout or partial
>>> template to
>>> render thru the URL. Beyond the obvious SQL injection protection
>>> and
>>> restricting the template/layout to a known set of reasonable values,
>>> what
>>> hazards (security, maintenance, etc.) lie this way?
>>>
>>> I think I can move towards and possibly achieve a RESTful API with a
>>> bit of
>>> squeezing state and context into the URL.
>>>
>>> Does this way lie madness/dragons?

[snip]