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.
