Slashdot Mirror
Enterprise vs. Open Source Portals?
lowvato asks: "I have recently been tasked with building two enterprise level portals. One is already in the making using Apache Jetspeed and the other is in the planning stage. I have been impressed with Jetspeed and its progress and versatility as a portal environment. One portal needs a very high level of security and interaction with disperate web services while the other is more of a community building service with CMS, forums, and so forth.
Upon a limited review of the commercial portal solutions, I have found it hard to determine what they offer over open source solutions (especially since a few are based on products like Jetspeed or UPortal). I would like to hear what others have found using commercial and open source portal products."
Zope may be what you are looking for. It's hard to beat for ease of use, maintenance, separation of code from content, etc. Zope is scalable, can also do enterprise-like stuff, connect to RDBMS and all, use any number of authentication schemes other than its own built-in scheme (LDAP, *nix passwd files, NT domains, databases). I believe you can also run Zope behind Apache w/SSL, which should take care of your security needs. Give it a try, anyway.
I thought portals went out with stock options, VRML, and "push."
I write in my journal
I completely forgot to mention the number one consumer of portals these days:
Individual companies.
Portals are an excellent "intranet" tool, offering company news and documents to their employees. They're often a better and cheaper alternative to investing in one of the Intranet-ware applications that are provided by M$ and others or trying to develop them in-house, since generally most of what an intranet needs to do is share documents, which can be done easily and well through a portal.
Karma: Chevy Kavalierma.
I had to work with Zope recently and had been quite underwhelmed :
1. Easy management : yes and no. It's full of "objects", "class", "methods", etc. I can understand that; my client cannot.
2. Separation of code from content : if you don't count DTML as "code", that may be true.
3. Authentication scheme : I tried to coax Zope into authenticating to a MySQL database. Two package seems to be doing what I wanted. One was full of bug, the other would have required that I port it from PostgreSQL to MySQL.
Quality of module vary greatly. Some are good, but a lot are outdated or broken.
The zope.org site suck big time. The search engine lack option and return too many hit without any regard to revelance.
Documentation is uneven. It's better than none at all, however.
Error messages are useless. Although it might be nice to know the function call stack, I would have prefered something more informative than "KeyError" for error message. And have a look at the data that made Zope choke, too.
I suppose it's a matter of taste. For the Python freak it might be ok. I personnally dislike it with passion.
:wq
Document Management? .. Plumtree has this, Jetspeed doesn't. I see this as being a pretty large effort to get this built in. Sure, I can arrange gadgets all over the place, but managing the content on these pages is another huge task I don't believe Jetspeed addresses.
Java, Pascal, C++, Python, Perl, etc. are all also full of objects, classes and methods. The programmer's job is to hide these things from the client behind a friendly interface.
Somewhat true, for DTML. However, Page Templates were recently introduced and they (mostly) separate code and presentation quite nicely.
Well, most search engines suck; that's why I use Google with the "site:" constraint.