Feature: Make everything an article.
Reported by Nolan Darilek | June 24th, 2008 @ 08:08 PM | in 0.5
Right now, there's lots of potential to integrate Feather with external services via plugins, which is cool. The problem, though, is that the only way to do this is to have each plugin re-invent the wheel and make some non-standard thing that is basically an article. This introduces unexpected behaviors and makes achieving desired behavior difficult.
Take, for instance, my attempt at installing feather-twitter. First I couldn't get tweets to appear because tweets use article-rendering hooks. I eventually made them appear by adding an article, but even so, tweets behave in non-standard ways. They don't appear to paginate, so I can't go back very far. They also don't appear in archives or won't appear as articles in any other plugin that displays articles in a new way unless that plugin is modified to work with tweets as well.
Then, of course, the same thing happens again when someone writes a flickr integration plugin. :)
It might be a good idea for future integration plugins to format their models as articles. Tweets, for instance, could be articles with HTML content, and rather than using custom partials to control the views, they'd be rendered normally. This would let me slirp in all my twitter updates and treat them just like blog posts. It'd also solve the "need an article before tweets appear" issue.
The only down side to this is that shorter updates would make the index paginate more quickly, but even so, the cleanliness of treating everything as an article would seem to outweigh this minor and occasional annoyance.
Comments and changes to this ticket
-
Elliott Draper June 25th, 2008 @ 04:44 PM
- State changed from “new” to “open”
- Tag set to “feature, plugin, twitter”
- Assigned user set to “Elliott Draper”
I couldn't agree more - I was actually thinking of something similar earlier today, the current Twitter implementation (that I wrote) isn't particularly tidy, and having the ability to simply insert "items" into the article stream that then get rendered by the existing views is a much nicer way of doing it. Pagination, archives, sorting, rendering would all be much much more reliable, and it would pave the way for Pownce, Brightkite, Plurk, Flickr, Delicious, other blog integration, and anything else anyone can think of! We could potentially extend core to allow these new items to be fed easily into the article stream, and then have a simple plugin for each service that we want to integrate with.
I'll assign this to me as I'm happy to work on this, if you or anyone else fancies taking it on before I get to it, let me know and I'll re-assign it.
-
Elliott Draper June 25th, 2008 @ 05:14 PM
- Milestone set to “0.5”
-
Alexander Flatter June 27th, 2008 @ 07:49 AM
I made a step in that direction without reading your ticket:
http://github.com/aflatter/feath...
As you can see in #render_one, the partial is chosen by the element's class.
This means that you can put different types of objects into one collection and render them as long as they have a partial. We could provide a default partial too.
BTW: I would rename the Articles controller then.
-
Nolan Darilek July 1st, 2008 @ 04:03 PM
- Tag changed from “feature, plugin, twitter” to “feature, item, plugin, twitter”
I've been doing a lot of work on this.
http://github.com/thewordnerd/fe...
http://github.com/thewordnerd/fe...
Everything is an Item. Items that are to be paginated, archived, put into feeds, etc. are Posts. Other items can be created that aren't paginated and are simply stored in the database and permalinked. Currently, feather-twitter has been modified to be item-based, and I'm working on doing the same for feather-pages. Things to consider:
1. Currently, feather-twitter formats tweets based on HTML in the model code. This is ugly, but only intended to ensure that this works. Might be good to store an ERB fragment on the plugin settings model, then format incoming tweets based on that. Creating new partials for each plugin in the filesystem seems like a themer's worst nightmare. :) Probably good to just format them all like posts while making the import process a bit more flexible.
2. I modified the twitter plugin UI some, but I'm not entirely happy with it. I've never been in a situation where I've only wanted to look at settings and couldn't just ignore the existence of the edit fields, so I got rid of the "show" view and combined everything into one controller. May be worth looking at the various plugins' UIs in this refactoring, because there seems to be unnecessary divergence between edit/view actions, especially for an admin interface.
3. Currently, tweets are displayed on the plugin settings edit screen. It might be a good idea to generate links to an admin/items controller for each Item subclass, excluding Post. Then perhaps generic CRUD views for each subtype could be provided. Haven't gotten around to doing this yet, though, and would welcome any assistance with it.
I don't necessarily want this ticket assigned to me, as I can't really commit to finishing what I've started here. I am, however, interested in getting feedback on these branches before I go much further. It would be great to know what needs done to make merging this work with the slices branch a desirable move.
-
Alexander Flatter July 2nd, 2008 @ 07:35 AM
I'm rewriting feather-twitter too (using my CollectionPresenter). :-) It's nearly done.
-
Nolan Darilek July 24th, 2008 @ 10:46 PM
Can we bump this up in priority and pull one of these two solutions into edge? It'll really define lots of what we're doing at the moment, so it seems like it'd make more sense to make this major architectural change sooner rather than later when it is more difficult. Both approaches have groundwork laid, and I'm not working any further on items until it gets pulled. :) Don't mean for that to sound harsh, I just don't want to work on a dead-end branch.
Personally I like the presenters slightly better, but there are a few complications:
1. Currently I don't see that they're integrated with archives. Ideally it'd be nice to tell someone about a trip I took in December and point them to myblog.com/2007/12 wherein they'll find everything I've posted on my blog or elsewhere reflected on that page.
2. Currently it appears that all items are selected and converted into an array. I know that DM does lazy-loading, but does the call to to_a cause the query to be executed? Right now it looks like all items of every type are being pulled into a single collection. If the call to to_a is hitting the database, we may want to investigate the efficiency of this. Even with caching, if someone starts paginating through large blogs with lots of tweets, flickr photos, etc. then every time they hit a non-cached page they'll be pulling every single item into one large array and taking a small slice of it.
It was suggested to me that the presenters approach is better because it doesn't tie everything to a database, and could potentially allow for pulling from multiple non-DB data sources. I like flexibility in principle, but despite being less so, the items code supports integration into archives as efficiently as the previous code. If we can meet the two above challenges with presenters then great, but if we lose efficiency or the ability to integrate everything into archives then, IMHO, Feather is no longer a blogging engine.
I'd definitely like to see some movement on this, as I'd really like to launch a Feather blog without worrying about drastic architectural upgrades later. :) I also have a couple plugin ideas that I'd like to start, er, plugging away on.
-
Alexander Flatter July 25th, 2008 @ 07:29 AM
After our talk yesterday, I got some new ideas to work with, but I still have to find a little time to implement them.
Same thing as yesterday: Thanks for showing off some difficult situations; I will try to take care of that.
Alex
-
Elliott Draper July 25th, 2008 @ 10:39 PM
I'll see if I can take a look at the code this weekend, and we can aim to settle upon a definite solution, and merge the code into edge to test out and play with.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create new ticket
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป
A robust set of plugins that'll allow the lightweight Feather core to be extended with various functionality.
Alexander Flatter