Restructure UI code.
Jonne Haß
Public
Seen by 45
I think we don't need to vote if we should do it, so this discussion is about how doing it. To make things easier we should keep the current design where possible for now and do design improvements when this is done. I'll list some possible requirements/alternatives to what we currently use/tasks:
HTML/Templates
- Get rid of unused templates
- Get rid of
app/views/shared/if still in use move them to better fitting places - Make clear rules on what to render on the server and what to render on the client side, get rid of handlebars and server side templates doing the same job.
- Refactor the code to get rid of "styling HTML", like 99% of
<br>s, potential<b>tags and whatever - Use semantically rich tags, like using
<em>for something important, not because it looks cool. - Decide on either ERB or HAML, don't use both.
- Use all the (semantic) power HTML5 provides.
- Stop using casing as design element, that just localizes terribly as there are scripts which have no casing.
CSS
- Make Layout responsive
- Get rid of fixed sizes where possible (I'm looking at you,
px) - Develop a clear and clean structure. Like for example one CSS file for each GET route + meaningful common usages Group the common usages by categories, i.e. forms.
- Port every SASS code to SCSS, see #3796 [DONE]
- Get rid of all
:css/`` blocks in templates - Port everything from Blueprint to Bootstrap, see#4466
JS
- Get rid of multiple libraries essentially doing the same where possible, i.e. the autocomplete ones.
- Move everything to Backbone if possible.
- Replace hacked libs with vanilla ones doing it right in the first place. If not found try to externalize the hack into another file. If not possible make it damn clear inside the library where the change it and why it was done with big fat comments, to ease the life of the updater.
- Update all dependencies, replace them with gems if available (maybe even create some?)
While at the frontend code, the locale files too contain many unused keys and semi duplicates. A lot of the template code was moved around so I guess about the half of the keys is accessed using the full path, unable to take advantage of the dot syntax. Maybe we should develop a struture there that's independent from the template structure?
I'll keep this list updated with the ongoing discussion, so ensure you'll rescan it once in a while ;)
Flaburgan Thu 27 Feb 2014 8:12AM
Hi, most of the front end code is dirty, we clearly need a real refactor, not only a conversion. This is currently done during the port to bootstrap.
Flaburgan Sat 1 Mar 2014 10:22AM
@ryunoki I am the one who does most of the port from Sass to Scss (see #3796) and manage css files. @steffenvanbergerem is the one who does most of the port from blueprint to bootstrap (see #4466)
Simply warn on these issues when you want to do something, and do it :) Don't hesitate to ping us on github or IRC if you need help.
Ryuno-Ki Thu 13 Mar 2014 7:00AM
Hm, will simply comment on it in the hope of getting informed on further comments … this week, I'm working on finishing my own projects ;-)
goob Wed 2 Apr 2014 10:20PM
Should we take a vote on whether to use ERB or HAML, or is more discussion needed on that issue first?
Sean Tilley Thu 3 Apr 2014 10:53PM
Might as well just vote on it.
Ryuno-Ki · Tue 25 Feb 2014 9:57PM
Hm, that's challenging.
I'm converting the .erb (but not .markerb) files into .haml using html2haml (works with .erb, too!).
However, it's not that easy (read: currently impossible) to mix JavaScript and Ruby interpolation at the moment.
For the record: For compiling .js out of .haml, wrap the code inside a :javascript filter (search the docs), which leads to the appropriate script-tags.
It's recommend to move the JavaScript code out of the markup. Shall I open a ticket for it?