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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
