Mobile responsive design with a very native feel, all in pure CSS (no
templating differences between versions — even though some things are
in very different positions.)
I’ve been working on this whole thing in my head for a while now,
planning out how certain components will be laid out on the mobile
version, and how to reason about them in the templates so that a
substantially different layout can still be achieved by only using CSS.
Today I finally wrote the CSS and it’s come together pretty damn
perfectly.
Still to come:
- Swiping left or right on discussions to reveal controls
- Tablet version
This means the component instance is created in the template, meaning
properties can be overridden in the view helper. It also just makes
more sense - a view instance doesn’t need to exist until it is rendered
in the template.
New stuff:
- Signup + email confirmation.
- Updated authentication strategy with remember cookies. closes#5
- New search system with some example gambits! This is cool - check out
the source. Fulltext drivers will be implemented as decorators
overriding the EloquentPostRepository’s findByContent method.
- Lay down the foundation for bootstrapping the Ember app.
- Update Web layer’s asset manager to properly publish CSS/JS files.
- Console commands to run installation migrations and seeds.
Refactoring:
- New structure: move models, repositories, commands, and events into
their own namespaces, rather than grouping by entity.
- All events are classes.
- Use L5 middleware and command bus implementations.
- Clearer use of repositories and the Active Record pattern.
Repositories are used only for retrieval of ActiveRecord objects, and
then save/delete operations are called directly on those ActiveRecords.
This way, we don’t over-abstract at the cost of Eloquent magic, but
testing is still easy.
- Refactor of Web layer so that it uses the Actions routing
architecture.
- “Actor” concept instead of depending on Laravel’s Auth.
- General cleanup!
Record when the discussion was renamed, from what, and by whom.
Information is stored in the `content` field as a serialised JSON
object because proper polymorphism will be too difficult with Ember
Data and especially when extensions try to add new post types.
If we use an #unless condition, then when the view is removed from the
template, it is destroyed, and cannot be inserted again. So we’ll just
keep the item there the whole time, and toggle its visibility with CSS.
HTMLBars goodness! Since there was some breakage and a lot of fiddling
around to get some things working, I took this opportunity to do a big
cleanup of the whole Ember app. I accidentally worked on some new
features too :3
Note that the app is still broken right now, pending on
https://github.com/emberjs/ember.js/issues/10401
Cleanup:
- Restructuring of components
- Consolidation of some stuff into mixins, cleanup of some APIs that
will be public
- Change all instances of .property() / .observes() / .on() to
Ember.computed() / Ember.observer() / Ember.on() respectively (I think
it is more readable)
- More comments
- Start conforming to a code style (2 spaces for indentation)
New features:
- Post hiding/restoring
- Mark individual discussions as read by clicking
- Clicking on a read discussion jumps to the end
- Mark all discussions as read
- Progressively mark the discussion as read as the page is scrolled
- Unordered list post formatting
- Post permalink popup
Demo once that Ember regression is fixed!
