Doing more Ruby on Rails today.
For ensuring data is good …
Anyone ever try using a scope to drop bad results and streamline view presentation?
Then just show the malformed entries on a different view where it doesn’t bork everything up?
Example I hit …
- if pet.user_detail
Revealed I had a single bad piece of data in my test results.
I’ve been playing around with rescue strategies etc for a year when something is missing.
Something like this guy does, though I used another’s idea last year … Link
Having struggled with this several times, I am considering the viability of a scope or series of them that presents only data that is valid & present. Something tells me there is probably a better way in code to do this, but the “If you absolutely & completely must be sure nothing should get to the view unless the record is good…” part of me is going “HRRRRMM”.
From time as a database admin, I would solve this issue in the DB, as a well formed one would have checks against bad data, but from a coders perspective there are more tools available and the database won’t always know what constitutes good data.
I was using a chunk of code that I found to be rather brittle for testing Xpath with Capybara in a ruby on rails integration test. Originally I was just calling
click_link on the first link within the
The problem is that’s really brittle. Any other links put in there before that will mess up the process. Also, if I make that page a partial so I can reuse that particular list on other pages, then my test is broken.
So my practice now is to add a class or div to the top of all partials or pages even if I have the body & nothing else is in that page.
_campaign.html.haml would have a
.campaigns at the top wrapping it. Then my html/css parsing with Xpath would be `.campaigns` to get into the section of the list I want to affect.
For my purposes that’s enough. If you want to go deeper though – as you have more elements inside & need to be selective, then you would add more path hierarchy …
.campaigns/.list-group/.list-group-item … with the last
 being select the first item in the list group.
Xpath best practices is to not stack too many or any nested items so they use
within. Still, probably best to only use two
within‘s one to grab the first unique class/div name & the next to grab the last div or element before running the method against the result.
- Instead the previous campaigns example, using the
within would be combined with something else….
Also, as a bonus I had to figure out the calls for using spaces in the names/titles. There are two methods I like.
- Exact matching with “multiple class selectors”…
.something/.something_else – Link.
- Matching Xpath to just search a string for a partial match with the xml/css – Link. I would still scope the search/match pattern (2nd method) by using a
.within anyways as the whole point is avoiding brittle tests.
Been summarizing some of my studies – note none of this is confirmed by an official Ruby on Rails historian …
I started out looking for where code was supposed to be placed. Why? Because I read about DRY. I really liked the idea of not wasting time redoing code – it’s one of the reason I got into Rails, which I will call RoR from here forward.
So people divide the RoR apps up according to MVC philosophy, which the short version is the model of the database logic, the view you see & is’ logic, and the controller with its logic to tie the two together.
In this MVC design, when I entered RoR’s world most posters were talking about Fat Model / Skinny Controller.
I started reading a lot about this stuff … Justin Weiss has a great breakdown summary of different patterns & where they get placed in the RoR app – Link. I also like the description of the process on Stackoverflow from ‘Jason‘ & Mike Woodhouse – Link.
From what I can gather from posts there was a development of programming as people moved along. Notice I’m not numbering these…there’s a reason…
- model / controller / views
- helpers (with special visibility to only their views)
- custom classes anywhere
- app/lib as “the spot” which at one point in RoR history auto loaded (not anymore)
- modules / mix-ins to include the classes/methods
- gems – which
- plugins – which were discontinued in Rails 4, but the command used to make engines now – Hawkins had a good break down if somewhat biased – Link
- concerns – which even had a special
activesupport::concerns for including classes added
- rails engines which improve on the modules>gems by encapsulating the database too … often these are wrapped in gems when created with mountable option – this might be part of the micro-services movement…