On 1 Feb 2011, at 14:13, D.Kreft wrote:
> I'm using an old version of Radiant (0.6.7) [1] but I think this behavior
> still exists in tip as well based upon what I see in github [2].
>
> My customer has a bunch of events in various cities across the world this
> year that they want to publish via our CMS. So the natural and most
> convenient thing to do is to put them under an ArchivePage so the URLs look
> like this:
>
> http://ourhost.ourdomain.com/events/YYYY/MM/DD/city
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.
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
>
