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!
Whenever a user registers or changes their email, they are sent an
email containing a link which they must click to confirm it.
Upon registering, a user won’t be assigned to any groups and therefore
won’t have permission to do anything (but they can still log in!) Upon
confirming their email for the first time, their account will be
assigned to the Member group and thus “activated”.
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.
