Cleanups for 4.1

I’ve been working on some cleanups for 4.1 in a branch, and I wanted
to give a heads-up here, so people can scream in terror before I
commit it :-).

The first change is that blog.url_for now uses
blog.canonical_server_url. This means that we don’t need a controller
to generate URLs any more. Which leads to…

  • a complete removal of the wacky before/after filter that saves the
    current controller.
  • a complete removal of the controller parameter for all of the text
    filter code
  • a complete removal of the controller parameter for notifications.
  • text filters stop being controllers.

So, a lot of ugly code goes away.

Next, I cleaned up a bunch of helper code. We had at least 8 copies
of the article permalink generation code, and a pile of redundant ways
to do almost everything. So I cleaned up all of it, but this will
break out-of-tree themes, filters, and sidebars.

First, I added a ‘permalink_url’ method of all of the model classes
that have permalinks. Since it uses blog.url_for, it’s static and
doesn’t depend on any controller code. I then removed all of the
other permalink generation code–article.location, article_url,
blog.url_for(article), and a handful of other localized helpers are
all gone. The entire codebase uses article.permalink_url now. I’m
working on adding edit_url, delete_url, and feed_url; once those are
done about 90% of the url_fors in the main body of Typo will
disappear. Since the new URL code is a lot faster then the old code
(caching, mostly), this should help performance a bit. And more
importantly, it’s a lot cleaner.

I’ve also removed a bunch of other helpers–I’ll post a list later,
but I’m trying to get rid of redundant and outdated helpers. In
general, I’m planning on keeping the most direct mechanism and getting
rid of the rest. For instance, it’s now safe to get rid of
article_html/coment_html/page_html and simply use article.html and
friends directly.

I’m not done yet, but the code is looking much cleaner and more
direct. I’m removing more code then I’m adding, which is almost
always a good thing.

The downside of this is that I’ve probably broken most themes. The
changes needed will be pretty trivial, but changes will be needed.
This is for 4.1, not 4.0–it won’t be released for months, so we’ll
have time to clean up themes. This probably won’t be the last
incompatible theme/sidebar/text filter change for 4.1, but we’ll have
some good things that will make up for it soon–trust us :-).

Scott

On Aug 14, 2006, at 10:21 AM, Scott L. wrote:

I’ve been working on some cleanups for 4.1 in a branch, and I wanted
to give a heads-up here, so people can scream in terror before I
commit it :-).

This is pretty spiffy.

The downside of this is that I’ve probably broken most themes. The
changes needed will be pretty trivial, but changes will be needed.
This is for 4.1, not 4.0–it won’t be released for months, so we’ll
have time to clean up themes. This probably won’t be the last
incompatible theme/sidebar/text filter change for 4.1, but we’ll have
some good things that will make up for it soon–trust us :-).

Since you’re targeting a release a few months out, are you going to
shoot for Rails 1.2? In other words, are you going to develop it on
edge or on 1.1.x/stable? If you’re going the 1.2/edge way, you could
probably use the RESTful routes to clean things up even more. Also,
you can use _path instead of _url, which is like
url_for with :path_only => true (i.e. no “http://domain.com” in the
html).

Rock on!


Josh S.
http://blog.hasmanythrough.com

On 15/08/2006, at 3:21 AM, Scott L. wrote:

I’ve been working on some cleanups for 4.1 in a branch, and I wanted
to give a heads-up here, so people can scream in terror before I
commit it :-).

The first change is that blog.url_for now uses
blog.canonical_server_url. This means that we don’t need a controller
to generate URLs any more. Which leads to…

Not exactly a scream in terror, but…

Does this mean that I won’t be able to take my production database
and run it on a development server (on a different virtual host)
without modifying the canonical_server_url?

To put it another way, does this work require knowing the server
(virtual) hostname or can you do what you have to do using just
absolute paths?

On 8/15/06, Piers C. [email protected] wrote:

yet, we do have to warn as early and widely as possible if we’re
going to go changing public interfaces.

(Not something we’ve been desperately good at I admit)

Yeah. My goal is to get 4.0.3 out tomorrow or Thursday, and then
branch 4.0.x. I’ll merge my code as soon as possible after that.

Scott

“Scott L.” [email protected] writes:

warnings into the logs the better. We don’t have to make the changes
yet, we do have to warn as early and widely as possible if we’re
going to go changing public interfaces.

(Not something we’ve been desperately good at I admit)

Yeah. My goal is to get 4.0.3 out tomorrow or Thursday, and then
branch 4.0.x. I’ll merge my code as soon as possible after that.

Yay!

“Scott L.” [email protected] writes:

Next, I cleaned up a bunch of helper code. We had at least 8 copies
of the article permalink generation code, and a pile of redundant ways
to do almost everything. So I cleaned up all of it, but this will
break out-of-tree themes, filters, and sidebars.

Okay, the sooner we get this into trunk (and a 4.0.x release for that
matter) with the ‘removed in 4.1’ helpers dropping deprecation
warnings into the logs the better. We don’t have to make the changes
yet, we do have to warn as early and widely as possible if we’re
going to go changing public interfaces.

(Not something we’ve been desperately good at I admit)

On 8/15/06, Piers C. [email protected] wrote:

Okay, the sooner we get this into trunk (and a 4.0.x release for that
Yay!
I know that Rails 1.2 will come with a deprecation system, but I don’t
want to wait, and I had a couple special things that I wanted to do,
anyway, so I whipped one up just now. You flag deprecation like this:

def foo_helper(arg)
typo_deprecated(“Replaced with Article#foo”)

end

Under normal circumstances, it logs deprecation warnings to the log.
The warnings look like this:

Deprecation warning: foo_helper called from
app/models/content.rb:31:in `initialize’ Replaced with Article#foo

Each deprecation line is only logged once; after that they’re silently
ignored, EXCEPT in test mode–when RAILS_ENV==test, deprecations
throw exceptions every time. This should make them harder to ignore
:-).

Scott

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs