I am new to Django, but am familiar with python. I am also familiar with
joomla (formerly mambo), and I would like someone to provide a comparison /
contrast between Django and joomla.... please, no hype, just the facts. I am
interested in the strengths and weaknesses of each.
Thanks folks,
Ps Please feel free to send directly to my email to cut down on list
traffic. tnx
--
Kind regards,
M Harris <><
Django is a framework where you can build a CMS, it doesn't come
with this behaviour after installed. You're going to have to make a
"Model" for "Article", code the functions to retrieve them, build each
display page (the html), etc...
The comparision can't really be made, since when you install Joomla
you get a very focused (even counting the plug-ins) solution. You
would have to build a CMS using what Django offers. Now, that's good
and bad :) You'll have complete control of the software, doing things
your way, adding features that you want.
If Joomla covers your needs as a CMS, go for it, unless you want
things differently, and that's where Djando would fit it.
I am sure someone has already built CMSs using Django, so a search
on the list archives and Google might be fruitful if you want a
starting point.
--
Julio Nobrega - http://www.inerciasensorial.com.br
A CMS like Joomla is a house, pre-built. A framework like Django is a
toolbox and some raw materials.
With the CMS, if you know you want a house, you're fine because that's
what you get. And you can customize it a little bit: you can repaint,
put down new floors, etc. If you're really ambitious you can add on
whole new rooms.
But if you need a restaurant or an office building, well, you're
stuck, because you've got a house and no way to turn it into another
type of building.
With the framework, if you want a house you build a house. If you want
a restaurant you build a restaurant. If you want an office building
you build an office building. And since you have the tools and raw
materials, you can go back and change things around later in ways that
wouldn't be possible if you'd just gotten a pre-built house.
Advantage of the CMS: pre-built, not as much work to do.
Disadvantage of the CMS: not nearly as flexible.
Advantage of the framework: nearly unlimited flexibility.
Disadvantage of the framework: more work, because you have to build up
what you want.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
On Apr 17, 2:09 am, "James Bennett" <ubernost...@gmail.com> wrote:
The other question I have for the community is this: Django ships with a
"simple" web server. Is this server designed for Django development /testing
only? Can it be safely put on-line, or is it better to run on Apache, etc.?
Thanks folks.
Not really. Although there are substantial numbers of parts of
things..fields to hold email addresses, phone numbers, etc. But not a
whole project that you could just customize and make into your own
contact application, alas.
> The other question I have for the community is this: Django ships with a
> "simple" web server. Is this server designed for Django development /testing
> only? Can it be safely put on-line, or is it better to run on Apache, etc.?
Run under Apache. The Django server would be slower and would be more
likely to fail once you got any kind of load on the server.
Todd
The Django server can only handle one request at a time, so "load"
would be defined as two people trying to access the site :)
Jay P.
The book is a very good place to start. The development team has
managed to take all of the different sorts of documentation and
examples spread over the main site and crunch it down into digestible
pieces. I wish the book had been around when I first started playing
with Django. :)
I can say I used Mambo before the split, and have toyed with Joomla
afterwards and Django has proven far more intuitive to use for
building custom applications. Like the house analogy, if you only
need it for a simple CMS, Joomla may be your best bet. If you want to
add features and have complete control, however, Django would be
better. Not to mention, the zen of Django is specifically content
management at a very abstract level - you define what content is, and
it manages the rest. You just fill in the blanks as to how it looks
and functions. The best part is, if you put together the models
first, the clients can start adding and manipulating content before
you're done with all of the functionality - just give them access to
the admin panel, if you want.
--
Michael
The next step is doing away with a predefined model altogether. Semantic
web CMS, anyone? ;-)
--
Nicola Larosa - nicola...@gmail.com
There are encouraging signs that more and more of us are choosing to wean
ourselves off our addiction to consumption, debt, and being too busy
and too tired for our own good. Out at the Edge, it's getting more
comfortable, more fun, and even a bit more crowded all the time.
-- Dave Pollard, September 2006
Have you looked at trunk/django/contrib/databrowse yet? :)
On Apr 19, 9:23 am, Nicola Larosa <nicola.lar...@gmail.com> wrote:
> Michael K wrote:
> > The best part is, if you put together the models first, the clients can
> > start adding and manipulating content before you're done with all of the
> > functionality - just give them access to the admin panel, if you want.
>
> The next step is doing away with a predefined model altogether. Semantic
> web CMS, anyone? ;-)
>
> --
> Nicola Larosa - nicola.lar...@gmail.com
Oh just the thought of it makes my head hurt. >.<
Although if something like that gets worked on, I wouldn't mind
helping where I can. :) (Assuming the work hasn't already been done!)
What can I say? I'm a masochist at heart.
--
Michael
Is that what Adrian's going for? I briefly tried out databrowse the
other day, and couldn't quite see the point (realizing of course that
it's brand new).
Jay P.
Wow, I don't update since 49xx, lo and behold, there's a new module
in contrib! Just briefly looking over it, it looks like it wraps
models for some black magic data browsing? And what's this? A plugin
hook? :)
--
Michael
This was the contrib that Adrian unveiled at PyCon2007 that had a
room full of applause. I beleve he referred to it as giving "the
treatment" or "the works" to your data. It allows easy
exploration of a data-set, as it will create views wherein your
data gets automatically linked and displayed saving tons of work.
I have a feeling this is going to become a killer-app for Django.
I missed its entry into contrib/ but look forward to toying with it!
-tkc
Well, I just meant views and models magically created based on the data.
From docs/databrowse:
"As the Django admin dynamically creates an admin interface by introspecting
your models, Databrowse dynamically creates a rich, browsable Web site by
introspecting your models.
"
Consider the case of a large dataset you're unfamiliar with. Consider
the case where you have a non-programmer trying to decide what to do
with data (or just get familiar with it). Consider the case of a
reporting app where a manager needs adhoc looks at the data.
Databrowse could be considered Access for the web.
Further reason to bemoan missing PyCon this year. The worst part is,
I'm originally from the Dallas area, so it's not like I didn't have
other excuses to go - just couldn't get the time off.
I agree, this is the one thing that was kinda missing (though not
missed) from Django. I have the perfect use for this.
Now all we need is a more advanced (additional contrib, maybe?)
permissions system. I've tried a few approaches experimentally, but
nothing seems to look or feel right, just yet. I have a project that
could be refactored and reduced in size if there were an "ownership"
concept in the auth module.
--
Michael
> Jeremy Dunck wrote:
>> Have you looked at trunk/django/contrib/databrowse yet? :)
Tim Chase wrote:
> This was the contrib that Adrian unveiled at PyCon2007 that had a
> room full of applause. I beleve he referred to it as giving "the
> treatment" or "the works" to your data. It allows easy
> exploration of a data-set, as it will create views wherein your
> data gets automatically linked and displayed saving tons of work.
> I have a feeling this is going to become a killer-app for Django.
It may be. It surely is a very useful addition. It is not what I was trying
to suggest, though.
Imagine, if you will, data that are not uniform. Data whose model is not
predetermined. Data whose attributes change from record to record.
This is the dream of the Semantic Web: a way of mixing data and metadata so
that you have an array of relations (like those in Dublin Core) that relate
subject and object (the RDF triple). And every object is defined by a set
of relations connecting it to other objects, in different ways for each
instance.
What for, you say? Well, I didn't know squat about the Semantic Web until a
few weeks ago, but often had the need for such flexibility in data
representation, that is, not having to know every possible domain change
and need in advance.
Then one day I stumbled upon Haystack, and what were just glimpses became
alive.
But just for a little while: Haystack is (was) a monolithic Java desktop
app, and its development stopped. The Simile project is trying to carry its
concepts on to the web world.
http://simile.mit.edu/
It looks like they are working mostly on the client side, but something
tells me that the need for a server side will arise, sooner or later. It
would be great exploring that side with Django.
Here, I've just handed you one of my deepest, secretest dreams: please
treat it gently. ;-)
This is something best handled by an RDF store or an object database,
neither of which is currently supported for Django; feel like writing
some new backends for us? ;)
IIRC Bill de hÓra was working on such a beast. Bill?
--
Antonio
James Bennett wrote:
> This is something best handled by an RDF store or an object database,
> neither of which is currently supported for Django; feel like writing
> some new backends for us? ;)
I gladly would, if I had the slightest idea about how it could be handled
by the admin interface...
--
Nicola Larosa - nicola...@gmail.com
Seems I may not be able to retain my title as "non-programmer" much longer.
What can I say? Python has made programming fun again.
-- Jeff Croft, December 2006
> Databrowse could be considered Access for the web.
w00t - coolest thing since the mini idli
--
regards
kg
http://lawgon.livejournal.com
http://nrcfosshelpline.in/web/
> It looks like they are working mostly on the client side, but
> something
> tells me that the need for a server side will arise, sooner or
> later. It
> would be great exploring that side with Django.
Interesting discussion. I'm just about to implement a slightly
'semantish' serverside backend in django - it's the fourth
incarnation acutally: the first was done with python and the zope DB
(it just produced XML files that were eaten by a Flash interface),
the second was done with mod_python, Apache and MySQL, number three
Zope and postgreSQL.
I've been playing around with django for some weeks now, and I like
the approach a lot. I was surprised how quickly I could reimplement
the functionality of my architecture (it's called 'paragon') in
django, for you interest here's the models.
My aim is to combine the strictness of semantics with the flexibility
of a kind of 'digital scrapbook' (in Germany, we speak of a
'Zettelkasten' or 'sheetbox').
As you can see, I don't care about restrictions very much - classes
can be abstract or concrete, there's no concept of cardinality etc.
Inheritance is also only 'nominal' yet: As soon as an object has the
relation 'is_instance_of' or 'is_subclass_of', the business logic has
to know how to deal with that.
The main advantage is that I can model almost everything with this
approach: persons, topics, books, exhibitions, conferences,
scientific paradigms, person's affilitations etc.
The project began in the arts field as an 'open source webbased
ontology' for the arts and related fields like architecture,
psychology, physics, cognitive scienence.
If you'd like to look at the current implementation: http://
www.christoph-pingel.de/paragon/objectpage/George_Lakoff
Comments, proposals, criticism are welcome. I'm quite new to django,
so perhaps I'm missing some things to make the design even more sober
and easy to maintain.
best regards,
Christoph
Here's the models if you'd like to play with it:
----------------
from django.db import models
class pg_object(models.Model):
"""
Objects and Classes of Objects
"""
object_name = models.CharField(maxlength=300)
def __str__(self):
return self.object_name
class Admin:
pass
class pg_atm(models.Model):
"""
A thesaurus of possible attribute meanings.
A theasaurus means less ambiguity and better possibilities to
map e.g. BibTex entries in a controlled manner
"""
# atm_bedeutung = models.CharField(maxlength=200) -- it's probably
better to use a more generic approach vs. i18n.
atm_meaning = models.CharField(maxlength=200)
def __str__(self):
return self.atm_bedeutung
class Admin:
pass
class pg_rlt(models.Model):
"""
Possible relations between objects.
I'm not sure if it's possible (nor how) to implement a ForeignKey
into the same table
"""
rlt_relation = models.CharField(maxlength=200)
rlt_backrelation_id = models.IntegerField()
rlt_times_used = models.IntegerField()
def __str__(self):
return self.rlt_relation
class Admin:
pass
class pg_atp(models.Model):
"""
Here we store the actual poperties/slots, whatever you call it.
Each key/value pair exists only once. Objects register properties
via a link table (pg_oal below)
"""
atp_bedeutung = models.ForeignKey(pg_atm)
atp_value = models.TextField()
def __str__(self):
return "%s %s" % (self.atp_bedeutung, self.atp_value)
class Admin:
pass
class pg_oal(models.Model):
"""
The link table for objects to register properties
'oal' stands for object attribute link
"""
oal_object = models.ForeignKey(pg_object,
edit_inline=models.TABULAR, num_in_admin=3)
oal_attribute = models.ForeignKey(pg_atp, core=True)
def __str__(self):
return "%s %s" % (self.oal_object, self.oal_attribute)
class Admin:
pass
class pg_ool(models.Model):
"""
The link table for objects to relate to other objects (or classes).
'ool' stands for object object link
"""
ool_source = models.ForeignKey(pg_object, related_name="Quelle der
Relation")
ool_relation = models.ForeignKey(pg_rlt)
ool_target = models.ForeignKey(pg_object, related_name="Ziel der
Relation")
def __str__(self):
return "%s %s %s" % (self.ool_source, self.ool_relation,
self.ool_target)
class Admin:
pass