At the university where I work, there is a LOT of momentum behind
Drupal. A large and active users group, and dozens of departmental
sites running it. I've succeeded in building a few departmental sites
with Django but still feel like it's an uphill battle convincing
managers to agree to go with a relative unknown, both in terms of
language (Python) and platform. Things like the announcement that
whitehouse.gov switched to Drupal just cement the deal in many
managers' minds.

I'd like to put together a summary sheet and blog post summarizing all
the reasons why I feel Django is the better choice for many sites, to
try and help make the "sale" to managers. I have my own set of reasons
but am not going to include them in this message. I'm especially
interested in hearing from people who have done development in both
Django and Drupal (or WordPress or Joomla, or other). Would be
interested in hearing comments on things like:

- Overall development time
- Ease of making changes to templates
- Ease of finding 3rd party functionality (modules vs. reusable apps)
- Server performance
- Ease of building data models that reflect the needs of the
organization
- Ease of finding other developers to take on a project when someone
leaves
- User friendliness (admin and editorial interface)
- Ease of getting the system to do highly custom tasks
- Ease of upgrades
- Security

etc. etc. - anything at all. Please indicate whether it's OK to quote
you (I can paraphrase you if not)

Thanks in advance,
Scot

For me, Drupal is anti-developers. Indeed, it is very hard to balance
a platform to be friendly both to users and to developers, and IMHO,
Drupal is decent but doesn't do great on anything (ease of use, ease
of development, scalability, etc...).

Drupal has many more third-party modules.
But those modules are very opinionated and some are of poor quality,
even when you would expect otherwise (I've had problems configuring
the I18N module, and I couldn't do it to behave reasonably ... making
a Drupal website multi-language is a pain).

Development in Django is a lot easier, because the modules are more
generic and the development process is more predictable because of its
simpler architecture. This is not easy to demonstrate though. The best
thing you could do is to take some time to learn some Drupal
development (there's a book Pro Drupal Development on Amazon) ... and
then do a comparison between the two by implementing a feature,
measuring the lines of code written, going through the problems you
had, etc ...

Another thing you could do is to implement your own CMS in Django that
has most of the features managers are looking for ... most people will
not say no to something that's already implemented. If they still have
troubles deciding, then do a scalability test.

--
Alexandru, Nedelcu
http://alexn.org

On Oct 31, 2009, at 1:20 PM, Alexandru Nedelcu wrote:

That's *exactly* what scares the crap out of managers; custom code vs.  
something "everyone" is using.  You're almost making Drupal's case,  
right there.

S

One key thing to remember is that Django and Drupal (and the other  
things you mentioned) are quite different things. You are comparing  
apples to oranges which makes the sell harder.

Drupal is a CMS and has a different target audience. It has the level  
of complexity that comes from solving the CMS problems.

Drupal like most CMS's will allow you to do things the Drupal way  
quite easily. As soon as you stray from that path, you'll be in trouble.

I recommend understanding your audience and the difference in tools  
and how this affects them.
--
   Andy McKay
   www.clearwind.ca

On 2009-10-31, at 9:44 AM, shacker <shac...@birdhouse.org> wrote:

On Oct 31, 10:42 am, Andy McKay <a...@clearwind.ca> wrote:

To clarify - I'm very aware that one is a framework and the other a
CMS. That part of the question resolves to something like "Is it
easier to use a prefab CMS (Drupal) with all of its opinions and
assumptions you have to wrestle with, or to start from the base level
(Django) and build up to what you need?"

In my experience, the Django admin suffices just fine AS the CMS in
many/most use cases, with a few modifications and the occasional
custom view.

It's been said that Drupal is a CMS with framework-like tendencies
while Django is a framework with CMS-like tendencies. The lines get
fuzzy.

To me, questions like "Is the fact that Drupal is not object oriented
and not MVC/MTV a major or minor annoyance?" (to me it's a major
annoyance).

So I'm aware of the overlaps and differences. I'm really looking for
responses to the questions in my OP.

./s

On Saturday 31 October 2009 10:42:24 Andy McKay wrote:

This is very true, but he can sell it as a cms with one of the many cms for
django[1].  Here he can pick one that matches the known requirements the
managers are looking for, then sell django along with the cms.

After that there are really only three main selling points, customization,
django has plenty of prebuilt apps[2] and the ability to build your own app
with ease. Secondly, speed of development, all php needs is header files to be
a poor mans version of C.  Django has made making web apps almost trivial and
the most time I spend now, is on the ui (both dojo and jquery make this almost
trivial also), rather than the backend.  

Finally, there is the maturity of the language. PHP is still adding in
features other, similar languages already have had. For example namespaces are
just barely a year old in php, initial release in the dev versions, less than
6 months for the actual first appearance in a stable release.

To quote wikipedia[3] on missing features from PHP:

"PHP currently does not have native support for Unicode or multibyte strings;
Unicode support will be included in PHP 6 and will allow strings as well as
class, method and function names to contain non-ASCII characters."

Seriously, in todays global world and well, for the past what 10-15 years,
hasn't this been mandatory?

I do not understand why web developers who use php, still do.  I don't
understand why companies and schools support it.  When there has been other
better languages to use, python, perl, java and haven't changed as much as php
has and still have more, better, what I call mandatory features, plus better
or equal performance. Well I do understand how it happened at first and
recognize it's not going anywhere. I just wish it would go back to the toy
bin/kindergarden for web developers to understand the nature of dynamic web
pages.

See the wikipedia page for related security topics also.

The only strength php has that I believe is a strength and a weakness is it's
drag and drop install.  It's a weakness the same reason php security is, bad
web developer choices, like storing include files and other files with
sensitive information in web accessible directories.  (Who remembers the
inlcude() hack or fread on a remote url?)

This is my main argument; the ability/maturity of the language itself.  

I do think that a lot of people who use php are smart individuals and just
make honest mistakes that led to phps bad repution in security. But, by
default, because of the intelligence of the django devs in getting this part
right, that it is harder for new developers to make similar security mistakes.
Really only in a few places allow you to.

The reason I came to django, because of the language it's based in. Though
many a day I wonder how django would do as a C++ framework. I may find out one
day, but not in the near future.

Mike

[1] http://code.djangoproject.com/wiki/CMSAppsComparison
[2] http://djangozen.com/
[3] http://en.wikipedia.org/wiki/PHP

P.S. quoting me is fine, but I think the wiki page and links will make a
better impression, so I suggest paraphrasing me if you find any of this
useful.

--
Anyone who cannot cope with mathematics is not fully human.  At best he
is a tolerable subhuman who has learned to wear shoes, bathe and not
make messes in the house.
                -- Lazarus Long, "Time Enough for Love"

signature.asc < 1K Download

On Oct 31, 2009, at 11:52 AM, Mike Ramirez wrote:

PHP has a large, and (perhaps more importantly) easy-to-find ecosystem  
surrounding it.  I think that Python's superiority as a language is  
simply not open to debate, but if you are looking for "I need a  
library that does <x>", PHP frequently has acceptable solutions closer  
to hand.

And, as with PostgreSQL vs MySQL, shared web hosting is very strongly  
oriented around PHP, and that (until the relatively recent rise of  
VPS) was the primary entry point for a lot of web developers.

--
-- Christophe Pettus
    x...@thebuild.com

On Saturday 31 October 2009 12:00:13 Christophe Pettus wrote:

It was a rhetorical question.  Tho the same goes for MySQL.  Why?
I do understand, I was there too watching and developing back in the early
2k's with php4 and first few versions of 5 helping clients cause I ran one of
those hosts. Sorry for not being specific about that.  Truth is that we used
MySQL and PHP mainly because CPanel (and other virtual host control panels)
had the support built-in and made it easy for the users and less headaches on
us.

Mike

--
Squirming:
        Discomfort inflicted on young people by old people who see no
irony in their gestures.  "Karen died a thousand deaths as her father
made a big show of tasting a recently manufactured bottle of wine
before allowing it to be poured as the family sat in Steak Hut.
                -- Douglas Coupland, "Generation X: Tales for an Accelerated
                   Culture"

signature.asc < 1K Download

On Oct 31, 8:44 am, shacker <shac...@birdhouse.org> wrote:

I helped produce a med-large site in drupal for a local non-profit.
This was at the tail of Drupal 5, and haven't used it a ton since, but
had set up several smaller drupal sites before then.

There are going to be lots of "it depends"

For a basic CMS site - Drupal will be faster and more full featured
out of the box.

Page design time is going to be about the same either way

Implementing templates for Django is easier as they are just simple
files and the inheritance system is simple - there are books about
doing templates in Drupal

Both have the problem of often complex dependencies.  The biggest
problem with Drupal is its relatively fast moving core - so that
modules for the "current version" are hard to find, or often
abandoned.  Also Drupal modules almost always seem to do 80% of what
you need.

Depends on the complexity - for relatively "flat" data, Drupal's CCK
is usable by non devs to create custom content types, and the Views
module allow for simple generic_view style pages.  When it comes to
more complex objects, Django's ORM is far superior.

In my experience it was hard to find any Drupal devs who wanted to do
small fixes, or maintenance.  Everyone was looking for the big fish of
bigger full site design with more $$$ involved.

While both can have a decent staff-admin UI, Django's user-admin UI
can be made much more clear and focused.  Where Drupal has its single
biggest advantage, is that a technical user, a sys-admin etc, can get
Drupal up and running.  Someone doesn't have to know PHP AT ALL to get
drupal going.  This is because Drupal has a decent admin-UI - where
modules are pretty much drop in, activate and configure.

Setting up even a basic Django site REQUIRES someone who has some
programming skills, even if thats just a matter of setting up the
settings.py file.

What happens is that non-developer/technical decision makers will
evaluate Drupal and think that all their needs will be met out of the
box.  When they find out they aren't, they need to hire developers,
and then those developers have to massage existing modules to
customize and tweak.  Then at some point they have this monster of
hodgepodge code.  But its that entry point that is the key to Drupal's
popularity.

What Django needs IMHO is an admin UI for Pinax. Pinax project plans
to do this "someday".  When Pinax can have a web-based install, with
an admin UI to enable/disable pluggable apps - Django will experience
huge win.  Because the same thing will happen as does for Drupal,
there will be technical users who evaluate pinax and think it can do
everything for them.  At some point they will need a custom app - they
HIRE a django dev.  That Django dev writes a well done reusable app -
and often with the blessing of the hiring company, releases that into
the world.  Let this process continue and you can see that eventually
the Django app universe will grow.

I don't think people appreciate how much Drupal development is spawned
by this existence of a usable entry point for Drupal by non-
developers. (and that it has 1-click installs on hosts, and in general
uses the far more common infrastructure of PHP-MySQL)

Django just wins this so hands down.  Here is part of the reason why.
Drupals assumptions translate into your code having to jump through a
lot of hoops - where as in Django, you make the assumptions and you
make the hoops.

2009/10/31 shacker <shac...@birdhouse.org>

I can't find the source for this (the original tweeter has protected tweets)
but if true its an interesting stat.

http://twitter.com/pydanny/status/5263754707

Plone not Django, but its closer than Drupal.

Cheers,
Dougal

I just wanted to thank everyone for their excellent contributions to
this thread. Sorry I got side-tracked for a while. I've just put up a
pretty complete draft of a post on this topic, written with decision
makers (managers, supervisors) in mind. It's still probably somewhat
technical for that group, but that's the nature of the topic.

http://birdhouse.org/blog/2009/11/11/drupal-or-django/

Before I send it out to some people I need to see it, wanted to bounce
it off you guys - make sure I didn't screw anything up, get anything
wrong, mis-attribute anything, etc.

Feedback and further contributions welcome.

Thanks all,
Scot

On 12 nov, 01:16, shacker <shac...@birdhouse.org> wrote:

A couple things that came to mind while reading your draft:

1/ wrt/ performances AND rapid development : I recently had to work on
a not-so-complex (functionaly-wise) Durpal project, and the response
times on my local station - all caches disabled of course - turned the
development process into a sluggish nightmare. Never had this kind of
problems with Django, even for far more complex apps.

2/ wrt/ rapid development again: I started yesterday afternoon (on my
spare time) a simple virtual gallery application for a painter friend
of mine. I had more than half of the application (including templates
etc) working in a couple hours, and most of the still missing features
will be provided by existing pluggable djang apps. It shouldn't take
more than a couple more hours to have the whole thing up and running.
And when I say "a couple hours", I really mean it, litteraly !-)

Else, I just can second most of the developper's comments : from my
experience, it can take more time doing "simple customisations" on
Drupal than you'd need to implement the same features from scratch in
Python.

My 2 cents.

Hi Scot

Having held your post in my browser for most of a busy day I finally read it but wondered throughout who it was targeted at. Now I come back to this thread I still wonder. When you say "managers" and "supervisors" you don't indicate their level of technical knowledge or involvement. Your post suggests they ARE technically minded and involved and sells your argument from that perspective. If however they aren't then I think there is one angle it seems to ignore: If we picture that one focus in any managers agenda is "are the things that need to get done getting done so I can answer to my higher uppers/clients/customers/etc?"

I can of course only speculate here, but I imagine that the appeal of Drupal you are trying to compete against is that, from their perspective, in going from 0-60, Drupal appears to already be at 50. It really doesn't matter to them that it could have taken 4 times as long to get from 0-50 as it would have taken if Django was used. To them the tangible is where Drupal is now.

It's also a jump to be able to realise that the 50-60 bit takes even longer and may actually never quite get there with a pre-existing solution. Your post almost deepens the sense that yeah, Django may be great but it's at 0 and as a manager I have to put ALL my trust in you that you're right. Partly because all those things Drupal already has I don't have either the time or knowledge, or both, to manage the development of anyway.

With that in mind I think you need to start at a more comparable point to Drupal. It has loads of solutions already built that actually DO work together which you don't mention. Drupal is a CMS so why not refer to existing CMS apps or better, let NASA do it for you:

http://pydanny.blogspot.com/2009/11/picking-django-powered-cms.html

There is one point that you made that you should push a lot more, albeit a little differently: "In Django, all development starts by defining the data models that describe the organization, publication, or site.". That single point is huge for an organization; Compared to a pre-existing solution Django is used to build something that fits the organization not the other way round.

Where I think you need to reword is that you say "starts by". Does the manager really know where the start is? Do they picture a blank page with a blinking cursor? Of course they'd be nervous if that is what they see. You and the rest of us on this list know of course that Django is itself already very well equipped and what it doesn't contain it has an ever increasing list of 3rd party solutions that can be used even if temporarily.

I could probably go on but I think I need to let sleep have it's way for a change!

Cheers,

Nick

On Nov 12, 11:16 am, shacker <shac...@birdhouse.org> wrote:

Hi Scot,

You should probably send a link over to the Drupal forum as well to
get some feedback from the other side of the fence.

To sum it up, anyone who is good developer and experienced in either
platform will probably produce very similar results in a similar
timeframe.

It really comes down to:

"do you (or your department) want to write code in PHP or Python"

because unless you have hugely complex or popular sites, either would
work quite comfortably.

Regards,

Ray Smith

Thanks everyone for the additional comments. Draft #2 is up now, with
substantial changes and additions based on your feedback.

Yes, I'd like to get feedback from some  Drupal people, but again want
to focus on devs who have worked in *both* systems. If you know of
anyone who has, feel free to point them to the document.

http://birdhouse.org/blog/2009/11/11/drupal-or-django/

./s

On Friday 13 Nov 2009 4:26:44 am scot.hac...@gmail.com wrote:

looks like you have missed out on security - count the number of critical
holes in drupal over the past year with the one hole in django in the past 4
years. btw, I tried to comment on your blog, but was rejected saying I was
behind a proxy. Given that practically any one on a LAN is behind a proxy,
this in practice prevents comments.
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
http://nrcfosshelpline.in/web/

On Nov 12, 4:56 pm, Kenneth Gonsalves <law...@au-kbc.org> wrote:

That's a tricky area - we have to be very careful about saying that
anything is "more secure" than anything else. We don't want to give
false hopes/impressions to managers, and we have to remember that part
of the reason for  Django's security track record is because it's
"below the radar" of attackers. That could change at any time. Still,
security is an important consideration and I've included a bit on it
in the "final" version, which is up now.

Thanks all for your contributions.

Scot

On Monday 16 Nov 2009 6:13:43 am shacker wrote:

is this really so? I do not know too much about security, but whenever this
debate comes up, most people take the view that if django was more widely
used, it would show up with more security holes. And I find it impossible to
counter this. I do also point out to plone vs drupal, but there again the
argument is the drupal is more widely used and hence has more observable
vulnerabilities. It does not sound logical.
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
http://nrcfosshelpline.in/web/

On Nov 15, 2009, at 5:10 PM, Kenneth Gonsalves wrote:

I don't think that anyone is seriously arguing that a piece of  
software being widely adopted somehow creates new security  
vulnerabilities in it.  I believe the assumption is that all software  
of a given level of complexity has roughly the same number of  
vulnerabilities, either exposed or hidden.  Thus, the more used a  
piece of software, the more attention the bad guys give it, and thus  
the more of those hidden security problems become exposed.
--
-- Christophe Pettus
    x...@thebuild.com

Hi, new to the list here, but I've been doing Django dev for a while
now and Drupal as well. In fact, at my workplace (60-person web design/
development shop) I'm leading a similar charge to move us away from
Drupal development towards Django.

I took a look at your post and thought I'd add a few things:

1. It's not exactly correct to say Drupal isn't Object Oriented. Like
Django, some of Drupal is written in a typical procedural style, some
OOP.  It's more accurate to say Drupal is less Object Oriented. More
here: http://drupal.org/node/547518  In any case I'm not sure it's a
huge selling point.

2. Same for MVC: Drupal does it...kinda. More here:
http://archivemati.ca/2006/01/21/drupal-as-a-mvc-framework/   I'd say
Django maintains a separation of concerns much better, though, and I'd
say this is a big selling point, unlike OOP

3. +10 on templates: Drupal templates are very frustrating. A single
page is usually generated by an elaborate nesting of templates. Let's
say you have a page that lists a bunch of nodes. You have a template
for the page, for the list, for node itself and maybe (with CCK)
individual node fields. This is a lot to keep track of and why there
are whole books written about Drupal templating. What's more, you
don't have enough control over markup. A lot of devs where I work feel
very frustrated when the lean, clean, semantic html mockups they
produce get completely torn up by the way Drupal works. Django almost
never forces any markup constraints on you. This allows front end dev
to proceed more or less parallel with back-end dev in Django, which
buys you a lot of time if you have teams that work that way. In
Drupal, the templating phase is intimately tied into the back end
development phase, partly because of the less-than-stellar separation
of concerns mentioned in #2 above. That's a slower way to work.

4. Drupal doesn't have an ORM, really. With  you can get a mapping of
DB fields to a php object, so that  say, the "title" DB column maps to
an object : $node->title, but that's not really an ORM in any sense
that I think of it.

5. Security. Django makes a lot of design decisions that make it hard
to write insecure code. Not impossible, but hard. Some attack vectors,
like SQL injection (and other input sanitization exploits) are pretty
much eliminated by Python's DB API and Django's ORM and Form
validation tools. This is not to say you couldn't create an exploit in
a Django app,  but that you'd have to be trying to on purpose. They
also give you tools to prevent CSRF which were optional, but in newer
releases are being promoted to "required" in contrib.admin at least
(http://docs.djangoproject.com/en/dev/ref/contrib/csrf/ )
 One of PHPs biggest failings re: security , IMHO, is they made it too
easy to do the wrong thing for far too long. This is improving, but I
think you still see this lax approach reflected in the large number of
Drupal exploits that have appeared and in the way many people don't
seem to take security as seriously in the PHP universe.

6. Deployment. I tend to think of Deployment as more than just
installing an app and for that reason, I think Drupal's deployment is
far inferior to Django's. It's relatively easy to set up a Lamp stack
and install Drupal on it. Django requires you to install Python,
Apache, your RDBMs, python drivers to connect to it, PIL (probably)
and mod_wsgi (Hopefully that's what you're using). These things
represent the baseline for installing an app, IMHO, and for people
without a *nix background, setting them up is harder than in Drupal
(although with debian and dpgk, it's not that bad). But to me,
deployment means more than installing a LAMP stack. Deployment means
packaging. PHP doesn't really have good package management tools.
Python does. Deployment means being able to run a test suite on your
install and know immediately if anything has broken: Django let's you
write tests for your app, Drupal does not.  Deployment means being
able to maintain dev, staging and production environments in sync. In
Drupal this is very hard: one of my biggest complaints is that Drupal
is that it mixes application configuration and data in the DB so that
they are completely inextricable. This is a huge problem if, for
example, you want to migrate some new views from your staging
environment to your production environment. Deployment also means
upgrading: In Drupal you've got the upgrade treadmill and it sucks.
The more modules you have the more it sucks. Upgrades not infrequently
break things, and since you have no unit tests or functional tests,
there's no way to know if something broke without clicking around and
hoping you catch the problem. Django + Python give you:

+ package management (distutils, virtual_env, zc.buildout)
+ unit and functional tests
+ fabric to help deploy in multiple environments across the cluster
+ south to help you migrate schemas
+ a complete separation of data from everything else

My argument against Drupal boils down to 2 things: 1. It's doesn't
know if it want to be a CMS or a framework, and the confusion shows.
It's an OK CMS if your problem set matches it's capabilities. It's not
a good framework for the reasons mentioned above and more which many
commenters here have caught. 2. Drupal makes deployment of a real,
professional site (where less than 99.99% uptime is not an option)
very difficult and there doesn't seem to be anyone doing much about
it. This is a start http://groups.drupal.org/aegir-hosting-system
...but it's not enough.

Anyway, from someone who has been there, I feel your pain. We've done
a few parallel development projects @ my workplace to show Drupal vs.
Django and the results have been encouraging. For the kind of site we
often do, an average Drupal build means moderate to heavy template
customization,  CCK and custom content types, 20 or so 3rd party
modules modules and 1 or 2 custom modules we write. If this is the
kind of site you're doing, Django is very likely a better fit.

On Nov 15, 7:43 pm, shacker <shac...@birdhouse.org> wrote:

On Monday 16 Nov 2009 6:50:10 am Christophe Pettus wrote:

it is precisely this assumption that does not seem logical to me. But frankly
I do not know how to counter it ;-)
--
regards
Kenneth Gonsalves
Senior Project Officer
NRC-FOSS
http://nrcfosshelpline.in/web/

On Mon, 16 Nov 2009 08:53:26 +0530, Kenneth Gonsalves <law...@au-kbc.org>
wrote:

It is quite simple. Say you write a letter. You proofread the result.
You give it to someone else to proofread and it's likely he/she finds
a few more typos. The longer the letter, the more mistakes you'll
make (absolute), while the percentage might stay the same.
The more eyes look at it, the better your chances are that you will
send a flawless letter.
Now, the question arises whether a program is more secure if it has
more exposure (proofreaders) or less and a bit of both is true.
The more proofreaders the less chance a bug remains, yet since
exploiting the bug requires knowledge to be shared and/or
incorporated into attack software, the chance that *you* as a user
gets exploited through one of these bugs lessens.
Think of this as the difference between a cabin in the mountains,
no locks on the door and a 5 mile steep hike to get there, versus
a bank downtown. Obviously, the bank is more secure, yet it's
much less likely that someone will try and rob the cabin.
--
Melvyn Sopacua

On Mon, Nov 16, 2009 at 5:25 AM, Melvyn Sopacua <

Metaphors are messy and tend to break down. There may be more spelling
mistakes in the Drupal letter, but that is because it is a letter and django
is an alphabet...

On Sunday 15 November 2009 19:23:26 Kenneth Gonsalves wrote:

How is it not logical?  Product A is widely used, Product B is used less. Bad
Guy A. is smart enough to realize that product A if broken can be used to gain
him more presents because more users have it. This is because of the human
condition of laziness and the majority are not really paying attention to what
they are doing. This is a fact. If you're one that thinks about everything
they are doing, i.e. every litteral step yout take down the hall is carefully
planned.  Then you are most likely going to avoid Bad Guy A, and be a
minority.  I hardly meet people who do this, they just act without thinking.

Its illogical to think that everyone or the majority will not succumb to
laziness because this is our ideal goal as a society.  Everything we build do
is to make our lives easier so we can be lazy without worry.

Mike

--
The chat program is in public domain.  This is not the GNU public license.
If it breaks then you get to keep both pieces.
        -- Copyright notice for the chat program

signature.asc < 1K Download

A long and complex report written by someone who has good communications
skills and who knows English fluently is likely to have fewer spelling
mistakes and grammatical errors than someone who uses Google Translate
to translate even a short and simple report to English from some other
language.
--
Regards,

Clifford Ilkay
Dinamis
1419-3266 Yonge St.
Toronto, ON
Canada  M4N 3P6

<http://dinamis.com>
+1 416-410-3326