On Tue, Feb 1, 2011 at 6:43 AM, William Ross <[email protected]> wrote:
I don't use the archive extension but my feeling here is that the logic in
> the model is right and your url scheme is twisting things a bit out of
> shape. Any reason not to use /events/city/YYYY/MM/DD? Then the slug
> constraint would be helping you as it's meant to. It may just be a case of
> creating a page for each city.
>
If I use the scheme you're suggesting (and I have thought of it), it would
lead to longer urls and it still wouldn't solve the problem. The scheme we
use is more like:
/apac/seminars/2011/02/01/beijing
/apac/workshops/2011/03/02/beijing
Turning this upside-down would require adding another directory (e.g.
events) to maintain a sane IA, and would make the urls look like:
/apac/events/beijing/2011/02/01/seminar
/apac/events/beijing/2011/03/02/workshop
But this still doesn't solve the problem because as soon as we want to host
another seminar or workshop in Beijing, we're right back to square
one--Radiant is going to whine about duplicated slugs. I really don't want
to have to put an obnoxiously-long-and-redundant-disambiguation-string on
the end of the url (as it would be if I let Radiant auto-generate the slug
from the title).
I totally understand the porting and backwards compatibility issues of which
you speak. It just seems that the current restriction is somewhat draconian
and counterproductive for archive pages.
Unfortunately, I'm still about a month out or so before I can get Radiant
upgraded, but by that time, we'll already have a dozen or so of these pages
in place, so that's not really going to help me for the pages we're posting
now.
-dan
>
> And you're right that validations are very difficult to monkeypatch but I'm
> not very keen on putting a special case in the Page model, nor on
> backporting it. If you're prepared to upgrade then life will get a lot
> easier: most obviously because you can use r:aggregate tags to combine the
> children of several pages, eg by publishing an events archive for each city
> and combining them on a main calendar page.
>
> With an up to date installation you could also consider using the
> event_calendar extension to provide proper calendar functionality. You can
> add (my) event_map for googlemapping and taggable_events if you want to tag
> your events by city (or any other scheme). See for example:
>
> http://350.royalsociety.org/calendar/2010/june
> http://350.royalsociety.org/map?month=7&year=2010
>
> we built that last year (which is why the various extensions listed above
> all exist) and you may well find it does what you need.
>
> best,
>
> will
>
>
>
>
>
> >
> > Where YYYY/MM/DD is the date that the event will be held.
> >
> > The problem with this, however, is that my customer is going to be
> hosting multiple events in the same city on different dates, e.g.:
> >
> > http://ourhost.ourdomain.com/events/2011/02/01/chicago
> > http://ourhost.ourdomain.com/events/2011/03/15/chicago
> >
> > However, the uniqueness constraint in page.rb[2] makes this impossible,
> since it enforces a unique slug under the parent. This seems excessively and
> unnecessarily restrictive for an ArchivePage--the uniqueness constraint
> really should be on the URL, not the slug.
> >
> > I'm able to get around this problem by hacking page.rb to include the
> following:
> >
> > validates_uniqueness_of :slug, :scope => :parent_id, :message => 'slug
> already in use for child of parent', :if => Proc.new { |page|
> page.parent.class_name != 'ArchivePage' }
> >
> > validate :unique_slug_unless_parent_is_archive
> >
> > private:
> >
> > def unique_slug_unless_parent_is_archive
> > return unless parent.class_name == 'ArchivePage'
> >
> > my_url = self.url
> >
> > match = Page.find_by_url(my_url)
> >
> > if match and match != self
> > errors.add :class_name, "URL #{my_url} is not unique. Choose
> another slug."
> > end
> > end
> >
> > However, for hopefully obvious reasons, I don't want to hack the source
> directly--I'd rather monkey patch, but it doesn't look as if the change I
> made to the "validates_uniqueness_of" line above (in bold) is possible with
> a monkey patch.
> >
> > Is there any chance of making this an official change in Radiant? Are
> there any other solutions or problems with my hack that I'm overlooking?
> >
> > Thanks,
> >
> > -dan
> >
> > -- Footnotes
> >
> > [1] An upgrade is in the works, but I keep getting preempted by "more
> important stuff." :-\
> > [2] https://github.com/radiant/radiant/blob/master/app/models/page.rb
> >
>
>
