[typo] A matter of style
Scott Laird scott at sigkill.org writes: On Sep 27, 2005, at 10:13 AM, Piers Cawley wrote: Yeah, but then I like rectangular arg blocks when they're parenthesized object.method(arg1, arg2, arg3, arg4, arg5, arg6) Which doesn't do much for shortening lines. object \ .method(arg1, arg2, arg3, arg4, arg5, arg6) I hate trailing backslashes. This looks cleaner to me: object. method(arg1, arg2, arg3, arg4, arg5, arg6). anothermethod(). somethingelse I see how this could be confusing to some people, though. that . doesn't really distinguish itself does it? The backslash has the benefit of being rather more visible. Plus, on first reading, I thought 'anothermethod' was one of method's arguments. -- Piers Cawley pdcawley at bofh.org.uk http://www.bofh.org.uk/
Re: [typo] A possibly dumb question...
Piers Cawley [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: With a typo 2.6 install, I see properly formed hyperlinks in comments on blog entries are being rendered as plain text. The comments filter is set to Markdown with Smartypants. Bug? Feature? User error? A glance at test/functional/articles_controller_test.rb seems to imply it's a bug. But I'm looking at the trunk not 2.6, so it might be a little longer before I take a closer look. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] A possibly dumb question...
Rodger Donaldson [EMAIL PROTECTED] writes: On Tue, Dec 06, 2005 at 08:49:59AM +, Piers Cawley wrote: [EMAIL PROTECTED] writes: With a typo 2.6 install, I see properly formed hyperlinks in comments on blog entries are being rendered as plain text. The comments filter is set to Markdown with Smartypants. Bug? Feature? User error? A glance at test/functional/articles_controller_test.rb seems to imply it's a bug. Looking at the implementation of ArticlesControllerTest#test_comment_spam1 I reckon a new test along the lines of this should expose any bug. def test_comment_spam_with_markdown_smartypants settings[:comment_text_filter] = markdown smartypants test_comment_spam1 end Where 'test_comment_spam1' takes a string with a well formed link in it and simply turns it into a 'nofollow' link (and adds p.../p wrappers round the string). I'll have a proper look later. Along those lines, it's also (I notice) adding another nofollow attribute every time the comment is edited, irrespective of whether there's already one there. I'm surprised it's adding one every time, since the html *should* be generated from the unformatted body (which is (or should be sacrosanct)). But nofollowify is definitely in the 'ugly hack' category of html modification. Having looked at its implementation I can think of all sorts of ways to break it in an entertaining fashion (I think a suitably crafted atrribute could let a spammer avoid the nofollow for instance.) I shall be having a play later. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo failed to start properly after rails update
Ernie Oporto [EMAIL PROTECTED] writes:
I was on 764. I've grabbed 791 and all looks good. We'll see how long it
lasts. For reference, this is the error I saw in my logs for looking at an
article entry. I haven't tested anything with script/server, but I've never
had issues with it.
Processing Base#permalink (for 24.149.167.195 at 2005-12-09 14:42:08) [GET]
Parameters: {month=11, title=feed-on-feeds-0-1-9-search,
action=permalink, controller=articles, day=01,
year=2005}
This was how it broke at 764? Or a random error that's cropped up
since? If it's a 764 issue then I'm not to worried about it, given
that it's working now.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Postgres Issue with Migrate BoolifyContentAllowFoo
Piers Cawley [EMAIL PROTECTED] writes: Paul Hart [EMAIL PROTECTED] writes: Jeffrey, Piers, Thanks for your help so far. I'm on the digest version of the mailing list, so I'll respond to both of you in turn. Piers: I might roll back to 739, but I'd prefer to have this fixed (and do what I can, if anything, to help). I haven't been on IRC in years, so I guess the person you were chatting with wasn't me! :) Jeffrey, I modified the code as you suggested in your mail. That fixed the issue with the allow_comments, but now it's hanging up on allow_pings. I find that weird, because it appears (to my rails-newbie-ish eyes) that the migrate script should be doing both allow_comments and allow_pings. I'm guessing that by doing the two separately postgres is happy about the one fix, but whiney about the second not being there yet? My rails UPDATE statment always seems to include all the columns regardless of which ones have changed, and that would be an issue given this method of solution. Yes! Thanks. Obvious when you point it out. New patch coming up. But not as soon as I thought. It appears that Typo HEAD and rails 14.4 don't play well together. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Postgres Issue with Migrate BoolifyContentAllowFoo
Piers Cawley [EMAIL PROTECTED] writes: Piers Cawley [EMAIL PROTECTED] writes: Paul Hart [EMAIL PROTECTED] writes: I'm guessing that by doing the two separately postgres is happy about the one fix, but whiney about the second not being there yet? My rails UPDATE statment always seems to include all the columns regardless of which ones have changed, and that would be an issue given this method of solution. Yes! Thanks. Obvious when you point it out. New patch coming up. But not as soon as I thought. It appears that Typo HEAD and rails 14.4 don't play well together. Right. The fix is in. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] getUsersBlogs
Scott Laird [EMAIL PROTECTED] writes: It's been a slow month. I'd really like to get a few fixes integrated, but something bizarre is going on with Ruby on my laptop; once I get Ruby working again I'll start working through the backlog of patches. I'm currently having problems getting everything passing its tests with Rails 1.0; something to do with categories not being saved, and I've no clue why it's not working. Oh, and I've got a possible new job lined up and a car to get serviced and... Once I've got that squared away though I hope to be able to commit 1 full day a week working on Typo. Probably Tuesdays. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] No tags for article displayed anymore
Patrick Lenz [EMAIL PROTECTED] writes:
On Jan 1, 2006, at 2:13 PM, Urban Hafner wrote:
Thanks for the quick response. I updated to 806, emptied the page
cache but I still see no difference.
You might have to hit 'save' for each article missing the tags. The
problem I fixed occurred while transforming the space separated
Article#keywords field into separate rows in tags and assignments to
articles_tags.
For future reference, something like:
script/runner 'Article.find(:all).each {|a| a.save}' -e production
should do the job nicely.
I find myself wondering if some sort of 'rake refresh_content' task
might be a useful addition for the future...
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] getUsersBlogs
Patrick Lenz [EMAIL PROTECTED] writes: On Jan 2, 2006, at 9:05 PM, Piers Cawley wrote: I'm currently having problems getting everything passing its tests with Rails 1.0; something to do with categories not being saved, and I've no clue why it's not working. There's an issue in Rails 1.0 having to do with multiple habtm relationships where only the first is being saved properly. This should be fixed in Rails trunk. However, the changesets I fired in over the last days made all tests pass for me. You might want to sync your tree. Yup, just did and all is well. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] getUsersBlogs
Scott Laird [EMAIL PROTECTED] writes: On Jan 2, 2006, at 12:05 PM, Piers Cawley wrote: Scott Laird [EMAIL PROTECTED] writes: It's been a slow month. I'd really like to get a few fixes integrated, but something bizarre is going on with Ruby on my laptop; once I get Ruby working again I'll start working through the backlog of patches. I'm currently having problems getting everything passing its tests with Rails 1.0; something to do with categories not being saved, and I've no clue why it's not working. Oh, and I've got a possible new job lined up and a car to get serviced and... Once I've got that squared away though I hope to be able to commit 1 full day a week working on Typo. Probably Tuesdays. Heh. I've been in a similar boat, with a new job 700 miles from home. Fortunately, it looks like my schedule will calm back down later this week and I should be able to get more accomplished with Typo. That and Christmas/New Year/Housewarming. Mmm... new house. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Changeset 828
Kevin just added a changeset that is claimed to fix 'test_comment_xss1', but which actually breaks it on my server. Kevin, do you have a gem installation of redcloth by any chance? If so, which version. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Changeset 830, abstemious cache sweeping
In case anyone's wondering what the new BlogSweeper#expire_siblings_of method is supposed to be doing, be aware that, right now, it's a stub. The idea is that, when an article is created or deleted, all the paginated sets in which the article could appear need to be flushed. Right now, the flushing logic is slightly broken; when you modify an article and change either its tags or its categories, a safe strategy is to sweep the entire cache, but we aren't quite doing that. However, if I don't finish typing this and step away from the keyboard for at least the next few hours, my life will not be worth living, so feel free to fix things :) -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Multiple Blogs Ticket #343
Scott Laird [EMAIL PROTECTED] writes: On Feb 16, 2006, at 9:06 PM, b4 wrote: I'm new. I'm evaluating blog packages to use in a project. We have 2 key requirements: support for multiple blogs/users one instance of typo for hundreds or thousands of blogs and authors ability to do single sign-on with our core app (built on Rails) authentication and authorization driven from our user/permission model I found ticket #343 http://www.typosphere.org/trac/ticket/343. Is anyone working on this? I would rather _not_ go back to J2EE and use Roller. In fact, i would rather spend a month solving those 2 problems using typo ;~) Any thoughts? Warnings? A number of people have started looking at adding multi-blog support to Typo, but no one has actually finished yet. It'll end up being fairly invasive, but it's not undoable. I suspect that it's really just a couple weeks' work. It's that very invasiveness that scares me certainly. And it's quite hard to think of a simple little test case to add that won't need the whole two weeks of work to make it pass. I suppose a first step would be to add a 'blog_id' entry to the contents table and make the various controllers use it... Hmm... I think it's a post 4.0 thing though. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo vs. Captcha.
George Razvan NICA [EMAIL PROTECTED] writes: Hi all, I was thinking of a solution of limiting comment spam by the use of a captcha. As far as I could see there is a nice tutorial for Captcha Rails over at http://frankhale.org/CAPTCHA_RoR_Tutorial.html . Are there any plans of including such a thing into Typo? It'll be a cold day in hell before *I* implement a Captcha scheme in Typo, but I can't speak for the other maintainers. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo vs. Captcha.
George Razvan NICA [EMAIL PROTECTED] writes: http://frankhale.org/CAPTCHA_RoR_Tutorial.html . Are there any plans of including such a thing into Typo? It'll be a cold day in hell before *I* implement a Captcha scheme in Typo, but I can't speak for the other maintainers. Maybe it's just my non-native English but I don't really get what you mean. Would you care to elaborate a little bit, please? I really, really don't like Captchas and I won't implement such a scheme. But I won't stop anyone else who wants to. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent Multi-Blog update Breaks
Kevin Kubasik [EMAIL PROTECTED] writes: Just a note, I found that when attempting to update to the latestTrunk, rev 915 breaks (it can't seem to add the new blogs tablecorrectly) 914 is good though. It seems to me that a multiblog branchshould be handled that way, in its own branch, not in the trunk(although the comment seems to imply that it is being done in abranch, maybe im just SVN illiterate) It's staying in the trunk -- the comment about the branch was from my local SVK based repository which I'd not edited out. What errors were you getting when you tried to run the migrations? Could you send me a the relevant log section? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent Multi-Blog update Breaks
Gary Shewan [EMAIL PROTECTED] writes: On 17 Mar 2006, at 16:19, Piers Cawley wrote: Kevin Kubasik [EMAIL PROTECTED] writes: Just a note, I found that when attempting to update to the latestTrunk, rev 915 breaks (it can't seem to add the new blogs tablecorrectly) 914 is good though. It seems to me that a multiblog branchshould be handled that way, in its own branch, not in the trunk(although the comment seems to imply that it is being done in abranch, maybe im just SVN illiterate) It's staying in the trunk -- the comment about the branch was from my local SVK based repository which I'd not edited out. What errors were you getting when you tried to run the migrations? Could you send me a the relevant log section? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list Sigh, well that's me not upgrading in trunk. Multi blog support is bloat for those of us running Typo on single sites. I think it's a bad move to keep this in trunk. If you want me to throw a penny in I'd say split it now. The initial attraction of Typo because it was lean. Why keep multi blog in trunk when not everyone wants it? It's screaming out for a separate branch. God I hate bloat. Have you even read the patch? The reason that the current changes have gone into the trunk is because they're paving the way to *removing* bloat. In fact, they have already done so by eliminating the settings table and a bunch of structural code to manage it. You could think of r914 as a refactoring of the config object if you prefer. I have no desire to run multiple typo blogs on my site, but a blog object makes a lot of things that I do want to do a good deal easier to manage. I have every intention of making it so that the single blog case is at least as efficient as the (so far hypothetical) multiblog case, but I also need somewhere to stash a bunch of structural currently implemented in controllers that really doesn't belong there. That place is the blog object. I've not benchmarked it, but I'm willing to be that the new blog object is at least as efficient as the old Configuration and Setting objects. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Migration 38
Kevin Kubasik [EMAIL PROTECTED] writes:
the upgrade kinda worked, I now have the blog table, but get this error
Processing GeneralController#index (for 69.140.109.194 at
2006-03-1809:23:53) [GET] Parameters: {action=index,
controller=admin/general}
Have you restarted your fcgi processes? Looks like you've got old code
trying to work with the new schema.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Flickr Plug-in Issue
Steve Longdo [EMAIL PROTECTED] writes: I had that problem for a bit. I would recommend going and getting your own flickr API key ( http://www.flickr.com/services/api/key.gne ). I did that and replaced the value in the environment.rb file (last line in the file) with my key, the flickr photos returned and the prophecy was fulfilled ;-P I think in this case it's something else; the problem was that I got a bit eager moving stuff from application.rb to content_controller.rb and moved something that the aggregator based sidebars depended on and, because we'd made the mistake of doing: @flickr = check_cache(FlickrAggregation, @sb_config['feed'] rescue nil we weren't even logging the errors. I wonder if there's a case for something like: def evaluate_and_log_error(failure_default = nil) begin yield rescue Exception = e logger.info e failure_default end end and replacing all our 'rescue nil' entries with something along those lines. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Migration 38
David Richardson [EMAIL PROTECTED] writes: Migration still failing with v 924 Can I have another copy of the rake trace? Preferably with linebreaks this time. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent Multi-Blog update Breaks
quite work. Nice idea though. #315 Google sitemaps No tests with the patch. With an even half decent test suite, this would go straight in. Without tests I'm worried I'll break it and not realise. #343 Beef up typo spam protection More of an ongoing issue than anything else. We've been talking on IRC about at least instituting a comment/trackback queue for approving or nuking comments and trackbacks rather more quickly than having to find the right article. Am I right in thinking that you've been doing some work in this area? A patch would be welcome; ideally with tests, but for something like this I'd be far more inclined to look favourably on it and write any necessary tests if someone came up with a good framework #392 Resources that are attached to an an article don't show up on the edit article page I've not attacked this one because I'm not at all sure of a good way to proceed. I think that we need to think rather carefully about the the interface for adding articles and their resources on the content page -- what we have isn't desperately good right now. We could really use some good user stories from people who want to use typo for podcasty type things. There is a podcasting patch, which looks at first glance, to be pretty good, but it has no tests and it adds an awful lot of feature, so it's currently in limbo. #421 Fix RSS converter to use a better parser Kevin Ballard's been working on this; from the look of the patches he's been adding and IRC conversations, we're damned close to being able to close this one. Again, the issue of tests arises, but we've got problems along those lines with all our converters. #304 Remote server communication (at sidebar admin) is not very transparent I'm actually working on this one (or on something that will hopefully close it as a side effect) at the moment. I'm not sure I'll finally have it knocked on the head with this iteration, if only because my javascript skills are... well, 'skills' is probably the wrong word. Rails 1.1 will make this sort of thing *way* easier. Oops, 9 open tickets, I just added: #725 Typo installation is about as friendly as a cornered rat Scott's working on this one. Actually, once Scott's got #725 nailed (and he's bullish about it) we should be able to start releasing some 'pre4.0' distributions. The current sketchy plan is that these will get pushed out weekly or monthly until at least 4.0 There will always be the bleading edge, and we'll always be grateful for the people who stay on it and report back when they get cut by it. We're trying to make it less likely that they'll get badly cut (for instance, migrations 38 and 39 were the two most robust migrations I've ever written. Although there was a problem with Postgres, the transactions got unwound properly and nobody (except me when I was writing them) had to recover anything by hand -- not something we've been able to say for every migration in the past), but we can't guarantee it. I can, however, assure that nothing goes into the trunk if we think it doesn't work. Hopefully the forthcoming pre4.0 series will let people get a good deal nearer to the edge without hurting themselves. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent Multi-Blog update Breaks
Gary Shewan [EMAIL PROTECTED] writes: On 19 Mar 2006, at 18:47, Piers Cawley wrote: Thanks for that Piers, it's appreciated because you didn't have to outline all that at all. Much better attitude than some development communities where any questions are met with It's open source, we give our time for free, deal with it or disappear Well, you know, I was tempted, but I thought of the three virtues of a programmer (Laziness, Impatience and Hubris). The whole 'deal with it or disappear' attitude is more along the lines of arrogance than Hubris. Operating with those virtues tends to mean that stuff goes in the trunk. If it turns out to be misguided, it gets rolled back. (For instance, I just rolled back the change that replaced the global config method with a this_blog method; I had temporarily forgotten that there are more themes out there than Azure and they all of 'em use config, not this_blog. Oops.) I understand that it needs to be fun, and I've never met a developer that really enjoys a good bug hunt over new functionality ... think I'd have a heart attack if I did ;) I dunno, there's a lot to be said for squashing a good bug. When a bug comes up in the trac that I can fix, I set to it with a will. Problems arise when I'm either not convinced that something's a bug or I don't have the knowledge or software to test it (the IE 6 issues, for instance), or when the defect is obvious, but the design insight needed to sort it out just isn't forthcoming. Then I go and work on something that I know how to do. There is a growing interest in Typo, but until there is a 4.0 release I never really recommend it to anyone unless they feel confident about it. The Typo installation is as friendly as a cornered rat issue again eh? From some of the things he's been saying about this on IRC, I'm pretty sure you'll like Scott's work on this. Everybody I know who isn't too technically minded - and has tried Typo - has pulled their hair out in frustration. I've been bitten hard a couple of times with migrations, but that isn't a problem for me because I know what working on the edge of trunk means. And it's because we have to deal with the support issues that arise when these things happen that we've been working on making the last few migrations as painless as possible. The new BareMigration system is a massive improvement here and a thousand thanks are owed to [EMAIL PROTECTED] for the fabulous patch that introduced BareMigrations and rejigged all the migrations to use them. I now have a great deal more confidence that I can make a migration work independently of any future changes in the behaviour of typo's model objects and that's an enormous godsend. I'm now pretty confident that you can migrate up to the bleading edge from any schema version you like, and that's a massive improvement on the the bad old days of, um... not all that long ago recently. I still have just over a thousand legacy blog comments sitting in an sql file that I have to reinclude because they got lost on one migration. But that's what I get if I only check 99% of everything after a trunk migration :) Ow! Ow! Ow! I'd suggest copying your production data into a development database and then, assuming N is the schema version that the comments you have come from, do: $ rake migrate VERSION=N $ appropriate rdbms commandline all_those_comments.sql $ rake migrate and test like crazy. If it works you can take the production version down for a few minutes and do the same thing with the production database. If it doesn't, it'd be good to know why no. I like the Typo system, I think you fellas are doing great work. Just that a few of us went Woah! when we thought we saw a large bit of new functionality (that not all users would use) get wedged in just after talk of an imminent point release. After all the first line in Trac is Typo is a lean engine... ;) I'm not entirely sure how true that still is. Probably more of an aspiration than a fact on occasions. Keep it fun, but also take some pride in the fact that people are using it and as the number of users grow it speaks volumes about your work. Oh yeah; gaining users is good. Admittedly, the whole More cattle; more care thing rears its head, but but the relationship's more along the lines of O(logN) than O(N), so that's okay. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Sidebars
I love sidebars, sidebars are cool.
I'm less enamoured of our current implementation of 'em, because
they're components and components are slow and a pain in the bum to
test.
With that in mind I've been playing with turning them into plugins
that delegate to a controller for almost everything. The basic parent
might look something like (with lots of handwaving)
class PluggableSidebar
@@subclasses = {}
cattr_accessor :controller
class self
# Keep track of our subclasses and have them keep track of theirs
def inherited; ...; end
def subclasses; ... ; end
def available_sidebars
subclasses.select {|sidebar| sidebar.subclasses.empty?}
end
end
class SetupSidebarFilter
class self
def before(controller)
PluggableSidebar.controller = controller
end
def after(controller)
PluggableSidebar.controller = nil
end
end
end
def method_missing(*args)
if @@controller
@@controller.send(*args)
else
raise NoMethodError, undefined method #{args[0]} for #{self.class}
end
end
def render(*args)
@performed = true
@@controller.render_to_string(*args)
end
def performed?
@performed || false
end
def configuration_wrapper
with_include_path(self.class.view_path) do
configure
render :partial = configure, :locals = {sidebar = self} unless
peformed?
end
end
def index
with_include_path(self.class.view_path) do
content
render :partial = content, :locals = {sidebar = self} unless
peformed?
end
end
end
Lots of stuff missing, obviously, but the basic goal is to turn
the Sidebar parent class into something that *feels* like a controller
to someone writing one, but which can be called with a helper without
having to go through the rather heavyweight process of rendering a
component.
Also, I want to be able unify the current Sidebar and
SidebarController classes in such a way that a Sidebar can be
serialized to YAML and stored on the blog object, and in a
:staged_sidebars key in the flash.
Thoughts?
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Sidebars
Scott Laird [EMAIL PROTECTED] writes: This looks pretty reasonable, at least in principal. Care to providean example of what one of the existing sidebars would look like, andhow the sidebar views fit into the picture? Okay, here's how I hope to make the amazon controller work: Given a basedir of RAILS_ROOT/vendor/plugins/pluggable_controllers/ we would have: lib/amazon_sidebar.rb class AmazonSidebar PluggableSidebar # self.display_name defaults to self.short_name.ucfirst, so no need # to implement it here because short_name defaults to 'amazon' def self.description Adds sidebar links to any amazon books linked in the body of the page end # config_accessor defines an attr accessor with a default. # Could possibly have it take enough information that the nice form # helpers that rails provides can build a config form automagically, # but that's for later config_accessor :associate_id, :default = 'justasummary=20' config_accessor :maxlinks, :default = 4 config_accessor :title,:default = 'Cited books' # default initializer works like the standard ActiveRecord::Base # initializer, so the admin controller can do things like: # sidebar_class_for[0].new(params[actives][0]) # self.default_config -- no need to implement, we just # AmazonSidebar.new will set the correct defaults. attr_accessor :asins def content self.asins = params[:contents].to_a.inject([]) do |list, item| list | item.whiteboard[:asins].to_a end.compact[0, self.maxlinks] if asins.empty? render :text = '' end end def configure end end views/amazon/_content.rhtml # possibly content.rhtml % unless sidebar.asins.blank? -% h3%=h sidebar.title %/h3 div id='amazon_links'%= render :partial = 'link', :collection = sidebar.asins % /div % end -% views/amazon/_link.rhtml iframe src=...asins=%= asin %...t=%= sidebar.assoc_id % views/amazon/_configure.rhtml labelAssociate ID/label %= text_field_tag sidebars[][associate_id], sidebar.associate_id %br / labelMax links/label %= text_field_tag sidebars[][maxlinks], sidebar.maxlinks %br / labelSidebar Title/label %= text_field_tag sidebars[][title], sidebar.maxlinks % The thinking here is admin/sidebar has a single form, ordering gets sorted out by drag'n'drop without having to keep sending stuff back to the server, 'publish changes' then just submits a single form. Also, the superclass's configure_wrapper needs to add a hidden id='sidebars[][class]' value='AmazonSidebar'/ as part of its pseudo layout. Even if we can't make admin/sidebar into a single form view, the _configure partial really doesn't need to set its own form up... Implementing this won't necessarily be straightforward, and it won't happen overnight, but there's *far* too much DRY violation going on with sidebars at the moment. Things like layouts to set the config form up can be implemented independently of any larger changes. -- Piers Cawley [EMAIL PROTECTED] Ãhttp://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent Multi-Blog update Breaks
Scott Laird [EMAIL PROTECTED] writes:
[Wow, that was ugly. I've never really tried pasting code into gmail
before. Let's see if this works]
Heh. Easy. Since we're single-threaded, we can just do:
def perform_action_without_filters
scope_for_content = {:find = {:conditions = blog_id =
#{this_blog.id}},
:create = {:blog_id = this_blog.id}}
Content.with_scope(scope_for_content) do
Article.with_scope(scope_for_content) do
Comment.with_scope(scope_for_content) do
Trackback.with_scope(scope_for_content) do
Page.with_scope(scope_for_content) do
$blog_id = this_blog.id
super
end
end
end
end
end
class Content
def initialize
...
self.blog_id = $blog_id
end
end
Should work. It's horrifically ugly, but it should end up working.
If we're happy with monkeying with undocumented methods, then it's
better to just avoid the global and do:
class Content
def initialize(attributes = {})
attributes.reverse_merge!(scope(:create)) if scoped?(:create)
super(attributes)
end
end
I'm not really advocating doing it this way, but it's probably the
shortest path to working multi-blog support. It's also the shortest
path to madness, but we might be able to extract it into something
less evil.
See above. I'll have a crack at doing a spike with this approach
tomorrow (well, later today, after I've been asleep for a bit).
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Sidebars
Scott Laird [EMAIL PROTECTED] writes: I'd really, *really* like to find a way to keep the sidebar code and views bundled together in the same directory structure. From what I can see here, you're breaking the two apart as a sort of natural consequence of dropping components. Can we please find a way to stick them back together? Ah... now I was deliberately trying to reflect the same structure as the rest of rails; there's nothing to stop us having a structure like: vendor/plugins/pluggable_sidebars/sidebars/amazon: amazon_sidebar.rb _content.rhtml _configure.rhtml ie, just have 'em sat side by side. It's all in how you implement 'with_include_path' Hmm... I think this might be the way to go, that way we can sling extra sidebars around as simple tarballs that can go pretty much anywhere in the include path. I can imagine a day when complex sidebars get their own gem installation and you either include them with environment.rb or do ./script/generate sidebar foo which copies the appropriate files from the gem directory and dumps 'em in your vendor/plugins/pluggable_sidebars/sidebars directory where they'll get picked up by init.rb Of course, YAGNI applies, so I'll not actually implement that until someone demonstrates a need for it, but it does give us a potential route to letting people distribute sidebars rather neatly. Another possible layout for the sidebar's directory gos something like this: amazon/amazon_sidebar.rb /views/_content.rhtml _configure.rhtml /tests/test_amazon.rb Especially handy if we can write a test_sidebars task that will run those tests. In other words, it's all up in the air, I haven't implemented anything yet, so now's a good time to think about what the API is going to be like. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Ajax in Sidebar Plug-in Admin Interface
Chris Saylor [EMAIL PROTECTED] writes: I would like to do drag and drop ordering of information in the admin section of a plug-in. I tried to define the update method in the plugin controller, but ajax was unable to call it. Anybody have any ideas on how I can get this to work. Here is a link to some code. http://rafb.net/paste/results/I5f5nJ15.html Right now I'm just trying to get the standard scriptaculous example to work. I'm not even trying to save the data yet into the config var. Does scriptaculous let you do nested drag and drop? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Mmm... higher order code
Mmm... I love this programming language.
I've just written the following:
def perform_action_without_filters
scope_hash = {:find = {:conditions = blog_id = #{this_blog.id}},
:create = {:blog_id = this_blog.id}}
blog_scoped_model_classes.inject(lambda {super}) do |block, klass|
lambda { klass.with_scope(scope_hash, block) }
end.call
end
And I fully expect it to work. Do you think I've spent to long
programming in lisp?
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] admin settings not sticking
Jack Schwarz [EMAIL PROTECTED] writes: I recently updated to the latest revision [935] and now I am unable to make comments or make changes to my admin settings. Commenting gives me an Input/output error. All options in my settings are checked and I am unable to turn any of them off. I am currently running MySQL 4.1.13. Hmm... so they're not. I wonder how we broke them. (And more to the point, I wonder why the tests didn't find the error.) I (or someone who beats me to it) shall investigate. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] more migration problems
Matt Rose [EMAIL PROTECTED] writes: I tried upgrading my dev environment to 946 from 876 and I get this error when I fire up r946 ActiveRecord::StatementInvalid in Articles#index Mysql::Error: Table 'typo_dev.blogs' doesn't exist: SELECT * FROM blogs LIMIT 1 So I thought, OK, I'll migrate my db by hand So I go into my rails dir, and I type rake migrate, and I get this. [EMAIL PROTECTED]:~/rails/typo$ rake migrate (in /home/mattrose/rails/typo) rake aborted! Mysql::Error: Table 'typo_dev.blogs' doesn't exist: ALTER TABLE blogs ADD settings text (See full trace by running task with --trace) I ran the trace, but it just gave me the same glaring error. My r876 rev didn't have the blogs table. am I missing a step here, or should the migration include a step that creates that blogs table. It does. In migration 38. You've not rolled your own migration 38 have you? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Rails 1.1?
Jon Gretar Borgthorsson [EMAIL PROTECTED] writes: I'm pretty sure that there can be a way to accommodate both. And some things can probably be solved by asking users to install a specific plugin if using version 1.1 or 1.0. But starting to use 1.1 only at some point will enable the use of the new features in 1.1. I like many of them like the new has_many :through and RJS. I think 1.1 features could actually shorten the typo code considerably. Oh ghod yes! I so want has_many :through. And polymorphic associations wouldn't go amiss either, though that's less of an issue now we're using a contents table rather than separate tables for articles, trackbacks and comments. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] The rails_1_1 branch
Okay, who wants to be on the bleading edge? If you've been watching the typo trac[1], you'll have seen that we now have a rails_1_1 branch. If you've been watching carefully, you'll be aware that we think we've ironed out the bugs and it works for both Rails 1.1 and 1.0 with the following caveat: * Under Rails 1.0 it's a wee bit fragile in development mode; if you interrupt a request before it's finished, you'll get a white screen of death However, from the testing I've managed to give it, it seems to be reasonably bulletproof under Rails 1.1 in both development and production mode, and under Rails 1.0 in production mode. Since a lot of you are using production mode, you probably won't see the 1.0 problems. So, before we merge the branch back onto the main line and call it done, we'd appreciate bug reports and 'no bug' reports from as many people as possible. The magic incantation to run from your typo base directory is $ svn switch svn://typosphere.org/typo/branches/rails_1_1 If you don't have your typo repository under svn control, you can check it out using: $ svn co svn://typosphere.org/typo/branches/rails_1_1 target_directory If you're running Typo 2.6.0, you'll need to freeze rails 1.0 in your vendor directory; I'm afraid we're unlikely to go back and fix it to work with Rails 1.1, but if anyone has a patch. 1. http://www.typosphere.org/trac/timeline -- a good place to start -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] 1.1 or 1.0, choose now!
After further testing of the rails_1_1 branch, it seems I was rather to sanguine about how well it works with Rails 1.0. Essentially, it doesn't, I don't know why, and working out why is going to be HARD. So, we're faced with a choice: we can move the typo trunk to a point where we *require* Rails 1.1, or we can wait until we come up with a fix for 1.0. My gut feeling (especially given the speed with which the hosting companies have made the switch to 1.1) is that we should just move over to requiring 1.1 as soon as possible; there's lots of goodies in there that I want to use for typo; we'd probably be going to 1.1 only pretty swiftly any way. If we do this, we'd tag revision 971 (the current trunk HEAD) as 'good_with_1_0' or something and just move on. What does the panel think? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] 1.1 or 1.0, choose now!
Piers Cawley [EMAIL PROTECTED] writes: After further testing of the rails_1_1 branch, it seems I was rather to sanguine about how well it works with Rails 1.0. Essentially, it doesn't, I don't know why, and working out why is going to be HARD. So, we're faced with a choice: we can move the typo trunk to a point where we *require* Rails 1.1, or we can wait until we come up with a fix for 1.0. My gut feeling (especially given the speed with which the hosting companies have made the switch to 1.1) is that we should just move over to requiring 1.1 as soon as possible; there's lots of goodies in there that I want to use for typo; we'd probably be going to 1.1 only pretty swiftly any way. If we do this, we'd tag revision 971 (the current trunk HEAD) as 'good_with_1_0' or something and just move on. What does the panel think? Actually, we might not have to choose. The latest patch on the rails_1_1 branch seems to be *substantially* more robust in Rails 1.0 development mode. And it's conceptually nicer too. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Towards 4.0.0
So, I've been looking at the roadmap, and as far as I can tell we have two show stoppers: 1. #725 -- the cornered rat issue I am not prepared to push the real 4.0 until is substantially easier to install than it is right now. We *must* provide both easy initial installation and easy migration for people currently on 2.6.0. 2. #746 -- It must work with 1.1 Something of a no brainer really However, if at all possible, we want a 2.6.0 user to be able to something like this sequence of steps: 1. Upgrade to Typo 4.0.0 2. Check everything's working. 3. Upgrade to Rails 1.1 4. Check everything's working Requiring to independent upgrades before the user has a working blog is probably not a good idea. The current rails_1_1 head seems to work with both 1.1 and 1.0 now, certainly in production mode, so that's probably for the best. However, until 4.0.0 is out, I think we really need to do our level best to retain dual compatibility. I'm happy to push pretty much everything else on the 4.0.0 milestone on to the 4.1 milestone. Also, as soon as we've got the rails_1_1 branch merged back into the trunk I want to cut a typo-4.0.0_for_daredevils tarball which can continue to suffer from the cornered rat problem, but which will work with 1.1 Again, I'm interested in everyone's input, but I'm particularly keen to hear from anyone still running 2.6.0. We're also looking into working out an appropriate incantation to shove in 2.6.0's environment.rb which will force it to use the 1.0 gems if they're installed, so hopefully we'll be able to make a 2.6.1 that you can just untar over your 2.6.0 installation and, so long as you still have your old gems kicking about (and most hosting services will do) everything will continue to work. If anyone *knows* the appropriate incantation and has tested it, a patch would be enormously welcome. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Freelance developer
Denis Lamotte [EMAIL PROTECTED] writes: Hi Piers, i'd like to know if you are available to work on multiblog hosting solution based on Typo. I know that you already build it when replacing the setting withe the blog object. All work can of course be used for typo afterwards. so working on typo and beeing paied can be nice , no? if you have some time free 2-3 days a week , can you send me your tariff, day/work, hour/work and the way you want to work. I'll send you a mind map (freemind on mac os x) with the requested features to develop ( essentielly multiblog with central commenting modération, multi role user with blog assignement, a small media center and a global aggrgation portal for all blog) If the agency accept the work, the wark will begin very soon, like next week. Somehow, I don't think you expected this to go to the list. Sadly, I don't really have the free time at the moment; I'm committed to another client for at least the next month. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] How to lock Typo to Rails 1.0?
Kevin Ballard [EMAIL PROTECTED] writes: It's not exactly MIA. There's a link there that leads you to typosphere.org/trac/ which is identical to the old typo.leetsoft.com. It's just that we wanted to build a nicer site around typosphere and currently there's been no progress (that I'm aware of, at least) on this regard. I'm not even sure what the concrete plans are for this. Piers? Scott? Tobias (if you're listening)? I had vaguely thought of having a front paged, multi-authored typo blog. Use static stuff in the sidebar to link into the trac and elsewhere and generally keep people informed. Plus, eating your own dogfood never hurts. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The rails_1_1 branch
Kevin Kubasik [EMAIL PROTECTED] writes: Sorry, some of that seems to have been leftover processes, oops A proper restart reveils a small issue under 1.1 with the content admin pages: Kevin, *please* format your mail to around an 80 column line wrap. Your mail is the next best thing to unreadable. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The rails_1_1 branch
Kevin Kubasik [EMAIL PROTECTED] writes: My most sincere apologies, that last one was sent over a remoteconnection, I hope this has fixed it. Nope. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The rails_1_1 branch
Jason Bainbridge [EMAIL PROTECTED] writes: Piers Cawley wrote: Okay, who wants to be on the bleading edge? Well after a bit of grief with forcing Rails to use the production environment after the Rails upgrade I have gotten this to work, for the most part it works fine but the AJAX commenting does something weird with the sidebar and makes it repeat on the other side at the bottom. How peculiar. If you leave a comment on one of my posts at http://typo.jasonbainbridge.com then you'll see what I mean, is that just a theme related issue or something within typo? I think it's the theme. It doesn't seem to be replicated here, using the Azure theme. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The rails_1_1 branch
Dean Strelau [EMAIL PROTECTED] writes: I had the same thing happening to me. In app/controllers/articles_controller.rb change layout :theme_layout, :except = [:comment_preview, :trackback] to layout :theme_layout, :except = [:comment, :comment_preview, :trackback] Not necessarily a good fix. Rendering a partial (which is what we do for ajax comment additions) shouldn't use the layout anyway. And for none ajax comments you need to render with the layout. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The rails_1_1 branch
Kevin Kubasik [EMAIL PROTECTED] writes: oops, a few minutes behind this one works for me now. Yup. Someone on IRC had the same problem and we tracked it down. Since gmail does such a lousy job with trackbacks, you might be best served in future by dumping the error output in the pastebin (http://rafb.net/paste) and simply pasting the resulting url into your message. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] 1.1 or 1.0, choose now!
Codeblogger [EMAIL PROTECTED] writes: 2006/3/30, Kevin Ballard [EMAIL PROTECTED]: The next release is 4.0 (we're skipping 3.0 to avoid confusion with a CMS called Typo3) and we're gearing up to release it in the very near future. Which is also very awkward because they just released their version 4 of Typo3. Well, I can't help it. ;-) Are they still calling it Typo3? Or are we going to get a switchtoweresque cease and desist order? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Towards 4.0.0
Rodger Donaldson [EMAIL PROTECTED] writes: On Thu, Mar 30, 2006 at 09:29:48AM +0100, Piers Cawley wrote: Again, I'm interested in everyone's input, but I'm particularly keen to hear from anyone still running 2.6.0. Last time I tried a rake migrate on my test box it was a disaster area; I'm quite happy to do a dump of my prod 2.6 DB into a dev DB and redo if that will provide useful debugging. That would be handy. We're rather more confident of the migration routes now that we use BareMigrations. Essentially, all the migrations are now protected from changes in our model classes. I'm less confident of the automigrate from a pre blog object to the current schema though. My site theme, which is based off one from the competition, didn't work, but I don't see that as something that the developers need to worry about, except perhaps by providing some documentation around what's changed that requires theme changes. Actually, I'm about to have a crack at adapting one of the competition themes to the trunk myself. Since I can't quite remember what *has* changed, I shall keep notes as I make the changes (or at least run diff on the results and extract instructions from there). -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] how does typo produce feed urls with .xml suffix?
Stephen Bannasch [EMAIL PROTECTED] writes: I'm pretty new to Ruby and Rails and I like to be able to create urls with an extension suffix similar to how Typo does this for the feed urls. However I need a bit of help understanding how this works in Typo. The Sidebar 'Articles' feed is generated here: components/plugins/sidebars/xml/content.rhtml with this script fragment: %= url_for :controller='xml', :action='feed', :format = @sb_config['format'], :type = 'trackbacks' % In my case @sb_config['format'] == 'rss20' and it produces urls in the following form: http://localhost:3000/xml/rss20/feed.xml config/route.rb processes this url with this map: map.xml 'xml/rss', :controller = 'xml', :action = 'feed', :type = 'feed', :format = 'rss' So clicking on the link runs XmlController#feed in apps/controllers/xml_controller.rb. Which calls the renderer at views/xml/rss20_feed.rxml (and a partial) which actually generates the xml feed. I've discovered that if I take out ':format = @sb_config['format']' from the url_for link the '.xml' suffix is no longer generated but I'm having trouble going further. The magic's all in config/routes.rb Notice that we add the .xml extension there. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] how does typo produce feed urls with .xml suffix?
Stephen Bannasch [EMAIL PROTECTED] writes: Stephen Bannasch [EMAIL PROTECTED] writes: I'm pretty new to Ruby and Rails and I like to be able to create urls with an extension suffix similar to how Typo does this for the feed urls. However I need a bit of help understanding how this works in Typo. The magic's all in config/routes.rb Notice that we add the .xml extension there. Hi Piers, I see it now. These lines match feed urls with .xml at the end and route off to the feed action in XmlController. map.xml 'xml/:format/feed.xml', :controller = 'xml', :action = 'feed', :type = 'feed' map.xml 'xml/:format/:type/feed.xml', :controller = 'xml', :action = 'feed' map.xml 'xml/:format/:type/:id/feed.xml', :controller = 'xml', :action = 'feed' That's one half of the answer -- the other half I'm still confused by. How do the original displayed feed urls in components/plugins/sidebars/xml/content.rhtml get rendered with the .xml suffix? Routes are a two way thing. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] r822 to r983 migration failing
Gary Shewan [EMAIL PROTECTED] writes: Okay the last version of trunk I was sitting on was r822. I thought I'd embrace 1.1 fully and push up to r983. Running rake migrate throws out these errors: ** Invoke migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute migrate Adding display name to tags Ah! It's about to be fixed, the migration didn't use a BareMigration. I caught it on my big trawl through the migrations fixing things for sqlite. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] r822 to r983 migration failing
Gary Shewan [EMAIL PROTECTED] writes: On 1 Apr 2006, at 22:03, Piers Cawley wrote: Gary Shewan [EMAIL PROTECTED] writes: Okay the last version of trunk I was sitting on was r822. I thought I'd embrace 1.1 fully and push up to r983. Running rake migrate throws out these errors: ** Invoke migrate (first_time) ** Invoke environment (first_time) ** Execute environment ** Execute migrate Adding display name to tags Ah! It's about to be fixed, the migration didn't use a BareMigration. I caught it on my big trawl through the migrations fixing things for sqlite. That was a very smooth and successful migration from r822 to r984. Good man Piers! Thank heavens for that. By all rights I should never have checked that big migration patch in when I did; I'd been working on it for about 8 hours straight, then rushed straight out to the pub, sang myself hoarse for a couple of hours and the next day was my weekly NO COMPUTERS! day. Sometimes arrogance pays off I guess. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Last n comments sidebar?
Gary Shewan [EMAIL PROTECTED] writes: I've searched and haven't seen anything, but has anybody had a bash at a 'Last n comments' sidebar? Mmm... nice idea. Write a story for it and stick it on the trac. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] NoMethodError (Blog:Class) error in production log
Gary Shewan [EMAIL PROTECTED] writes: This error keeps cropping up in my production log. I don't know if it's contributing to any flakyness. Anybody any clues? Production? Weird. When we've had problems with missing methods on a class before it's been because the class didn't get reloaded properly, which obviously isn't the case here. Er... -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo and Rails 1.1.1
Kevin Ballard [EMAIL PROTECTED] writes: Uhh, Typo trunk has been running on Rails 1.1 for some time now. If you check out HEAD you'll even get rails 1.1 extracted into your vendor dir (through the magic of svn:externals). You'll probably get 1.1.1 now. We're using branches/stable as the external target. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] svn problems...
Kevin Kubasik [EMAIL PROTECTED] writes: Apperently it doesn't (exist) any more. They just recently added a new tag/branch set for 1.1, (according to the svn log). Maybe they wiped the 'stable' branch accedentaly. Someone wanna send an e-mail to their list? BWAH! There I was, carefully setting the thing up so that it tracked the stable version, and making sure that the trunk would break nice and early, and they go and remove the branch! What's a developer to do? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] The sidebar issue in HEAD
Sorry for any problems you've been experiencing folks. I'm trying to get sidebars to a point where we can test them automatically, which will hopefully mean that problems like you've been experiencing will be a thing of of the past. I am, however, reasonably confident that, with the current trunk (r999 and above), and starting from an empty sidebars table[1] you should be able to populate your sidebar quite happily from the standard sidebar set and have your changes saved without any problems. If anyone is still having problems with core sidebars, starting from an empty sidebar, then please start a ticket in the trac[2] with as much information as possible including log traces and exactly what it was you were trying to do. I'm afraid my time to work on this is somewhat limited all of a sudden; I've just had a big influx of paying work that's eating into my time -- instead of having three or four days a week to work on typo I'm going to be lucky to grab one or two for the next while. 1. You can empty your production sidebars table by doing: $ ./script/runner -e production 'Sidebar.delete_all' If you're running in development mode, replace 'production' with 'development' and it should purge the table. However, only do this if you've got problems with your current sidebar set. 2. http://www.typosphere.org/trac -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Engineering sidebars
On IRC just now, someone was describing a navigational sidebar that they were trying to write. The idea sounded really cool, but in order to make it work well, he was going to have to write a 'first class' controller to handle menu expansions in order to retain the menu's state. Which meant he'd have to put something into typo's app/controllers directory. Which is something we'd been trying to avoid in the design of the sidebar system. Meanwhile, in another project, I've been using a Rails Engine[1]. The rails_engines plugin is a cunning plugin which enables writing plugins that, in essence shadow the main application's tree, complete with their own controllers, models, lib, views, tests... Which sounds like a perfect match for the kind of sidebar this person was trying to write (and the techniques used to make engines go looked like they might enable some seriously powerful themes, but that's definitely in the blue sky category). The catch is, having a full engine for each sidebar is definitely overkill. So, I'm thinking of investigating pulling our current sidebar system out into a 'typo_sidebars' engine, with the goal of having a vendor/sidebars directory into which you would drop 'simple' sidebars consisting of a SidebarPlugin based controller and 'configure' and 'content' views (Actually, I think it's not beyond the bounds of possibility to have the configure view be entirely autogenerated from metadata). More complex sidebars could then make full use of engine capabilities by being distributed as engines in their own right. Has anyone had much experience working with rails engines? Thoughts? 1. http://rails-engines.org/ -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] The sidebar issue in HEAD
Piers Cawley [EMAIL PROTECTED] writes: Sorry for any problems you've been experiencing folks. I'm trying to get sidebars to a point where we can test them automatically, which will hopefully mean that problems like you've been experiencing will be a thing of of the past. Oops, guess who forgot to run svn add? No wonder I couldn't replicate the issue. Fixed in r1001 I hope. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] I dance the dance of happy!
Here's the commit notice from revision 1004: Sing, muse the joy of pdcawley as he puts the monstrosity article_url and all its spawn to his sure swift sword and casts the tiny pieces down, down, ye even unto the very depths of The Pit. Bear witness as Content#full_html returns to the fray, trailing clouds of glory, renewing the vigour of old themes left withering in the TypoGarden. For, verily, I have returned the sensible API to its rightful place. (Oh, and if you must use them, article_url et al. will continue to work for the forseeable future, but I will insist on treating them like red headed stepchildren.) Which is, arguably, a little bit over the top, but I've been longing to get rid of article_url since the very moment we introduced it. The old 'content_object.body_html' was just so much neater. But, once we introduced a proper blog object, we had somewhere to hang the active controller, so that's what I did. The Blog class is now an around_filter called by the controller, so, for the duration of a request, Blog (and hence any of its instances) know what the controller is. And our content objects know what the blog is. So Content#full_html now looks roughly like this: def full_html html(blog.controller, :all) end (It raises a slightly more informative error if there's no active controller, of course). Also, an article (and eventually other content subclasses) can now tell you its url by asking the blog, which asks the controller. Once all the content types are asking the blog for their url we can start using the blog as a place to store url policy. Why is that useful you may ask? Well, I was chatting on IRC to someone who was converting a large wordpress blog and he was looking at writing the thick end of 1500 redirect rules because wordpress urls look like: http://someblogger.com/blog-entry But ours look like http://sometypoblogger.com/articles/2006/04/09/blog-entry So, instead of writing a generic route that catches all of his articles, he has to write a redirect for each one. But wouldn't it be cool if we could have a 'url_style' setting on the blog, so if you want wordpress style urls you get 'em, if you want dateless permalinks, you get those. The routing table would (obviously) have to handle all (most) cases, but all our generated links would respect the blog's link style. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Application error (Rails) on site navigation
Jack Schwarz [EMAIL PROTECTED] writes: Hi all, Just updated to [1004] and am getting an Application error (Rails) when navigating my page. Navigation of the admin interface works just fine. After a little more investigation it seems that some themes give errors while others do not. Azure, of course, works fine. Ah... I was intending to retain backwards compatibility with themes that worked with the old (new) API. D'you have a log trace? Also, if the theme in question is downloadable somewhere I'll be happy to test against it. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Fixing broken themes
Some time ago (I thought it was in pre 2.6.0 days, but apparently not), we added a 'render_sidebars' helper method, so that theme authors wouldn't have to go typing: %= render_component(:controller = 'sidebars/sidebar', :action = 'display_plugins' % in their themes. It also had the advantage of encapsulation; if theme authors used 'render_sidebars' then we could change the details of how sidebars got rendered with impunity and we wouldn't break any compliant themes. And, in revision 1003, we did exactly that. Except, it turns out that an awful lot of themes aren't compliant. So, if your theme is playing up with recent trunk rails, you need to look in your /themes/whatever/layouts/default.rhtml, find the part that renders the sidebar using render_component, replace it with %= render_sidebars %, sit back and take quite satisfaction in the wonder that is encapsulation. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Application error (Rails) on site navigation
phil [EMAIL PROTECTED] writes: On Mon, 10 Apr 2006 12:36:40 -0500, Jack Schwarz [EMAIL PROTECTED] wrote: Piers was nice enough to help me out with this one. I will post the solution below incase anyone else is having trouble. Some themes (Scribbish in particular) were giving me Rails errors when rendering pages. This was the the fix: Change the line in /layouts/default.rhtml that reads %= render_component(:controller = 'sidebars/sidebar', :action = 'display_plugins') % to read %= render_sidebars % Nice, now is there an easy way to fix searching in Scribbish? Errr. I haven't touched the search... -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] jabber_notify.rb error
George Sudarkoff [EMAIL PROTECTED] writes: I keep getting this error. Any ideas as to why this is happening? I am running r977 (don't have time to update). Can someone please just dike the entire jabber notification subsystem out? We'll start again from clean after 4.0. I'd do it myself, but I'm stuck doing paing work at the moment. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] jabber_notify.rb error
Piers Cawley [EMAIL PROTECTED] writes: extra understanding from the first, failed solution. As I've explained in my blog[1], I'm not totally averse (but getting more averse by Oopsie. Forgot the footnote. Here it is: 1. http://www.bofh.org.uk/articles/2006/03/12/if-you-test-it-i-will-patch -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] jabber_notify.rb error
Trejkaz [EMAIL PROTECTED] writes: On Friday 14 April 2006 01:36, Piers Cawley wrote: George Sudarkoff [EMAIL PROTECTED] writes: I keep getting this error. Any ideas as to why this is happening? I am running r977 (don't have time to update). Can someone please just dike the entire jabber notification subsystem out? We'll start again from clean after 4.0. I'd do it myself, but I'm stuck doing paing work at the moment. Alternatively could someone commit my patch which makes it all work? It's been on the trac for quite some time now. The main problem I have with the whole Jabber notification scheme is that it's almost entirely test free. I prefer to view what's in place as a spike, throw it away and start again test first with the benefit of extra understanding from the first, failed solution. As I've explained in my blog[1], I'm not totally averse (but getting more averse by the day) to committing changes without patches, but only when those changes are 'mine' because then I've at least got a chance of remembering my intent. Which is why I haven't committed the big podcasting patch either -- It's screaming out for a couple or three integration or functional tests to stand as an explanation of what the patch does. Without that, I haven't the faintest idea if what the patch does is the right thing, or just what it does. Show me tests and you show me what you intend. The main problem is that Typo went with Jabber4R, which is buggy. Replace that with XMPP4R, and everything works fine. I just checked, and there's a licensing problem with XMPP4R as well, which means we can't include it in the Typo distribution without changing Typo's license, which I'm not prepared to do. And I'm not prepared to add an external dependency either. Give me a patch, with tests, that degrades gracefully (it can simply turn jabber notification off) if the absence of XMPP4R and I'll jump at the chance to apply it. Until then, I'd far rather see it taken out for 4.0 rather than ship broken code. P.S. If you're going to throw out Jabber notification, please throw out email notification too. I only use the Jabber one, after all, and can't imagine why anyone would want to be notified via email. ;-p Meh! I just use the feed... -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] HTML structure
So, I've been looking at Scribbish[1] and the CSS Zen Garden[2] and I like what I see. In particular, I like the idea of the hAtom microformat for our articles, and I really like the idea of making sure we have a robust semantic structure for our core HTML. Every time someone has to write rhtml in their themes I cringe slightly. So, I'm thinking that the whole Theming thing needs looking at. Here's a few ideas: * No more overriding layouts/default.rhtml just to add a couple of theme specific css files. We've already moved to having most of the layout's header generated by a helper method, it should not be beyond our wit to have it do something like: %= render :partial = 'common/stylesheets.rhtml' % as part of its strategy. * Nail down the basic semantic structure of our layout and have more of the individual divs rendered as partials (and hence more finely overrideable by a theme). Also, the 'partial' boundary might well be a good place to insert more granular fragment caching for better performance. * Make use of the hAtom microformat (and possibly other microformats for other bits and pieces, is there one for tag clouds yet?) * Get some feedback from (or become) CSS experts with an eye to designing a basic page structure that's flexible enough that most themes can simply provide a css file and a bunch of images. Check out the CSS Zen Garden for the sort of thing that has been achieved with 'pure' CSS. * As we're breaking themes already, let's break 'em good and proper so we can rebuild them stronger, better, faster... Thoughts? 1. http://quotedprintable.com/pages/scribbish 2. http://csszengarden.com/ -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] HTML structure
Gary Shewan [EMAIL PROTECTED] writes:
On 14 Apr 2006, at 07:05, Piers Cawley wrote:
* No more overriding layouts/default.rhtml just to add a couple of
theme specific css files. We've already moved to having most of
the layout's header generated by a helper method, it should not be
beyond our wit to have it do something like:
%= render :partial = 'common/stylesheets.rhtml' %
as part of its strategy.
* Nail down the basic semantic structure of our layout and have
more of the
individual divs rendered as partials (and hence more finely
overrideable by a theme). Also, the 'partial' boundary might well
be a good place to insert more granular fragment caching for
better performance.
* Make use of the hAtom microformat (and possibly other microformats
for other bits and pieces, is there one for tag clouds yet?)
* Get some feedback from (or become) CSS experts with an eye to
designing a basic page structure that's flexible enough that most
themes can simply provide a css file and a bunch of images. Check
out the CSS Zen Garden for the sort of thing that has been
achieved with 'pure' CSS.
* As we're breaking themes already, let's break 'em good and proper
so we can rebuild them stronger, better, faster...
Thoughts?
I don't understand what you're getting at here ... at all. And I've
tried.
Bah! You obviously haven't tried hard enough!
Breaking themes has nothing to do with CSS. Rendering a sidebar has
nothing to do with CSS, rendering the content has nothing to do with
CSS. I could put my CSS on a wordpress install and it would look the
same (after renaming my divs). That's the whole point of CSS - it's
just the styling.
My theme was broken because I had to change
%= render_component(:controller = ‘sidebars/sidebar’,
:action = ‘display_plugins’ %
to
%= render_sidebars %
in default.rhtml and that has nothing to do with how pretty my site
looks (CSS) but how the sidebar is rendered (Typo code).
Separate CSS and HTML in your mind.
Pointy end grandma.
Why would you want to stop a themes overriding default.rhtml (if
that's what you mean)? As that's a nice feature.
I want to stop every theme and its brother *having* to override
default.rhtml. It's a 'nice' feature, but we're definitely cracking
nuts with sledgehammers if we end up overriding default.rhtml just
because we want to change a stylesheet.
If we have a default (rails) layout that goes something like:
!DOCTYPE html Blah Blah
html xmlns=http://www.w3.org/1999/xhtml;
head
%= render :partial = 'common/html_head' %
/head
body id=%= params[:controller].gsub('/', '-') %
div id=header
%= render :partial = 'common/header' %
/div
div id= page
div id=content
%= yield %
/div
div id=sidebar
%= render :partial = 'common/sidebar' %
/div
br style=clear:both; /
/div
/div
div id=footer
%= render :partial = 'common/footer' %
/div
/html
And make the various 'common/*' partials overrideable by the theme,
then we're already in the position that a theme designer can alter the
structure of the various divs without having to repeat a bunch of
boilerplate.
Why are you talking about nailing down a basic structure of the
layout? That's for a theme designer to do surely?
No, I'm talking about nailing down the basic structure of the HTML we
generate. Layout is done with CSS. The problem here is that the Rails
concept of a layout clashes with the CSS concept of a layout. It's
awfully easy to get the two confused (and my original post wasn't a
model of clarity in this respect, for which I apologise).
Take a look at the sort of thing that's achievable using nothing but
CSS styling over at the CSS Zen Garden. My goal here is to have our
default theme consist of nothing more than a couple or three
stylesheets and have our basic, unthemed output be structurally sound
enough that the majority of themes can do the same. At the very least
we need to make sure that our unthemed output (including the core
sidebars, which means I need to take a look at the Amazon contoller)
is fully compliant with XHTML Strict.
I'm lost.
Is it just me? Could be ;)
I readily agree that something needs to be firmed out though because
I'd put money on the fact that nearly every theme in the contest
would be broken in trunk now.
Well, if it uses sidebars, it's broken. And if it wants to use at
least one of the plugins (can't remember which one) that needs a
particular javascript included in the header, it's doubly broken.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Towards 4.0.0
Rodger Donaldson [EMAIL PROTECTED] writes: On Fri, Mar 31, 2006 at 04:51:17AM +0100, Piers Cawley wrote: Rodger Donaldson [EMAIL PROTECTED] writes: On Thu, Mar 30, 2006 at 09:29:48AM +0100, Piers Cawley wrote: Again, I'm interested in everyone's input, but I'm particularly keen to hear from anyone still running 2.6.0. Last time I tried a rake migrate on my test box it was a disaster area; I'm quite happy to do a dump of my prod 2.6 DB into a dev DB and redo if that will provide useful debugging. That would be handy. We're rather more confident of the migration routes now that we use BareMigrations. Essentially, all the migrations are now protected from changes in our model classes. Sure. [walkthrough of a failed upgrade elided] Ack. So, I guess the DownloadCurrent page needs to note the dependency on rails 1.1 and/or rake 0.7. It's too late to upgrade all of ruby tonight 8). Drat! So it does, I shall get that sorted. We definitely depend on Rails 1.1, but an SVN download should fetch the right version of Rails through the magic of svn:externals. Sadly, we can't quite do the same thing for Rake. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] jabber_notify.rb error
mathew [EMAIL PROTECTED] writes: Anyhow, I think it's pretty funny to be rejecting code based on lack of tests, when there's an almost complete lack of documentation. Huh? Join the non sequitur club, we may not make sense but we do like pizza! -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] HTML structure
Gary Shewan [EMAIL PROTECTED] writes: On 14 Apr 2006, at 15:59, Piers Cawley wrote: I don't understand what you're getting at here ... at all. And I've tried. Bah! You obviously haven't tried hard enough! True I want to stop every theme and its brother *having* to override default.rhtml. It's a 'nice' feature, but we're definitely cracking nuts with sledgehammers if we end up overriding default.rhtml just because we want to change a stylesheet. [...] The dawn of a new day brings clarity :) Mmm... clarity... I like clarity. I can see the benefit of that, definitely. But is it not _almost_ like doing the same thing as overriding default.rhtml ... 'cept in separate files? For instance, let's say I need to place my own meta tags, a custom div and a custom footer. At the moment that all goes in the themes default.rhtml. So in the future I'd have to put the meta tags in 'common/header', and I want the custom div before the content so I'd normally place that just before the content is called in default.rhtml ... would I place that at the top of 'content'? (There would be a 'common/content'?) The custom work for the footer would then go into 'common/footer' - obviously :) Now that's not about CSS. I haven't even styled any changes yet. But is that right? Well, yes, and no. The benefit of overriding your footer in common/_footer.rhtml[1] and your header stuff in common/_sidebar.rhtml etc is that you don't have to copy quite so much crap (that might change, but we hope not) just to make your changes. And we'll probably arrange things so that the default versions will default to include theme/_extra_headers.html and so, assuming you're not making a major structural change, you get to write a partial which *only* has stuff specific to your theme with, with no boiler plate. The aim of the game is to apply the Hollywood Principle[2] to themes. It works well for the rest of Rails, so we should be able to make it work for themes as well. I'm lost. Is it just me? Could be ;) I readily agree that something needs to be firmed out though because I'd put money on the fact that nearly every theme in the contest would be broken in trunk now. Well, if it uses sidebars, it's broken. And if it wants to use at least one of the plugins (can't remember which one) that needs a particular javascript included in the header, it's doubly broken. So yeah ... pretty much every one. I smell a new contest after the release of 4.0 Speaking as someone with the graphic design sense of a teeny tiny kitten, I'd quite like the chance to win a Macbook too. And if there *is* another competition, can we please try and avoid bitterness this time? 1. Partials have a leading _, it's a Rails thing, I'm not entirely sure I understand why. 2. Don't call us, we'll call you -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] uninitialized constant Sidebars::SidebarController
Steve Longdo [EMAIL PROTECTED] writes: render_component was replaced by %= render sidebars % That should fix your problem. You may also want to clear out your sessions table. That's %= render_sidebars % -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Timezones
Syed Uzair Aqeel [EMAIL PROTECTED] writes: As a compromise, how about storing time in UTC and the offset in use when the entry was posted? Or, more acceptable, the timezone code, eg. CST/EST/PDT. Time's a minefield and Timzone codes doubly so. It turns out they're not unique. One of Perl's wins is the work that Dave Rolsky did on the DateTime library (to the extent that every time I work with dates in Ruby I find myself wishing someone had ported DateTime). I'm all for stashing everything in GMT though. However, it's not something I'm going to lose any sleep over fixing; I'm happy enough with our delta based time reporting for comments and the likes. So long as articles are displayed in chronological order I'm pretty happy. Your mileage may vary of course, so patches are welcome. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Timezones
mathew [EMAIL PROTECTED] writes: [a long explanation of why times and dates are hard] As soon as someone ports perl's DateTime[1] (which solves all mathew's issues and more; mathew forgot to mention leap seconds, time deltas where daylight savings is switching over and, oh, a bunch of other stuff) I'll happily switch to using it for Typo's dates. Until that happy day, I'll live with stashing everything as GMT (which may well not be what we do now, but patches welcome) and displaying with simple time deltas. 1. http://datetime.perl.org/ -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] XML renderings...
So, on another project, I've been playing with 'respond_to'[1] and it's *lovely*. I am seriously considering rejigging things so that our index type pages in articles_controller will all be responsible for generating rendering feeds and make the xml_controller simply act as a redirect to the new /articles based urls. Thoughts? 1. http://www.loudthinking.com/arc/000572.html -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Wordpress Mu
marcus estes [EMAIL PROTECTED] writes: From the Lyceum FAQ: Q: What is the difference between Lyceum and WordPress MU? The main difference between Lyceum and MU is the database schema. MU creates a set of tables for each blog in a system. We're definitely not doing that. At all. Ever. Over my dead body. Lyceum uses a fixed number of tables for the entire system. Much more sensible. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] XML renderings...
Scott Laird [EMAIL PROTECTED] writes: On 4/27/06, mathew [EMAIL PROTECTED] wrote: Scott Laird wrote: A couple things: 1. How do we do both RSS and Atom feeds? Ruby XML Builder 2.0 was released recently. It now does automatic escaping. I don't find Atom or RSS to be complicated enough that it's worth using a special purpose library to *produce* them; they're just XML, after all. No, I mean if we move the Atom feed from /xml/... to /articles, anddistinguish between the Atom feed and the HTML feed via the Acceptheader, then how do we feed both Atom and RSS from the same URL? DHH covers this in the article where he introduced them; you munge the request to have an appropriate Accepts and serve up 'application/xml+rss' and 'application/xml+atom' or whatever it is. And ideally we drop Atom 0.3 from our supported list. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] XML renderings...
mathew [EMAIL PROTECTED] writes:
Scott Laird wrote:
No, I mean if we move the Atom feed from /xml/... to /articles,
anddistinguish between the Atom feed and the HTML feed via the Acceptheader,
then how do we feed both Atom and RSS from the same URL?
Why do they have to be from the same URL? I must have missed that
bit.
Here's ArticlesController#index
def index
@pages, @articles =
paginate(:article, :per_page = this_blog.limit_article_display,
:conditions =
['published = ? and contents.created_at ? and blog_id = ?',
true, Time.now,
this_blog_id],
:order_by = contents.created_at DESC,
:include = [:categories, :tags])
end
Which is (with a couple of extra wrinkles, which can be ironed out)
pretty much the same as what /xml/feed does (XmlController is actually
slightly better factored than articles_controller, but it will break
as soon as anyone adds a second blog).
The issue isn't so much to do with serving Atom, RSS, and HTML from
the same URL as it is with serving them from the same controller
action, reducing the amount of duplicated effort in controllers (and
avoiding the current problem where ArticlesController#index is
multiblog safe, but XmlController#fetch_items -- which is what finds
the things to be published -- isn't.
Personally, I'd make /articles be Atom format, and have something like
/articles?format=rss or /articles/rss for legacy RSS support.
Definitely the first rather than the second of those options; that way
a prefilter can grab the format variable and use it munge the
headers. Here's ArticlesController#comment, rewritten to to use
respond_to (and, incidentally, so that it'll work with non ajax
commenting again)
def comment
return unless comment_args_are_valid?
begin
@article = this_blog.published_articles.find(params[:id])
@comment =
@article.comments.build(params[:comment].merge({:ip =
request.remote_ip,
:published = true })
@comment.user = session[:user]
@comment.save!
add_to_cookies(:author, @comment.author)
add_to_cookies(:url, @comment.url)
respond_to |wants| do
wants.js# AJAXy updating
wants.html { display_article @article }
end
rescue
STDERR.puts @comment.errors.inspect
render_error(@comment)
end
end
def comment_args_are_valid?
if ! request.post?
render_error You can't GET a new comment!
return
end
unless @request.xhr? || this_blog.sp_allow_non_ajax_comments
render_error(Please turn Javascript on and try again)
return
end
end
Hmm... you know, I really dislike all those 'render_error(...); return'
things. I'm having bad thoughts... how do you think rails would
react to a prefilter that looked like:
def save_the_continuation
callcc do |continuation|
@filter_continuation = continuation
true
end
# This is where @filter_continuation[some_value] will return to.
# By returning false through this continuation, rails is fooled
# into thinking that your filter chain failed (but any rendering
# you did still gets done...)
end
Then, render_error would look like:
def render_error(object = '', status = 500, [EMAIL PROTECTED])
@text = object.errors.full_messages.join(, ) rescue object.to_s
@status = status
respond_to |wants| do
wants.js # For sensible error reporting of AJAX type requests
wants.html { render :text = text, :status = status }
end
# Make the prefilter return false!
return_point[false] unless return_point.nil?
end
I have the sneaking feeling that that would work rather well... I
shall experiment when I have the tuits.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
[typo] Thinking about caching
I've been thinking about how to get the benefits of page caching back without the pain of the same. It occurred to me that, for a snappy response to 'real' readers, we could probably get away with just caching the first page of /articles, articles/category/whatever, /articles/tag/whatever and so on, along with their associated feeds and the full articles. It's my gut feeling that the vast majority of hits are to the first page of an index, or directly to an article[1]. In order for this to work, we'd have to ensure that none of our links were ever generated in the form '/articles/tag/whatever?some_arg=...', but that's merely tedious, not necessarily a showstopper. However, there are problems with this approach because we've taken advantage of fragment caching to introduce goodies like time limited sidebars and future publication times[2]. One approach to cache sweeping, suggested by Tobi on IRC, is to have each request process fire off a sleeper thread, set to wake up at next expiry time (or in an hour say, whichever is sooner) and zap the cache. Because every dispatch thread would be doing this, it doesn't really matter if one of 'em gets killed before time, and a double expiry's not really a problem either, so what if the cache gets zapped twice, it'll still get rebuilt. Another possibility is to stick a bit of javascript in the default layout that fires off a request to some kind of uncached heartbeat action, so a page may get served up without touching typo (so the the browser gets a fast response) but typo still gets hit 'at leisure' so to speak and can do any posted cache sweeps/publication actions in a postfilter. I like this idea rather less, because it doesn't work for feeds, and it's the sort of suspicious javascript activity that gets apps a bad name. A third option is to have a separate process that gets fired from a cron script or something and handles any cache sweeping required, but I don't think that's going to fly for a lot of people using hosting services. Whatever option gets chosen, I reckon there's a case for unifying the handling of future events. Here's a sketch of a possible approach: class Trigger ActiveRecord::Base belongs_to :pending_item, :polymorphic = true class self def post_action(due_at, item, method='came_due') create!(:due_at = due_at, :pending_item = item, :method = method) fire end def fire destroy_all 'due_at now()' true end end def destroy pending_item.send(method) end end This allows for arbitrary ActiveRecord based objects to post trigger requests. Then application could declare a post_filter that does 'Trigger.fire' at the end of every request. Here's an example of how Article could take advantage of triggers: class Article def before_create Trigger.post_action(published_at || created_at, self, 'publish!') end after_save :ping_on_publication def publish! unless published? self.published = true self.save! end end def published=(publication_state) if publication_state unpublished? @just_published = true end self[:published] = publication_state end def ping_on_publication if @just_published send_notifications end end end (Note that there's no need to do the cache sweeping logic here because the cache sweeper already handles that) We'll have to do some fancy footwork to make sidebars work as pending_items, but there's virtue in making it happen. For instance, an aggregation sidebar could check to see if anything had changed in its target feed and only trigger a cache flush if there was something new. Note too that, with this interface, the cron option is easy -- the commandline to handle everything is: /typo_installation/script/runner -e production 'Trigger.fire' Which seems pretty cute to me. Thoughts? What have I missed? 1. I would really appreciate it if anyone who can be bothered would go through their typo logs and quickly check for the relative frequency of non search engine crawler hits on any index pages after the first. I'm guessing that there's a serious power law curve in effect here. 2. Using the 'created_at' field, which should really, really, really be published_at or some such -- overloading 'created_at' in this way is simply confusing. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Adding fixed content to feeds
Gary Shewan [EMAIL PROTECTED] writes: How easy would it be to add fixed text to the end of each post in the feed? I don't mean in the actual post itself, but automagically inserted on publish - only in the feed. Shouldn't be too hard (but you're going to be repeating yourself a fair bit if you do it for all possible feed types), just add some static content to your app/views/xml/_feed_type_item_article.rxml templates (I think you should be able to do that in your theme directory but I haven't tried it). Making it configurable would be rather more work, which I think I want to put off until Sam Ruby's finished his sterling work on getting our feeds to be compliant. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Google Summer of Code 2006
Oleg Frolov [EMAIL PROTECTED] writes: Hello everyone! I've noticed that Google has Ruby Central as mentoring organization this year and Ruby Central has Contributions to Typo suggestion. So I would like to apply. I believe, for me, it is good opportunity to quit enterprise, contribute to the community and promote myself as Ruby developer. I offer my helping hands (and brain too) to the Typo team. You may find more info on me on http://olegf.name. If you are interested please submit your ideas for my application. I'm new to Typo and I believe Typo developers have more suggestions on what Typo needs. I will try to do my best. I, for one, may suggest internationalization, rails 1.1 supported release (i know it is in trunk, but it's not regular release yet) and a website http://typosphere.org (it is very important to attract more users). I really want to help. The issue for me is mentoring time. I simply don't have the time available to be a mentor. I dunno about the other maintainers. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Adding fixed content to feeds
Gary Shewan [EMAIL PROTECTED] writes:
On 1 May 2006, at 11:00, Piers Cawley wrote:
Gary Shewan [EMAIL PROTECTED] writes:
How easy would it be to add fixed text to the end of each post in the
feed? I don't mean in the actual post itself, but automagically
inserted on publish - only in the feed.
Shouldn't be too hard (but you're going to be repeating yourself a
fair bit if you do it for all possible feed types), just add some
static content to your app/views/xml/_feed_type_item_article.rxml
templates (I think you should be able to do that in your theme
directory but I haven't tried it).
Dear me you think it would be easy, but it isn't. I can kill the
feed compliance by putting a made up tag in (I can live with that
for now). Something along the lines of rights after each item
using
Have you tried doing:
xm.content(type = text/html) do
item.full_html if this_blog.show_extended_on_rss
p('This content gets added to the end of every article')
end
Which seems like it should work to me.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
[typo] Copious Free Time bit enabled
First up: Sorry for all the recent problems with Typo that followed on from a couple of my patches; I've spent the last week insanely busy on paying work which left me too knackered to do anything on Typo in the evenings. However, I'm off that contract now[1] and I plan to spend some quality time with Typo this week. If anyone's looking for an inflexible, scary and slow programmer for some paying work, my email address is down there in the signature, I'd be happy to hear from you. 1. Apparently I'm inflexible, scary and slow. Inflexible? possibly. Scary? Well, I suppose a huge shouty fat person could be seen as scary. Slow? Wha? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Copious Free Time bit enabled
Gary Shewan [EMAIL PROTECTED] writes: On 6 May 2006, at 08:40, Piers Cawley wrote: First up: Sorry for all the recent problems with Typo that followed on from a couple of my patches; I've spent the last week insanely busy on paying work which left me too knackered to do anything on Typo in the evenings. However, I'm off that contract now[1] and I plan to spend some quality time with Typo this week. Don't worry, it only affects people on the edge ... and we're on there to test. In fact I've picked up a couple of issues and learnt a couple of things by diving into files and the db because of it. Trackbacks in particular. Which is not to say that breakage is good though! Because we (me) also point and laugh and say Piers patch has broke it again ;) Yeah, they're usually my patches aren't they? I think I've got a big one coming up to try and sort out the whole publication status/trackbacks/whatever situation. The responsibility for sending pings and the like needs to be moved out into an observer; conceptually, an article doesn't need to know all that stuff about pinging things, it just needs to know what it's called, what it contains, when it was published and what's been said about it. The Blog is responsible for knowing where to find it, and the (as yet nonexistent) PublicationObserver will be responsible for noticing that an article got published and sending out any pings and other notifications based on the blog's policy settings. Big changes, but I think it'll make for a conceptually cleaner system, and conceptual cleanliness is never a bad thing. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Recent problems with posting
Gary Shewan [EMAIL PROTECTED] writes: On 8 May 2006, at 11:56, Piers Cawley wrote: Just checking, are these sorted now? I can't seem to replicate the issues here. Definitely still a problem. You can see what it changes in #847 and every time I post from Ecto it needs me to make a manual change in the db. This isn't a problem posting from the admin area ... never was. Only a problem posting from a blog client. Ah... I see. I'm just running the tests for a new patch (complete with some sanity checking tests) that should fix it. Sorry for the problems. All being well, it should be checked in (r1041, probably) by the time you read this. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Interface Question
So, I'm just tidying up the publication semantics by adding a published_at field to Content, and adding a Trigger class, which fires off events at specified times in the future (or as soon after the specified time as possible). The workings are slightly ugly at the moment, but the upshot of this is that articles.published is only true for articles which are both marked as published and have a 'published_at' time in the past. Pending articles are have a future published_at attribute, a false 'published' flag and an entry in the triggers table set to fire on the first request after the published_at time. The idea is that notification, remote pings and cache invalidation all get pulled out of Content and into appropriate observers (Notifier, Pinger and the current CacheSweeper spring to mind as decent names), which only fire at the point when an article is *actually* published (using a 'just_published?' flag). Which means we also get to DRY up the various places which trigger notifications/pings (they're currently triggered in Admin::ContentController and various of webservice implementations, and they sometimes trigger at the wrong time). So, with that in mind, I'm canvassing opinions on what people expect from /admin/content... If you post an article and don't mark it as published, but *do* set a 'Publish At' time, do you expect it to get published at the requested time? I'm assuming 'yes' for the time being. NB: For the Can't we just have a stable release? crowd. The stable release is currently blocked on Scott's work on making Typo installation rather more friendly and is independent of the work I'm doing on publishing semantics. The publication semantics work is because, at present, the notification/remote ping system is broken in the face of future publication times -- notifications get sent before the article is visible on the blog, which is flat wrong. It's also to do with code quality; by adding various observers we can get rid of a fair amount of code duplication and 'structural' code[1] 1. Structural code is code which treats an object as a data structure -- never a good sign. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Interface Question
Gary Shewan [EMAIL PROTECTED] writes: I know exactly what you mean about notifications being broken. If Typo runs into a rails error when I'm posting (normally something to do with text filters) then I still get the notification that there is a new post even though the published flag isn't set ... it's like that flag is the very last thing set. So it would be very nice to see notifications working properly. The plan is that notifications only get sent *after* an article has been published and successfully saved to the database. The idea being that it's better to publish successfully and not send the notifications than it is to notify but not to publish. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Added a :default_server_url setting to blog
For those of you living on the edge, after you update to revision 1046, please go to your general settings page and make sure that it makes a good guess at your canonical server url and either accept or correct it and hit save (whether you corrected it or not). This is a new fallback setting for the Blog. I don't believe it affects any production stuff yet, but there are some tests that fail without this setting being available on the blog (the fixture sets something appropriately). However, in the long run, I expect that this setting will get used more often (in fact, I can see it, or something like it, getting promoted to a proper column on the 'blogs' table for use by the dispatcher in a multi blog environment. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Added a :default_server_url setting to blog
Trejkaz [EMAIL PROTECTED] writes: On Thursday 11 May 2006 20:12, Piers Cawley wrote: For those of you living on the edge, after you update to revision 1046, please go to your general settings page and make sure that it makes a good guess at your canonical server url and either accept or correct it and hit save (whether you corrected it or not). This is a new fallback setting for the Blog. I don't believe it affects any production stuff yet, but there are some tests that fail without this setting being available on the blog (the fixture sets something appropriately). However, in the long run, I expect that this setting will get used more often (in fact, I can see it, or something like it, getting promoted to a proper column on the 'blogs' table for use by the dispatcher in a multi blog environment. Out of curiosity, how does this affect those of us who access the same blog through both normal HTTP (for all public stuff) and HTTPS (for all admin pages)? Err... I think in the long run, the setting will end up being 'canonical_server'. Until then, about the only thing you'll need to do is change 'https' in the suggested canonical server url to 'http' -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Comment spam increasing lately
Steve Longdo [EMAIL PROTECTED] writes: Whoever uses spams from the *.50webs.com domain is able to post spam to Typo even with AJAX comments enabled. I have had several hits from it. Seems to target articles older than 40 days from what I have seen so far. Lame yes? I suppose it was inevitable that someone would work out how to get round AJAX only comments. I can't remember the story number on the trac, but it looks like we need to work on tweaking comment publication strategies and get an approval queue working on the admin interface. Also, there's probably a case for making 'nuke comment' throw up a followup form suggesting possible blacklist entries. In the case where none AJAX comments are enabled, there's probably something to be said for harvesting possible blacklist entries from failed comments. Does anyone know if any work's been done on Bayesian comment spam stopping? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] My Personal Medium/Long Term Typo goals
I've just been chatting with sprewell on IRC and it occurred to me that it might be handy to share my current development priorities for typo with the wider list. Immediate goals --- * Finish the work on making article publication use a state object * Possibly look at making the state object be persistent as a memento on the Content object * Knock off a few more low hanging fruit from the outstanding tickets list Medium/Long Term * Think more about the right set of states and transitions for comments and trackbacks (henceforth 'responses'). I'm pretty sure that the state machine for response publication isn't and shouldn't be the same as the machine for article publication. * Experiment with having multiple selectable state machines/publication policies for responses, so one policy might be 'open door' where everything gets published, another might throw all responses into a 'pending approval' queue, another may publishe all ajax comments and throw the rest into the pending approval queue or whatever. * A Bayesian trackback spam stopper * Make page caching work right. Back in 2.6.0 days, page caching was a huge pain in the bum, but by ghod Typo was fast when it was working. As I outlined in an earlier post, I think the Trigger system will allow us to get the benefits of future publication and expiring sidebars alongside the speed boost of page caching, but it's not straightforward. * Document our APIs. I've tended not to do much in the way of documentation because I'm far from sure that the APIs are stable enough for it not to be wasted effort. However, I'm starting to think that the new Sidebar API might stick around for a while and could use some documentation. (But I need to write a non-trivial sidebar to be sure of that I think...) * Give the Theming system a long, hard look. I'm inclined to adopt something like the Scribbish document structure -- having seen the kind of things that can be accomplished with CSS at the CSS Zen Garden[1] I want to make sure that our default markup is as friendly to that sort of modification as possible. Of course, there will always be a space for the kind of advanced themes that need to change the markup, and I want to make life easier for those too. I think there's a case for allowing themes to have parameters akin to sidebar parameters, but that needs some careful interface thought -- it shouldn't be impossible to hang theme parameters off the blog's settings though. * Blog settings need some thought too. If we do go all the way to multiblog capability (still open for debate), then we'll need to pull some settings out of the settings hash and up into the blogs table proper (at the very least we'll need to pull any settings that are used by the router to determine which blog a given url maps to up to the table so they can be accessed with a simple sql query). Also, it seems that the settings hash could benefit from being multilevel (one obvious case for this is in the default settings for various content objects, currently we have 'comment_default_allow_pings', 'article_default_allow_pings', 'article_default_allow_comments' and what have you. Wouldn't it be cool if you could do: Article.with_scope(:create = this_blog.defaults_for[Article]) do ... end Admittedly, it'd be cooler if you didn't have to do that, but could simply let this_blog.articles.build(...) handle it for you, but... baby steps... * Textfilters. I really, really, want to rework text filters so they're not controllers. * Er... * That's probably not all, but it'll do for now. Did I miss anything 1. http://www.csszengarden.com -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] My Personal Medium/Long Term Typo goals
Piers Cawley [EMAIL PROTECTED] writes: I've just been chatting with sprewell on IRC and it occurred to me that it might be handy to share my current development priorities for typo with the wider list. [...] Medium/Long Term [...] * Textfilters. I really, really, want to rework text filters so they're not controllers. * Er... * That's probably not all, but it'll do for now. Did I miss anything Yes, it seems I did: * Admin plugins. Rework the admin interface so it's easy to add a new admin tab as a plugin. That way we can experiment with things like spam handling/blacklisting or whatever in a way that's (hopefully) decoupled from the rest of the administrative interface. It would also be good to be able to add actions to existing tabs in a neat fashion. Things like the podcasting addons have the potential to work rather neatly as a plugin * 'Whole body' plugins. Thinking about the possibility of making the podcasting addons into an admin plugin, it occurs that really it would need to be more than that because there's also user visible feeds to worry about. It seems there's a case for at least working out a standard directory structure and registration system for plugins so that they can integrate themselves with the wider Typo system. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] My Personal Medium/Long Term Typo goals
Gary Shewan [EMAIL PROTECTED] writes: On 13 May 2006, at 12:15, Piers Cawley wrote: * Admin plugins. Rework the admin interface so it's easy to add a new admin tab as a plugin. That way we can experiment with things like spam handling/blacklisting or whatever in a way that's (hopefully) decoupled from the rest of the administrative interface. It would also be good to be able to add actions to existing tabs in a neat fashion. Things like the podcasting addons have the potential to work rather neatly as a plugin * 'Whole body' plugins. Thinking about the possibility of making the podcasting addons into an admin plugin, it occurs that really it would need to be more than that because there's also user visible feeds to worry about. It seems there's a case for at least working out a standard directory structure and registration system for plugins so that they can integrate themselves with the wider Typo system. Now that's an exciting concept ... you read my mind because I'd just asked myself What about a plugin architecture? Heh. I've got the idea in my head now. I dunno when I'll do something about it, but once something is named it's much easier to work on it unconsciously. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Weird issue getting even into the console
Trejkaz [EMAIL PROTECTED] writes: On 13/05/2006, at 22:23 PM, Trejkaz wrote: Any ideas? To answer my own question, it was probably a bug in Active Record, which is fixed now. Now I just wonder why about 90% of my unit tests fail. I haven't modified *that* much from the trunk. :-/ Some pretty big changes in the trunk recently, mostly affecting content and its subclasses. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] My Personal Medium/Long Term Typo goals
Steve Longdo [EMAIL PROTECTED] writes: How will you handle having plugins register routes or are you contemplating making a 'typo plugin' versus the regular 'rails plugin'? Dunno yet. Plugins are definitely in the 'blue sky' phase of planning at the moment. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Comment spam increasing lately
Trejkaz [EMAIL PROTECTED] writes: On Monday 15 May 2006 20:14, Gary Shewan wrote: Trejkaz, have you ever heard the saying It's better to keep quiet and have people suspect you're a fool, than to open your mouth and have it confirmed? It's a brilliant quotation. One of those that really helps in life. Seems like it's proved itself today. Um, guys... Calm down. Please? The saying I tend to think of in these matters is Do not wrestle with pigs, you only get muddy and the pig enjoys it. Plus, after a while, you're both so damned muddy that nobody can tell which one's the pig. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Testing typo...
Matt Rose [EMAIL PROTECTED] writes: So I've been looking into the built in unit tests in typo, and I figured out how to run them. Umm... have you run 'rake migrate'? ISTR that the schema in the trunk doesn't exactly tally with the migrations. Which could explain your failures. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] New Typo Install - install notes, theme viewer and an import question
Gary Shewan [EMAIL PROTECTED] writes: On 22 Jun 2006, at 02:08, John Wang wrote: I just put together a tutorial on installing Typo (2.6.0 with captive Rails) with MySQL, Apache, lighttpd and FastCGI if anyone is interested: I also put together a Typo Theme Viewer app using Scriptaculous' Sortable. Right now it only covers the themes at Typo Garden but others can be added. It's primarily designed to make visual scanning a lot easier. Very nice work John. Crying shame that those themes are broken on trunk as that would be a handy resource. The fellas at Typogarden should have a word with you. They're a good deal less broken than they were though. If memory serves it should just be a matter of tweaking the layout head and possibly the code to render the sidebar (the trunk's way of rendering the sidebar worked in 2.6.0, but the old, explicit way doesn't work any more) -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Memory leak fixed (and speed improved, too)
Scott Laird [EMAIL PROTECTED] writes: I think the Great Typo Memory Leak of 2006 has been fixed: http://scottstuff.net/blog/articles/2006/07/08/ding-dong-the-memory-leak-in-typo-is-dead It was an interaction between the action cache and all of the other filters that we're using--when the action cache's before_filter found a cache hit, it cancels the rest of the filter chain and returns the cached results to the user. Unfortunately, if any of the other filters are saving data in their before_filter and planning on dropping it in their after_filter, then they're going to cause a memory leak, because the after_filter will never be called. Hmm... it's a shame you can't have 'ensure' filters in rails isn't it? The fix is to straighen out the filter order. I moved the cache's filters to the very outside, and that gave us a big speed boost, as well as fixing the memory leak. Longer-term, we need to audit our filters, because they're getting too complex. But for now, I think we're okay. D'oh. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] Identity issues
I got slightly sidetracked on the way to the TRAC, but I've been thinking about identity and blogging. I really, really, really don't want to have to add yet another login/password pair to a commenter's keychain if I can possibly help it. But, it would be cool for people to have some way of identifying themselves in some trusted fashion (so that, for example comments made by signed in users get added straight away, but all other comments get put into a queue pending approval). My thinking on this is that we need to come up with some sort of an identity control API. We define the ways in which Typo interacts with an authentication service, things like: authenticator.session_is_authenticated?(session) authenticator.session_user(session) - returns a user object authenticator.authenticate(controller, session) - May do redirects, hence the controller Then our user object will carry information like: user.memento - Unique string identifying this user (for use in any authorization system) user.email user.display_name user.icon user.url user.authenticated? Possibly more, possibly fewer. Methods like #icon can obviously return an empty string... Once we've worked out the protocols (and tweaked our current identification mechanism to use them) it should be relatively easy to write adaptors for Flickr; Yahoo; Google; OpenID; some kind of dumbass captcha system, if you really insist but don't expect it to get accepted into the trunk; or whatever other authentication services exist or arise. Of course, methods like 'authenticator.session_is_authenticated?' will generally be accessed via helper methods like: session.authenticated? Right, brain dump over, I shall proceed to the Trac directly. Note: Authentication is *not* the same as Authorization. About the only thing I'm sure of regarding authorization is that we shall have something. Note2: This isn't even remotely imminent. I'm just sketching here. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
[typo] More medium/long term Typo goals
that RESTful. Article permalinks are, of course, sacrosanct, but pretty much everything else is fair game. In the long term, I'd like to see the back of admin/* in favour of moving administrative behaviour up into top level controllers and slightly more complicated access control. This is definitely branch territory, if only because the support for the sort of thing I'm thinking of has only recently gone into edge rails. * Migrations. Migrating is hard. It's hard to keep the migration scripts up to date. So, I propose firming up the various message posting protocols we have, documenting them, and then sticking to them both in our controllers and any migrations we use. I envisage using something like the Atom API as our basic posting protocol. * Implement the Atom API. * Use the rails plugins directory. If you write textfilter, or a sidebar, you want some easy way of distributing it. And we want not to have to stick it in the core distribution. It seems that the best way to do this is to enable writing plugins that can be installed in the same way as any other rails plugin. I *think* that this can already be done, but it's completely undocumented. We need to investigate this and, if it will work with the current state of the art, we need to write generate tasks to allow a plugin developer to do: ./script/generate sidebar|textfilter|theme and have a framework dropped in place so she can get on with the hard work of making it do something interesting. * Investigate other blogging engines' plugin architectures. See if we're missing any capabilities and what we'd need to do to import any useful stuff into Typo. Hmm... that'll probably do for now. Did I miss anything? -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] More medium/long term Typo goals
Alastair Rankine [EMAIL PROTECTED] writes: On 01/08/2006, at 7:07 PM, Piers Cawley wrote: * Finish working through the implications of the new state machine based content 'state'. Essentially, 'published?', 'spam?' and a few This looks great, but I would like to see this reflected in the admin interface. Particularly with spam - Wordpress' Akismet plugin does a great job of not only filtering out the spam but holding it in limbo in case of false positives. Typo does this but it's a bit counterintuitive from an administration perspective - they're not marked as presumed spam, merely unpublished. It took me a while to realise that real comments were being published and that spam was being held. Except that's changed with the last checkin. Now the presumed stuff is marked as Spam? and Ham? and the confirmed stuff is marked as Spam and Ham. Also it seems that you (blog admin) need to go and remove unpublished (ie spam) comments periodically. They seem to appear on the articles otherwise. Or am I doing something wrong? They shouldn't be appearing on the articles (assuming they were posted after the spam checking code went in). And one thing I mean to add is an option to say that marking something as definite spam should just report that to Akismet and then delete the feedback. Some other suggestions: * Ability to configure multi-column sidebars Wah! I knew I'd missed something. * A wordpress-like dashboard of recent comments, incoming links, stats (number of articles, comments, etc) Hmm... we're not doing much in the way of intelligent stats gathering yet, so I'm not sure how easy 'incoming links' would be to do, but I like the idea of a dashboard. * Ability to specify a license on a per-page or per-article basis (with a blog-wide default obviously) which would generate the right HTML and RDF for easy inclusion in themes. I'm thinking specifically of making it easy to add a creative commons license to a blog. The problem with per-article licensing is how you sort out the licensing of the front page. Probably doable with a sidebar that works in a similar fashion to the current amazon sidebar (walks the list of contents being rendered on the current page extracting book citations/links and then builds the sidebar). But I'm still not sure how it would *choose* the frontpage license. Ho hum. Worth thinking about though. Here's one I forgot: * Investigate splitting the contents table into 'contents' (for pages and articles) and 'feedback' for comments and incoming trackbacks. The tricky part would be doing the split, and deciding whether it's a requirement to maintain article ids (if you do decide to do that, you enter a twisty little maze of RDBMSes, all different, as you try to make sure that new ids get generated correctly once you've done the conversion) or to break any /articles/read/n type links. I'm beginning to think we need to do this, articles and feedback have a fair amount in common, but the differences are becoming more distinct with each migration. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo's memory footprint
Eric Sendelbach [EMAIL PROTECTED] writes: I am hosting my blog on Textdrive and they have a 48 meg limit on process usage. After that it just gets whacked. On a fresh restart with Typo 4.0.0 its SIZE is 36016K and its RES is 33452K. A couple hits on the main page tack on around 4 more megs and about 90% of the time just editing an article will push it over the top. Pre 4.0.0 I was running on trunk and did not experience this problem. Maybe I was hovering at the limit and didn't realize it. My install of Typo is sitting behind lighttpd/fastcgi. Does anybody on the list know if turning off or abstaining from the use of certain features will help relieve how much memory is consumed? In the spirit of Piers' email to look at more mid/long term goals, I think that memory consumption is definitely something that could be looked at, at least to offer some way of working with a lighter memory footprint. I could be wrong (and I probably am, but we don't have any particualrly great tools for investigating this), but I think Scott's changes to the filter chain and caching have got rid of the big memory leak, but the new, highly inclusive optimized SQL for getting content which tends to pull in the world right at the start (reducing the hits on the database, no bad thing) means that the process gets very big rather quickly, but then doesn't get a great deal bigger after that. I don't think it's going to slim down very much I'm afraid. -- Piers Cawley [EMAIL PROTECTED] http://www.bofh.org.uk/ ___ Typo-list mailing list Typo-list@rubyforge.org http://rubyforge.org/mailman/listinfo/typo-list
Re: [typo] Typo's memory footprint
Steve Longdo [EMAIL PROTECTED] writes:
It is a funtion of the sidebar and textfilter controller where it
dynamically loads all files in the directories into memory:
Dir[#{RAILS_ROOT}/components/plugins/sidebars/[_a-z]*.rb].each do |f|
require_dependency f
end
So it is cool because when new plugins are added they automagically load up,
but unfortunate when, like Sparklines, they have a large overhead
associated.
As for knobs, you could have something that wrote a more specific regular
expression for the load instead of just [_a-z]*.rb...
This is something that could be helped by the mooted move of sidebar
plugins to vendor/plugins. Essentially you'd only need to install
those sidebars you use.
--
Piers Cawley [EMAIL PROTECTED]
http://www.bofh.org.uk/
___
Typo-list mailing list
Typo-list@rubyforge.org
http://rubyforge.org/mailman/listinfo/typo-list
