Django vs. Liferay
Nic Jordan
I'm currently involved in a project for building en entirely new site.
The choice of our informatics-advisor is Liferay. I now volunteered to
try to convince him, that "Django" is the better choice.
Unfortunately, I don't know anything about Liferay, and I'm still
fairly new to Django as well. I know that these are two completely
different "systems".
To be a bit more specific about what is wanted (what we really need is
another topic):
-JSR-168 (or similar specification) and SOA;
-Capable to handle more than one programming language in data
activities as well as in application activities;
-Independent of Hardware, Software, programming language, operating
system (as much as possible)
Has some sort of a software library which is expandable and has
already enough basic business logics in a framework to quickly develop
a new application on top of it;
-Has a web services kind of API to the external components, so the
independency to any environment is as low as possible;
-Easy authority structures preferable via an external LDAP/X.500
system;
-Editorial capabilities (separation for writing, checking, publishing
and maintaining);
-Capable to automatically deal with the differences between the web
browsers (IE, Firefox, Safari, etc.);
-Able to (automatically) synchronize (and converting) data if these
data’s are used and/or distributed over more than one database;
-Relatively easily to backup;
-Relatively easily to maintain.
I'm well aware that there are many things mixed up, not belonging to
the question of "using Django or not", but I do not know how to put it
simpler, because the mentioned points above are the "cracking ponts"
to choose "something".
Does anyone have experience which she/he is willing to share with me?
If there is something other than Django that fits these "needs", I'm
very open for a hint, too.
Thank you in advance for taking the time to answer to my somewhat off-
topic post,
Nicola Jordan
Malcolm Tredinnick
On Sat, 2008-09-27 at 10:16 -0700, Nic Jordan wrote:
> Dear List,
>
> I'm currently involved in a project for building en entirely new site.
> The choice of our informatics-advisor is Liferay. I now volunteered to
> try to convince him, that "Django" is the better choice.
> Unfortunately, I don't know anything about Liferay, and I'm still
> fairly new to Django as well. I know that these are two completely
> different "systems".
Yeah, no kidding. :-)
>
> To be a bit more specific about what is wanted (what we really need is
> another topic):
> -JSR-168 (or similar specification) and SOA;
Oeople from the Java side of town always seem to assume that everybody
else knows what each particular JSR is (you're not the first to do
this). I got as far as getting to the Sun Java site to read JSR-168, but
the license says I can only use it for internal evaluation and since
there's a greater than zero chance I might one day want to implement
something "portlet" related in Django and it might even have a large
overlap with something Sun have previously done, I can't agree to that
license, so I can't read the document. What does the "portlet API" do?
Similarly, SOA is an architecture style. It's not the one Django is
normally used for (since REST-style architecture is more useful for the
types of things Django was built for), but it wouldn't be impossible to
do things in that style. After all, you're still sending data to a URL
that is then processed by a view and in your (Python) view functions you
can do whatever you like, including running that data through SOAPy or
ZSI or any other library that can be used
> -Capable to handle more than one programming language in data
> activities as well as in application activities;
What does this mean? Can you give an example, please, since "data and
application activities" just means "code" when I use the normal meanings
of the words. Django requires writing code in Python. You could just
Django on Jython and then call to Java code (modulo running a
non-released version of Jython at the moment, but that will change early
next year).
> -Independent of Hardware, Software, programming language, operating
> system (as much as possible)
Django is a Python framework. Liferay doesn't meet this requires,
either, since it's totally Java based. That being said, you can run
Python on more platforms than you can run Java on, so it's more
independent of hardware and OS in that respect.
> Has some sort of a software library which is expandable and has
> already enough basic business logics in a framework to quickly develop
> a new application on top of it;
You can see from djangosites.org, random browsing of this mailing and a
few quick Google searches that Django is designed to build a variety of
simple and complex applications quickly. But "quickly" is a very loaded
term, since it depends on the available skillset and complexity of the
task, for example. There are no doubt some seemingly very simple
applications for which Django would be inappropriate, but there are
complex ones for which it is highly appropriate. So looking for a
definitive answer here is a bit of a fool's errand.
I would be suspicious of choosing or rejecting *any* framework because
of a bullet-point like this (or many of the other ones in this list). I
realise this isn't necesarily your list, but so many of this points can
convincingly and correctly be answered with "both yes and no". Unless
there are some people (more than one!) in your team who have invested a
week or so in really trying to build something with both Django and the
alternatives, you aren't going to be able to make that sort of gut-feel
call.
> -Has a web services kind of API to the external components, so the
> independency to any environment is as low as possible;
Having an API is the easy bit. Hooking it up to the appropriate models,
etc, is highly problem-specific. As noted above, we have an API in that
Django accepts calls to URLs and there are Python libraries for
processing WS-* protocols. So I guess this is a "yes".
> -Easy authority structures preferable via an external LDAP/X.500
> system;
People have integrated Django's authentication system with LDAP in the
past. It doesn't come out of the box, but external authentication
backends are possible by design.
> -Editorial capabilities (separation for writing, checking, publishing
> and maintaining);
Look at the admin interface. Django isn't a Content Management System
per se, so the admin is the only built-in thing like this.
> -Capable to automatically deal with the differences between the web
> browsers (IE, Firefox, Safari, etc.);
There are some hacks (and they really are) to work around bugs in IE as
far as the HTTP protocol goes. As far as generating HTML/CSS/Javascript
that works everywhere, Django stays out of your way there and lets you
do whatever you want.
> -Able to (automatically) synchronize (and converting) data if these
> data’s are used and/or distributed over more than one database;
Not out of the box. But pretty easy to write scripts to do this. You're
not evaluating just Django here, after all. It's Django plus Python plus
available libraries.
> -Relatively easily to backup;
Backup what? The database is backed up however your database of choice
is backed up. The files are backed up however you choose to backup files
normally. I can't see how there would be any kind of differentiation on
this point.
> -Relatively easily to maintain.
Again, "relatively easy" is a comparitive term. For myself, anything in
Python is about 1000 times easier to maintain that most Java pieces of
code I've worked with. But I have friends working deep in the bowels of
Java shops where the reverse might well be true.
>
> I'm well aware that there are many things mixed up, not belonging to
> the question of "using Django or not", but I do not know how to put it
> simpler, because the mentioned points above are the "cracking ponts"
> to choose "something".
>
> Does anyone have experience which she/he is willing to share with me?
> If there is something other than Django that fits these "needs", I'm
> very open for a hint, too.
I doubt that there's anything that clearly fits or doesn't fit these
"requirements", since they're so non-specific and open to interpretation
that it's really a license for picking whatever takes the fancy. As
management requirements lists go, it's pretty typical and not that
useful for assesment.
I was serious in what I wrote above: you really have to roll up your
sleeves with one or two others and try implementing something
non-trivial in each platform and see how easy or hard it is. Those types
of run-off evaluations are still hard to interpret, since mistakes you
make the first time around and experiences gathered influence the second
implementation, but if you're really trying to work out the most
appropriate fit (rather than just validate a previous choice) and if the
same people work on each section, it's possible to draw some reasonably
valid conclusions.
Best of luck,
Malcolm
Nic Jordan
thank you Malcolm for your reply. I don't have anything really
specific, but I *think* I know so much now:
We have some static sites, those are already ported to the dcms
(language support) pluggable, so the cms part is pretty much solved.
That is true for Liferay as well, since it has a cms built in.
We have to deal very much with surveys, and there is nothing out of
the box for Django nor Liferay, so writing something like that is (as
far as I know) easier with Django. Database models, automatic admin
interface etc. But there is also the goal to have an "internal",
meaning intranet, file-system, unlike a normal file-system with "just"
directories, but something like a "general" and a user directory. As
far as my knowledge goes (and it isn't very far), neither Liferay nor
Django provide such means.
On all the other points a completely agree with you, but maybe that's
the reason why I have so much trouble finding a solution, because
there's lacking the "specificity" for this new project. So I really
have to digg into Django (*JOY*) and Liferay (*not so much joy*).
I'll try to resume what I've got so far (thanks to Malcolm's answers):
-neither Django nor Liferay are "better", they both focus on different
things
-There is a need for more specificity to be able to decide, best way
is to digg into both systems end evaluating
-API are possible in Django, also authentication is "simpel" to write
-Any other points need further investigation and to be more specific
or less "abstract"
If I'm wrong on this, please correct me.
Thank a lot for the support,
Nicola Jordan
On Sep 28, 4:15 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:
Warren
them is difficult. Like apples and oranges are both spherical fruits
that grow on trees, Django and Liferay are both web application
frameworks that *can* make developing web applications much easier.
Back when I was working with Liferay, one of the clients to which we
were advocating it found Plone and, since I had Python and a little
Zope experience, I was asked to compare the two based on a list
similar to Nic's.
The essence of some of the things I told that client seems to apply
here.
So, here is my advice:
If your shop has significant Python experience, use Django.
If your shop has significant Java experience, use Liferay.
If your shop has both, then evaluate the needs of your project against
the strengths and weaknesses of both frameworks, including the culture
of the communities surrounding the language platform.
If your shop has neither, learn Python and use Django. Its easier.
Benjamin Wohlwend
I'm a co-worker of Nic and want to clarify some points.
We work at an institute of a major university in Switzerland. Our
institute makes a habit out of employing students for its in-house web
development. As a result, the personnel in the webdev team fluctuates
quite often. Nic and myself maintain half a dozen web applications
(between 10-50 klocs each), without having been involved in the
initial development of any of them. Because most students employed in
the past weren't CS students (I'm only the second CS major working
here...), those apps are of varying quality, and a couple of them need
to be replaced ASAP.
Two of our webapps run on Zope 2, one is a TurboGears1 app, the rest
is PHP (not using a framework of any kind). In other words: we have
quite a bit of Python experience. As far as Nic and I go, our decision
would be Django, in a heartbeat.
Problem is, we do not make the decisions 'round here, the people
making the decisions are the ones proposing Liferay. They like that
there are commercial support plans for Liferay. They like that big
players like IBM and Sun have committed themselves to the Portlet
specs (JSR-168, JSR-268). They really love Java.
Our main problem in getting our bosses convinced are those sky-high
buzzwords like SOA, SOAP, web services, SaaS, virtualization -
buzzwords that have "Java" literally oozing out of them. While both
Nic and I highly doubt that our institute will ever expose one of our
apps as a web service, our bosses seem to think otherwise.
To show our bosses just how awesome Django is, I ported one of the PHP
sites to Django (using django-page-cms, sorry Matthias, couldn't get
my head wrapped around tusk-cms ;) ) in less than two days. The
initial development of that site took two weeks of two developers
working full time. Well, let's say they were kind of impressed by the
effort, but not sold on Django. You see, "getting things done" is not
a top priority at government-funded institutes like ours...
Well, we prepared a presentation today on Django vs. Liferay,
incorporating much of Malcolms comments (thanks again, we were
overwhelmed by the depth and sheer insightfulness of your answer!).
We'll hold that presentation to our bosses tomorrow, let's see how it
goes. If anything, I have the feeling that this whole thing will
someday make a great story on "The Daily WTF" :-)
Kind Regards,
Benjamin Wohlwend
P.S.: before someone asks: we're young and we need the money ;-)
Steve Holden
> [a minor tale of woe]
>
> P.S.: before someone asks: we're young and we need the money ;-)
>
Thanks for the explanation. Seems like you and Nic are learning about
corporate politics the hard way. Sadly the technical staff often don't
get to make much input into what are ostensibly technical decisions.
Don't be too downhearted if they end up choosing Liferay: at least you
have done your best to knock some sense into them.
regards
Steve
Jean-Christophe Kermagoret
if I were you, I'll go in the sense of your management because using
Liferay isn't in contradiction with using Django.
In fact, I think Liferay (and any JSR 168 container) aims at federating
portlets (just a kind of component after all) which may be written in
any language. Just imagine Liferay replaces Django template engine :
all your app (business logic + views - except template) can be written
with Django. Communications between portlets is a matter of js
communication and permit to set up SOA architecture based on REST,
exactly the buzz words your management likes :-)
And it's true that modern portlet container (JSR 286) like Liferay,
jBoss... can agregate new content dynamically and allows real
personalization by the end user in a very easy manner.
Hope that helps,
JC
Warren a écrit :