Towards 4.0.0


#1

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.


#2

On Thu, Mar 30, 2006 at 09:29:48AM +0100, Piers C. 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.

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.


Rodger D. removed_email_address@domain.invalid
“Forgive us if we bite your head off; we were led to assume you weren’t
using it in the first place”
–Jim Allenspach, in comp.lang.perl.misc


#3

Rodger D. removed_email_address@domain.invalid writes:

On Thu, Mar 30, 2006 at 09:29:48AM +0100, Piers C. 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).


#4

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.

Thanks for any pointers. If you are interested I’ve posted a
description of my actual problem below.

ps. I’m learning a great deal studying and playing with the Typo code.
Thanks!


I have a builder template that renders a Java webstart jnlp file.
Right now I am creating the the jnlp file links like this:

link_to ‘Run’, :action => ‘jnlp’, :id => activity

Which creates links like this:

http://host.com/controller/jnlp/1

The action looks like this:

def jnlp
@headers[“Content-Type”] = “application/x-java-jnlp-file”
@headers[“Cache-Control”] = “public”
@activity = Activity.find(params[:id])
render :layout => false
end

Which then calls the Builder view: jnlp.rxml

By setting the Content-Type in the http headers most browsers
correctly interpret the file “1” as a jnlp file and if Java is
installed start the webstart application. However FireFox (and
Mozilla) on MacOS seems to require that the file actually be served
with the “.jnlp” filename suffix.

So I’d like to instead create links like this:

http://host.com/controller/jnlp/1.jnlp

The general question is: how can I concatenate a static filename
suffix to a link?

Thanks!

– Stephen B., stephen at deanbrook dot org


#5

Quick tip - make sure you remove most of the stuff from and
use <%= page_header %> (that’s off the top of my head, function name
might be slightly off). Look at Azure as an example. The theme will
work without that, but lightbox won’t, nor will any other lightbox-
esque additions in the future.


#6

Stephen B. removed_email_address@domain.invalid writes:

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.


#7

I think it could be a good thing to put on the wiki in a “Tips’ page”


#8

Stephen B. removed_email_address@domain.invalid writes:

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.


#9

Stephen B. removed_email_address@domain.invalid 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?

the following form:

http://localhost:3000/xml/rss20/feed.xml

Thanks for your help.

– Stephen B., stephen at deanbrook dot org


#10

“cedric” removed_email_address@domain.invalid writes:

Kevin B. wrote:

Quick tip - make sure you remove most of the stuff from and
use <%= page_header %> (that’s off the top of my head, function name
might be slightly off). Look at Azure as an example. The theme will
work without that, but lightbox won’t, nor will any other lightbox-
esque additions in the future.

I think it could be a good thing to put on the wiki in a “Tips’
page”

I really hate top quoting… but maybe that just means I’m old
school[1] or something. But yes, it’s probably as well to open a
ThemePorting page. However, I keep looking at the most fundamental
change that has to be made – replace article.body_html with
article_html(article, :body) – and loathing the new style with such
intensity that I just want to make the old way work.

  1. Says the man with the 10 year old email address

#11

On Fri, 31 Mar 2006 04:51:17 +0100, Piers C. removed_email_address@domain.invalid
wrote:

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).

I’ve had a heck of a time staying with a theme, as when I update to
trunk oftentimes my site will work, but only display the titles, no
content for my articles. Othertimes things look good until you click on
a link, and then that page bombs with the ‘permalink’ error.

Regardless of how much I love the Lucid theme, having to kill the
public/ directory and clearing the cache to get (parts of it) to work
right after an update is too much. I’m now using the excellent
‘Scribage’, but I haven’t modified it at all. I think having 4-5 nice
contest themes packaged into 4.0 would be nice, that way we’d have some
‘just work’ themes for that, and then hopefully Typogarden can start
tagging themes with which ver they’re known to work on.

P

http://fak3r.com - you dont have to kick it


#12

Piers wrote:

Routes are a two way thing.

Aha!

I hadn’t realized that the routes worked both ways (mapping incoming url
requests AND as the template used to generate urls by the app). Thank
you for pointing out the concept! Of course now looking back it is
obvious that it has to work that way.

I find it interesting reflecting on my process trying to figure this
out. I tried to follow the url_for code in the rails source but I knew I
was missing something. One part was getting my head around all the
meta-programming used in Ruby and Rails and the other was the fact that
as implemented in Rails routes affect both halves of the url process.

– Stephen B., stephen at deanbrook dot org


#13

On Fri, Mar 31, 2006 at 04:51:17AM +0100, Piers C. wrote:

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.

[rodgerd@sacco typo]$ svn update

[…]

Updated external to revision 4210.

Updated to revision 1021.

[rodgerd@sacco typo]$ rake migrate
(in /home/rodgerd/typo)
rake aborted!
undefined method `namespace’ for main:Object
./Rakefile:10

Hmm. Not so good.

[rodgerd@sacco typo]$ gem list --local

*** LOCAL GEMS ***

[…]

rails (1.0.0)
Web-application framework with template engine, control-flow layer,
and ORM.

rake (0.6.2)
Ruby based make-like utility.

[…]

Hmm. Is this a problem with sitting on rails-1.0 as opposed to
rails-1.1, the wrong version of rake, or something really dumb on my
part?

[rodgerd@sacco typo]$ sudo gem install rails
Attempting local installation of ‘rails’
Local gem file not found: rails*.gem
Attempting remote installation of ‘rails’
Updating Gem source index for: http://gems.rubyforge.org
Install required dependency rake? [Yn]
Install required dependency activesupport? [Yn]
Install required dependency activerecord? [Yn]
Install required dependency actionpack? [Yn]
Install required dependency actionmailer? [Yn]
Install required dependency actionwebservice? [Yn]
Successfully installed rails-1.1.2
Successfully installed rake-0.7.1
Successfully installed activesupport-1.3.1
Successfully installed activerecord-1.14.2
Successfully installed actionpack-1.12.1
Successfully installed actionmailer-1.2.1
Successfully installed actionwebservice-1.1.2

[rodgerd@sacco typo]$ gem list

*** LOCAL GEMS ***

rails (1.1.2)
Web-application framework with template engine, control-flow layer,
and ORM.

rake (0.7.1)
Ruby based make-like utility.

[rodgerd@sacco typo]$ rake migrate
(in /home/rodgerd/typo)

Rails does not work with Ruby version 1.8.3.
Please upgrade to version 1.8.4 or downgrade to 1.8.2.

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).


Rodger D. removed_email_address@domain.invalid
“Not only does the English Language borrow words from other languages,
it
sometimes chases them down dark alleys, hits them over the head, and
goes
through their pockets.” – Eddy Peters


#14

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.
Is there a way to make it not grab Rails 1.1 if I already have it
installed?

  • Jared

#15

Jared Luxenberg wrote:

Is there a way to make it not grab Rails 1.1 if I already have it installed?

~$ svn [update|checkout|export|…] --ignore-externals

~$ svn help update
[…]
–ignore-externals : ignore externals definitions

Is that what you needed?

Eric D.


#16

Rodger D. removed_email_address@domain.invalid writes:

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.