Django vs. Liferay
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". 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs. Liferay
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
Re: Django vs. Liferay
Dear List, 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 <[EMAIL PROTECTED]> wrote: > 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 reject
Re: Django vs. Liferay
Having worked with both systems, I would have to agree that comparing 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. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs. Liferay
Hi, 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 ;-) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs. Liferay
Benjamin Wohlwend wrote: > [a minor tale of woe] > > P.S.: before someone asks: we're young and we need the money ;-) > Is that one reason, or two? ;-) 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 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Django vs. Liferay
Hi, 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 : > Having worked with both systems, I would have to agree that comparing > 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. > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
