-
Notifications
You must be signed in to change notification settings - Fork 74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixes #476 - Adds missing location details #516
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
- if @service_areas.present? | ||
%section{ class: 'service-areas' } | ||
- if defined? stitle | ||
- if stitle.present? | ||
%h1 #{stitle}: | ||
%ul | ||
- @service_areas.sort.each do |f| | ||
%li | ||
%span | ||
= f |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -102,14 +102,24 @@ | |
%section#categories-box | ||
%h1 Service Categories | ||
%section.services{ itemscope: '', itemtype: 'http://schema.org/Service' } | ||
%ul{ itemscope: '', itemtype: 'http://schema.org/ServiceType' } | ||
%ul{ itemscope: '', itemtype: 'http://schema.org/serviceType' } | ||
- @categories.each do |category| | ||
%li{ class: "depth#{category.depth}" } | ||
%li{ class: "hierarchy-depth-#{category.depth}" } | ||
%span{ itemprop: 'serviceType' } | ||
-# Category links are disabled till there's a corresponding filter that can be toggled! | ||
= link_to category.name, organizations_path(@search_params.merge(:category => category.name)) | ||
= link_to category.name, organizations_path(@search_params.merge(category: category.name)) | ||
= category.name | ||
|
||
- if @keywords.present? | ||
%section#keywords-box | ||
%h1 Keyword Tags | ||
%section.keywords | ||
%ul | ||
- @keywords.each do |keyword| | ||
%li | ||
%span | ||
= link_to keyword, organizations_path(@search_params.merge(keyword: keyword)) | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The keywords section should be moved to its own partial. This will make it easier to remove from |
||
/ Main detail content. | ||
%section | ||
|
||
|
@@ -118,7 +128,7 @@ | |
%section | ||
|
||
= render partial: 'component/detail/template', locals: { org: @org, field: :short_desc } | ||
= render partial: 'component/detail/template', locals: { org: @org, field: :description, stitle: 'Description' } | ||
= render partial: 'component/detail/template', locals: { org: @org, field: :description, stitle: 'Location Description' } | ||
|
||
- if @org[:coordinates].present? || @org[:transportation].present? | ||
%section.map-box | ||
|
@@ -167,14 +177,16 @@ | |
%section.service{ itemscope: '', itemtype: 'http://schema.org/Service' } | ||
|
||
= render partial: 'component/detail/template', locals: { org: service, field: :name} | ||
= render partial: 'component/detail/template', locals: { org: service, field: :description} | ||
= render partial: 'component/detail/template', locals: { org: service, field: :description, stitle: 'Service Description'} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'd prefer to stop using this pattern, please. This is one of the areas I'm planning on refactoring, so the existing code can be cleaned up later, but any new partials we add should adhere to a better pattern. The way the In the details view, each section represents a different field, and it's possible that one might want to style or mark up some fields differently. By using a template, it makes it harder to customize a particular field. The other problem with this approach is that every time the page is rendered, each field goes through the same logic, even though that logic will never apply to certain fields. It would be faster to render the non-array fields (like Audience, Eligibility, Fees, etc.) directly, than have the code go through a conditional first. In this instance, the best practice would be to have a separate partial for each field, each with its own custom markup, like the languages partial. This way, there's only one place where you need to look to understand what a partial is rendering. With the existing template, there is too much thinking involved. You have to go to the Also, any new content we add should make any user-facing text customizable. So, the
In the view, you would use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It sounds like a helper method might be the way to go. From the CSS-side it's preferable to have these in a consistent HTML template, with permutations on the template easily identified. If they all have their own named partial it becomes difficult to know which partials need to be updated and which don't if the underlying shared HTML structure needs to change. I'd like to move more toward a Web Component model where UI components are a self-contained collection of HTML/CSS.
Right now they each have a unique class name, so can be styled differently through that. The underlying mark up can be separated out for the ones that are different, as is done now, but it's preferable that the same HTML markup be shared.
Ideally, the sections would have underlying components defined through a CSS class and a shared HTML markup and if someone wanted to customized this they'd swap in a different component appearance by changing the class and possibly using a different underlying markup. E.g. right now we have:
Instead we should probably add a component class to this, something like:
Then if someone wanted to customize this, they'd maybe have a different set of component styles they'd apply with:
... that maybe was the summary but had less padding/margin and fit on one-line or something. Additionally, they could do customizations to this specific component instance through the Anyway, I'm not sure what that looks like on the Rails side, but point is any re-usable UI chunk in the design should be isolated and have a shared HTML structure with other UI chunks that are the same. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Given that 1) the HTML structure has already been defined and is not likely to change, and 2) the current template is slowing down the view rendering, the simplest solution I would go with today is to have partials for each field, and you can make sure each partial has the correct HTML structure. Then, if it makes sense to refactor into helper methods, that can be explored. The result of refactoring should never be less efficient or less readable than the previous solution. As an example, take a look at the "Edit location" form in the admin interface. It contains a bunch of fields, of which many share the same HTML structure. I could extract out the various types of similar fields like in this Railscasts, but I personally wouldn't go down that route. I think it's too much added code and complexity for little benefit. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Having said the above, this scenario is not as complicated as ActiveModel form objects, and it should be possible to create simple helper methods, but it's a little more involved than you might think. There will need to be at least 2 helper methods: one for array fields, and one for text fields. The problem with your current template is it tries to be a one-size-fits-all solution, and breaks the Tell, Don't Ask principle. In your template, every field gets asked the same question before it can be rendered: "Are you an array?" For array fields, the answer will always be "Yes", and for text fields, "No". If you already know the answer beforehand, why waste time asking the question? Instead, you should tell the array fields to do one thing, and text fields to do another thing by creating separate methods for them. Because the methods act on an object, you will need to pass the Service object as a parameter, along with other parameters, like the field name and h1. However, creating a regular helper module with methods that could be used with any object (not just a Service), would be wrong since we'd like to use an object oriented approach. This means we'll need to create a separate class, called |
||
= render partial: 'component/detail/urls', locals: { org: service, field: :urls, stitle: 'Homepage' } | ||
= render partial: 'component/detail/template', locals: { org: service, field: :fees, stitle: 'Fees' } | ||
= render partial: 'component/detail/template', locals: { org: service, field: :audience, stitle: 'Audience' } | ||
= render partial: 'component/detail/template', locals: { org: service, field: :eligibility, stitle: 'Eligibility' } | ||
= render partial: 'component/detail/template', locals: { org: service, field: :how_to_apply, stitle: 'How to Apply' } | ||
= render partial: 'component/detail/template', locals: { org: service, field: :wait, stitle: 'Service Wait Estimate' } | ||
= render partial: 'component/detail/service_areas', locals: { org: service, field: :service_areas, stitle: 'Service Areas' } | ||
|
||
/ detail footer content | ||
/ Detail footer content. | ||
- if @org[:updated_at].present? | ||
%footer | ||
%section.metadata | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think these two conditionals are necessary. Per my previous comment, the
h1
should be read from the locales file, which will have a value by default.