You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am not sure if this is still needed after #6, but I'm copying the issue over from the API repo for now.
Jess
pages should know their identity and be able to pass controller variable to set class so Karin can use one stylesheet
I recall this was trouble with turbolinks or some other rails caching type of mechanism, specifically with the neihardt version of the site, but I have no idea if Rails 5 can handle it or if other things have changed about how the pages are rendered which would mean this works out better. Should revisit.
Debating on whether this should always be explicitly set (i.e. passing through a variable from the view) OR if it should be entirely based on the URL. In cocoon I mostly depended on routes/url's. I'd set the home page explicitly:
and then all the other pages I'd set by the first part of the URL:
above = the text that gets inserted as a class name
To be more future proof, we may want to prepend something to make sure that class names don't collide with any framework classes. so maybe
site_home
site_about
site_writings
etc.
Thoughts?
We had a brief discussion about the feasibility of including this based on the url - for most sites, I think this would be enough, though being able to overwrite from a view would also certainly be useful.
I vaguely recall trying to use the controller previously for the Neihardt test run and it didn't have as fine of control as Karin was looking for. Maybe controller + action?
The text was updated successfully, but these errors were encountered:
I am not sure if this is still needed after #6, but I'm copying the issue over from the API repo for now.
Jess
pages should know their identity and be able to pass controller variable to set class so Karin can use one stylesheet
I recall this was trouble with turbolinks or some other rails caching type of mechanism, specifically with the neihardt version of the site, but I have no idea if Rails 5 can handle it or if other things have changed about how the pages are rendered which would mean this works out better. Should revisit.
Example:
https://github.com/CDRH/neihardt/blob/master/app/views/layouts/application.html.erb#L2
Karin
Debating on whether this should always be explicitly set (i.e. passing through a variable from the view) OR if it should be entirely based on the URL. In cocoon I mostly depended on routes/url's. I'd set the home page explicitly:
and then all the other pages I'd set by the first part of the URL:www.whatever.org/*/**/***.html
To be more future proof, we may want to prepend something to make sure that class names don't collide with any framework classes. so maybe
site_home
site_about
site_writings
etc.
Thoughts?
We had a brief discussion about the feasibility of including this based on the url - for most sites, I think this would be enough, though being able to overwrite from a view would also certainly be useful.
Greg
Another option may be to use the controller name, params[:controller], similarly to how it is described here: http://edgeguides.rubyonrails.org/asset_pipeline.html#controller-specific-assets
Jess
I vaguely recall trying to use the controller previously for the Neihardt test run and it didn't have as fine of control as Karin was looking for. Maybe controller + action?
The text was updated successfully, but these errors were encountered: