On 7/6/06, David King Landrith <[EMAIL PROTECTED]> wrote:
It's on the roadmap, as is integration with OpenID. No one has really started on it, though.
A few people have requested this. It'll break all of our current themes, though, and it'll make a mess of our sidebar editor, which was a pain to get to the state it's in now. On the other hand, it's probably not that hard to support an arbitrary number of sidebars.
That's going to cause a world of hurt. Really.
We need to refactor some of the fields out--there are quite a few redundant fields, or things that we can move into the serialized column because they're rare. But breaking things back out will break a lot of code reuse, and it's all been *nasty* code to get right.
Yeah. I found a 6-second query today in a module I'd never used. Then I accidentally blew away my test DB while trying to fix it.
I'm not sure if this is generally useful or not. I'd like to avoid adding non-metaweb API fields where we can, although I have a few of my own that will probably go into 4.1 if I can keep them from being hideously ugly. What's the point of having a title that's too long to display?
1. introduce user privilege levels and user types. My blog is going
to be a large group blog, and I will need this sooner rather than
later. (This is the one gap between typo and wordpress that is an
absolute obstacle to long term deployment.)
It's on the roadmap, as is integration with OpenID. No one has really started on it, though.
I have a few things already in mind here. I can go into it in some
detail if you all are ready for a proposal.
2. ability to have a right sidebar and a left sidebar (most blogs, in
my opinion, have lines of text that are too long, and therefore too
hard on the eyes). I'll probably start out with a hack of some sort
and try to work it in more gracefully as I get a better handle on how
the sidebar works.)
A few people have requested this. It'll break all of our current themes, though, and it'll make a mess of our sidebar editor, which was a pain to get to the state it's in now. On the other hand, it's probably not that hard to support an arbitrary number of sidebars.
3. separating out some parts of the contents table for article and
comment specific data. In my opinion, there seem to be too many
single use fields to justify a single table for the whole set.
That's going to cause a world of hurt. Really.
We need to refactor some of the fields out--there are quite a few redundant fields, or things that we can move into the serialized column because they're rare. But breaking things back out will break a lot of code reuse, and it's all been *nasty* code to get right.
A fourth item that I have already implemented is an increase in the
number of indices in the tables to make sure that common joins are
correctly optimized.
Yeah. I found a 6-second query today in a module I'd never used. Then I accidentally blew away my test DB while trying to fix it.
A fifth item that I have already implemented is a short_title field
for the contents table, along with a one line change to the
appropriate admin page.
The sql to change this is as follows:
alter table contents add column short_title varchar(60) default NULL
after title;
the changes to the admin page at app/views/admin/content/_form.rhtml
involve inserting the following 4 lines at line 8:
8 <p>
9 <label for="" Title:</label><br />
10 <%= text_field 'article', 'short_title' %>
11 </p>
This allows for a short version of the title to be specified for
places where an abbreviation is appropriate. This is especially
advantageous for elements in the sidebar which may want a meaningful
abridgment of the name due to space constraints. Specifically, I have
a latest_comments plugin that uses it that has the following controller:
class Plugins::Sidebars::LatestCommentsController <
Sidebars::ComponentPlugin
setting :title, "Latest Comments", :label => "Title"
setting :count, 20, :label => "Number of Comments"
setting :show_comment_author, true, :label => "Show Comment
Author", :input_type => :checkbox
setting :show_article_title, true, :label => "Show Article
Title", :input_type => :checkbox
# not used yet
# setting :link_to_more, true, :label => "Link to More Comments
(requires comments page)", :input_type => :checkbox
def self.display_name
"Latest Comments"
end
def self.description
"Links to the latest comments"
end
def content
begin
@articles = Article.find( :all,
:select => "contents.*,
comments.author AS comment_author, comments.id AS comment_id",
:joins => 'LEFT JOIN contents AS
comments ON comments.article_id = contents.id',
:conditions => 'comments.type = "Comment"',
:order => "comments.created_at DESC",
:limit => @sb_config['count'])
rescue Exception => e
logger.info e
nil
end
end
end
(This is my first typo sidebar thing, so excuse any egregious errors
or omissions)
Then it has a default display that looks like this:
<h3><%=h title %></h3>
<% if @articles.empty? -%>
<ul id="latest_comments">
<li>No Comments</li>
</ul>
<% else %>
<ul id="latest_comments">
<li>Last: <%=
# I realize that this is a pretty cloogey way
# to do the date, but I'm not great with the
# rails date thingies yet
d = @articles.first.created_at
p = d.strftime("%p").downcase
i = d.strftime ("%I").to_i.to_s
m = d.strftime("%M").to_i.to_s
t = d.strftime("%a, %b %e")
"#{t}, #{i}:#{m}#{p}" %></li>
<% @articles.each do | article |
title = ''
title << "#{article.comment_author}: " if
show_comment_author
linked_title = ''
if show_article_title
# this works for now, but it should be simplified using
# the coalesce function in the content method of the
# controller and offering an option in the
controller to
# use short_title
if article.short_title.to_s.empty?
linked_title << (article.title.to_s.empty? ?
'[no title]' : article.title)
else
linked_title << article.short_title.to_s
end
end
url = "">{article.comment_id}"
%>
<li><%= link_to(title, url) %></li>
<% end %>
</ul>
<% end -%>
I'm not sure if this is generally useful or not. I'd like to avoid adding non-metaweb API fields where we can, although I have a few of my own that will probably go into 4.1 if I can keep them from being hideously ugly. What's the point of having a title that's too long to display?
I'm new to all of this and new to this community. What's the best way
to work out these kinds of additions?
By and large, sending mail here works as well as anything. I'm going to add a few milestone-4.1 to-do items to Trac soon. Other then that, send patches via Trac. Patches with tests attached are more likely to be merged. Patches that change major pieces of code without tests will probably sit for months, if they get merged at all. Core pieces, like multiuser support or anything that makes changes to the contents table should probably be discussed a bit first.
Scott
_______________________________________________ Typo-list mailing list [email protected] http://rubyforge.org/mailman/listinfo/typo-list
