The Angular Mini-Book is a
guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and
deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.
Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.
For book updates, follow @angular_book on Twitter.
The JHipster Mini-Book is a
guide to getting started with hip technologies today: Angular, Bootstrap, and Spring
Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.
This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.
For book updates, follow @jhipster-book on Twitter.
We arrived back in Denver after an awesome week in Cancun. There's no real good stories to tell, just lots of fun, laughter and relaxation with family. Below are some pictures from our trip, as well as many others on Flickr.
Right before I left last Saturday, I released AppFuse 1.9, then went to watch the Broncos vs. Patriots at Invesco Field. Today, it's the Steelers. It's pretty cool to come home to a town this excited. Go Broncos!!
A few weeks ago, I realized I was developing webapps the hard way, by re-deploying everytime I made a change. It's important to have a build process that can create a WAR and deploy, but it's also important to have a system where you can edit/save/view changes w/o ever deploying.
I spent some time this weekend working with Jetty Launcher, Eclipse 3.1 and the latest version of Equinox. Below are instructions on how to make the two work together. Once you've completed the steps below, you should be able to launch Jetty and edit/save Java files or JSP files in Equinox - and the changes will show up immediately in your webapp. No deployment or Ant/Maven interaction necessary.
I've tested this setup on Eclipse 3.1, using both OS X and Windows XP.
Step 1: Install Jetty and Launcher
Download and install Jetty. I tested 5.1.4 and 5.1.6 and both seem to work (6.0.0 Beta does not). In Eclipse, go to Help » Software Updates » Find and Install. Select Search for new features to install and click Next. Click on the New Remote Site button and enter "Jetty Launcher" for the name and "http://jettylauncher.sourceforge.net/updates" for the URL. Click OK, continue to download and restart your workspace.
Step 2: Install Equinox and create Eclipse project files
Download Equinox 1.5 beta 1 and extract to your workspace (I generally use c:\Source on Windows and /Users/${username}/dev on OS X). Download Maven 2.0, install it, and add $M2_HOME/bin to your $PATH. From the command line, cd into the equinox directory and type "mvn eclipse:eclipse". Get a cup of coffee or soda while you wait for Maven to download all the dependencies.
Once the project files have been created, open Eclipse and go to File » New » Project » Java Project. Click Next and type "equinox" in the Project name box. Click Finish to begin importing the project. You'll probably get an error like the following. Click OK to continue.
Click Next to continue (I had to click it a few times before it took me to the next screen). On the next screen (Define the Java build settings), select the web directory and click Configure inclusion and exclusion filters. Click the Add button for Exclusion patterns and enter "WEB-INF/classes/" (the trailing slash is important).
You're not done yet, now you need to define the M2_REPO variable that points to all the downloaded dependencies. Click the Libraries tab and then the "Add Variable" button as seen below.
Click the Configure Variables button and add a new one with a name of M2_REPO and Path of to your local Maven repository (/Users/${username}/.m2/repository on OS X and C:\Documents and Settings\${username}\.m2\repository on Windows). Click OK, Cancel and then Finish.
Step 3: Configure Jetty Launcher for Equinox
In Eclipse, go to Run » Debug and select Jetty Web in the Configurations panel. Click the New button. In the "Use Options" section, use "web" for the webapp root and (optionally) "/equinox" for the context name.
Jetty has issues running applications that use commons-logging, so you'll need to turn off all the INFO logging from the projects that Equinox uses. To do this, click on the Arguments tab and add the following to the list of VM arguments:
-DDEBUG -DDEBUG_PATTERNS=org.appfuse -DDEBUG_VERBOSE=-1
This can be placed on the line below the -Djetty.home argument. For more information on logging in Jetty, see the Jetty logging and debugging tutorial.
Step 4: Start Jetty in debug mode and modify to your hearts content
Click Apply and then Debug, and watch Jetty startup. If you go to http://localhost:8080/equinox/users.html in your browser, you should see a log message like the following:
11:44:25.855 DEBUG [SocketListener0-1] org.appfuse.web.UserController.handleRequest (UserController.java:24) >29> entering 'handleRequest' method...
You should be able to click on "UserController.java:24" to navigate to the UserController.java class. In this class, modify the log.debug(...) message, save the file and hit refresh on your browser. The console should spit out your updated log message. If it didn't, go to Window » Preferences » Workspace and make sure Build automatically is checked.
As far as I can tell, edit/save/refresh will work for .java and .jsp files, but not for .xml files. For that, the Jetty Launcher adds a Stop/Restart Jetty icon to your Eclipse toolbar. This setup seems to work great, except for the fact that you can't see when Jetty is done starting up in the console.
NOTE: I tried to get a similar setup working with the Tomcat Eclipse Plugin (v3.1 beta) and the Eclipse Web Tools Project (v0.7.1). Neither worked as smoothly, and the WTP wouldn't even deploy to Tomcat.
For the last few years, I've always done Java webapp development the hard way. Yeah, I'm the guy that makes Dion cringe (although I'm pretty sure he's not referring directly to me). I edit a class/jsp/xml file and run "ant deploy reload". Then I wait a few seconds for my context to reload in Tomcat. Luckily, I do mostly test-first development, so it's rare that I have to open my browser to test stuff. However, with the power of CSS and Ajax, manual testing in a browser is becoming more and more useful (although Selenium may solve that).
I've long resisted the power of the IDE, b/c I've always trusted Ant and felt confortable with the command line. However, I'm ready for a change. I'm ready to start developing Equinox and AppFuse-based applications using the edit/save/auto-reload cycle. So how do I get started? Where's the instructions for setting up my IDEs to work this way?
I prefer to use Eclipse and IDEA for development - so I'll likely try to get this working in both. If I get it working, I'll make sure and provide good documentation so others can do the same. I'm also willing to make any changes in project structure to make this happen; modifying build.xml (or pom.xml) to accomodate shouldn't be too difficult.
Simon used to work for IBM, on a video conferencing product. In 1994, Simon would fly all over the world to tell everyone about it. The last 10 years have brought many changes. When Simon used to travel in 1994, he needed cash and travellers checks, airline tickets, telephone kiosks and sent mail through the regular ol' postal system. Fast forward to 2004, and we have ATM cards and a "global identity card" (a Visa card), e-tickets, GSM mobile phones and e-mail. We're now in the participation age.
If we were massively connected:
Security would no longer concern only boundaries. Before the participation age, security was a matter of "how do I keep you out". Now it's "who are you can you prove that". It's all about digital identity now.
Software would have nowhere and everyone to run. Service orientation is how software is build today. Simon believes it'll happen through REST-based services, rather than by employing web services.
Software pricing should not track ephemera [definition]. We're now switching to value-based pricing.
Markets would become conversations (from The Cluetrain Manifesto). This idea led Simon to start blogs.sun.com.
Closed-room development would be insufficient. The old way was lock smart people in a room and slide pizza under the door - and then charge others admission fees to watch them work. Software that's developed out in the open gets better and better b/c you can get all the experts working on it. This is called Open Source. The initial objective of Open Source was to undermine companies like Microsoft and Sun - but now it's the best way to write software in a connected society.
Open Source in a Nutshell: a community of developers, sharing a code commons, create "wealth" from the commons, enriching the commons in the process. The "craft guilds" have been rediscovered in a sense. Open source is not communism, but more like Connected Capitalism.
There are a number of different open source licenses:
According to Simon, the best license is the one that gives the most freedom to the most people. Class A licenses promote freedom to innovate, but do not protect the commons. Class C licenses promote constant growth of the commons but limit the freedom of the developer to use their own innovation however they want. Class B licenses balance both freedoms protecting and enriching the commons but leaving innovators free to use their work in any commons.
The overlooked corners of open source: it's not licenses, there's no more limelight needed for those. However, there is a problem now - and that's license proliferation. There's too many licenses, we need fewer so it's easier to choose. We need better motivational models: how do we leave room for the motivations of diverse contributors?
The overlooked corner of open source is Governance. Apache is a good example of how Governance should be done. Bad governance is the primary vector for disease in open source. If the only way to contribute back is to go through one company that chooses committers, the project is likely doomed.
Software Patents happen, get over it. "Parallel Filing" means Corporations own patents on pretty much anything they touch. If you don't, your competitor will. The nature of US law means all must play. Using patents defensively is a routine element of corporation-to-corporation interaction. Software patents are a zone on the continuum - even their detractors have to deal with them. Until world trade is reformed, software patents happen.
So how do you protect yourself?
Simon believes all 3 approaches are needed to protect ourselves from software patents. He believes that #2 and #3 should be mandatory for standards bodies and open source projects.
Summary: The next phase of F/L/OSS is upon us. The Virtuous Cycle of open source needs a health check. We need to reduce license proliferation by dealing with its causes. We need to leave room for the motivations of all contributors. Don't sacrifice the freedom of developers for an ideology. Governance best practice needs an advocate.
F/L/OSS Alone is not enough for freedom - we need standards. Open standards set end users free to choose. Development and deployment are not the same thing. Standard Formats + Open Source = Freedom.
Software Patents demand multiple defenses. We need to lobby the governing bodies of our countries and put a stop to patents.
The main reason that Geronimo was started was to have a BSD-style licensed Java application server. The other two open-source application servers are JOnAS and JBoss, both of which are LGPL. The advantage of having a BSD/Apache licensed container is that companies can put it into their products, or develop products with it - w/o worrying about licensing issues. Bruce says IBM just validated the goals of Geronimo with their WebSphere Community Edition.
Geronimo's architecture is designed around GBeans - which are services that are pluggable inside of the kernel. To learn more about GBeans, see Jeff Genender's article "Integrate third-party components into Geronimo". The GBean is an IoC container in itself. Bruce is now showing a GBean Descriptor for ActiveMQ. There are only a few main elements in this XML file: multiple <dependency> elements and <gbean> elements. The dependency element refers to a JAR and the idea was borrowed from the Maven project.
Bruce, the poster-boy for Maven 2 only made it 15 minutes before he mentioned Maven. 
For more information about integrating ActiveMQ in Geronimo, see Sing Li's article "Magic with JMS, MDBs, and ActiveMQ in Geronimo".
Deployers vs. Builders: Deployers are J2EE specific, Builders are Geronimo specific. The Geronimo Deployer is JSR-88 compliant and handles both deployment and distribution. Personally, I'm a little disappointed that Geronimo doesn't support hot-deploy out-of-the-box, but I can understand their desire to be spec-compliant first, and developer-friendly 2nd. After all, it is an IBM product.
Geronimo's deployer is currently a script that you can pass arguments into. There is also a webapp console (developed and donated by Gluecode) that's based on portlets. It uses JetSpeed under the covers and looks to be a pretty slick little webapp. Bruce started up Geronimo and showed us the console UI - it appears Geronimo's default footprint is about 20 MB.
Custom Assemblies: One of the nice things about Geronimo is that it's so configurable. Because of it's architecture, you can easily create custom assemblies. Here's a few examples:
The Geronimo Kernel and GBeans make all of this possible. This is pretty cool IMO, especially with the whole Agile Java EE movement. Bruce thinks this is real future of Geronimo: the stacks that can be created with it. He expects the innovation and ideas in this area will come from the community and what users want.
Geronimo Community: Made up of many different open-source projects: MX4J, ActiveMQ, Tomcat, ActiveCluster, HOWL, JOTM, TranQL, Derby, Jetty, ServiceMix, OpenEJB. Rather than re-creating everything (the ol' NIH syndrome), the Geronimo team has tried to embrace and re-use other open source projects as much as possible. Many of the committers on the aforementioned projects are Geronimo committers or founders.
Bruce's favorite quote: In open source, we come for the code, we stay for the people.
Project Status: Now a top-level Apache project. Has officially passed J2EE 1.4 certification tests. The official 1.0 release date is "when it's done it's done", but the developers are hoping to finish by ApacheCon.
Below are notes I took while attending Tom Bender's talk on Mule at the Colorado Software Summit:
SOA: A collection of services with well-defined interfaces and a shared communication model is called a service-oriented architecture.
ESB: Provides a light weight, loosely coupled, event-driven SAO with a highly distributed universe of naming routing destinations across a multi-protocol message bus.
Four Tenets of SAO (as proposed by Don Box):
Properties of an ESB: Light Weight, Loosely Coupled, Event-Driven, Transactional, Securable, Distributed Network Topologies, Abstract Endpoints, Intelligent Routing, Message Transformation (inbound/outbound), Multi-Protocol Message Bus.
One of the main differences between application servers and ESBs is appservers are traditionally integrated with a hub-and-spoke architecture. ESBs, on the other hand, use a distributed integration architecture.
Mule - What is it?
Ross Mason is the founder and primary developer of Mule. From its homepage:
Mule is an Enterprise Service Bus (ESB) messaging framework. It is a scalable, highly distributable object broker that can seamlessly handle interactions with services and applications using disparate transport and messaging technologies.
Mule is an event-based architecture. Actions within a Mule network are triggered by either events occurring in Mule or in external systems. It's a light-weight messaging framework that's highly distributable and very pluggable (i.e. for multiple transports and protocols). Mule supports Web Services using Axis or Glue.
A Closer Look at Mule
The basic building block is a "UMO Component". This component is used to wire applications together - it's basically a POJO that can optionally implement interfaces if it wants to hook into lifecycle events. An application communicates with the UMO component through a channel (i.e. TCP/IP or JMS). This channel talks to a message receiver that works with a connector that's backed by a transformer and formats it for the UMO component (whoa, that's a mouthful - and that's only inbound!). When going to the receiving application, the process starts from the UMO component, goes though the outbound router - and plows through the whole transformer » connector » message dispatch » channel » application process again. Here's a diagram of this process that I found on Mule's website:
Mule supports many different endpoints: POP3/SMTP, JMS Topic or Queue, HTTP, File, VM (w/in the JVM), SOAP, RMI and EJB. Each of these have their own URI prefix.
I tuned out for the rest of Tom's talk (sorry Tom). The whole ESB topic is pretty dry IMO, but Tom seemed to do a good job of keeping the audience interested.
I love the idea of Mike Stenhouse's CSS Framework. It's so simple: name the elements in your XHTML with a specific set of names, and then create your CSS to match that. The only problem with this framework is I haven't seen any good-looking designs on top of it. For good-looking design examples, see the CSS Zen Garden or Open Source Web Design.
While the CSS Zen Garden is nice, most of the designs are not useable for web applications. They're more of a showcase of what CSS can do, and often contain too many images for a real-world application or website. The designs from oswd.org, on the other hand, are perfect for web applications. However, the underlying HTML is different for each design.
So how do we marry the two? Maybe we should lobby some designers at oswd.org to use the CSS Framework for their designs? I think this would be a great asset to many communities - imagine what you could do with your Drupal theme if you didn't have to change your template files (only CSS). That'd be pretty cool.
In my last post, I narrowed my open source CMS candidates down to Joomla and Drupal. I was hoping to have a choice made by Monday morning, implement the design in the morning, and populate the content in the afternoon. Two days later and I'm now where I was hoping to be on Monday morning. I've spent the last two days implementing both Joomla and Drupal. Monday, I spent most of the day with
Joomla. While it was easy to apply my own theme, I became very discouraged when I discovered I didn't have full control over the HTML markup produced. All of the content I produced was wrapped with a <table> - and from what I could tell, it was impossible for me to change that w/o hacking Joomla's code.
Based on that discovery, as well as the overwhelming number of pro-Drupal comments I received, I moved on to implementing Drupal. Monday night and yesterday were spent with Drupal. It's been extremely frustrating, but mostly because of all the CSS I had to write. The major problem with Drupal is the admin interface uses the same template as the reader interface. I did find a nice way to use an existing theme for the admin, and our own for the reader - but decided not to use it because it would give content authors the wrong impression of what their stuff looks like.
The majority of the time I've spent with Drupal has been modifying templates and installing modules. For the most part, Drupal doesn't come with everything you might need. I found the CivicSpace download to be much more complete with modules I needed. In addition, it has an installer which makes things a bit easier to setup for a web designer. I'm currently using the Article module, which works quite well, but I wish I could create multiple blocks for different categories (taxomies). Instead, I had to hack up my own block using some SQL to select all the "news" content types (for a Recent News block).
My biggest problem with Drupal continues to be my lack of knowledge. Luckily, there's a plethora of information out there and a lot of people are using it. I've been able to use the Drupal Forums as well as Google to solve most of my issues. Now the hard part comes - I need to show it to the designer/marketing folks and teach them how to use it.
The brochure site in an hour tutorial was extremely helpful for me to get started with an About page, Contact Us page, and Press Releases. However, it says to use "books" to create pages, and I've seen others recommend "page" and "story". So which is the best one to use? Should I advocate using "page" for regular site pages, and then "story" for our articles and whitepapers? Or should we use "book page" for the main pages. I'd like to limit the number of choices if possible.
I think the major problem with using Drupal is going to be tweaking our template. Every time I see a new custom theme (like this one) I want to steal stuff. Right now, I'm using a design from oswd.org and much of the CSS from the spreadfirefox theme.
Conclusion: No CMS is perfect. You'll have to hack it on one way or another to make it fit your needs. Drupal seems to be used by many web designers w/ little to no programming skills. Most folks love it and I've received many, many positive comments about it. I've received hardly any positive comments about Joomla. Zope and Plone also seemed to inspire hatred among some users.
Lesson Learned: Listen to your readers. Other users' experience is one of the most valuable indicators of a good open source project.
This is the third and final post in my quest to find the best open source
CMS for my needs. Previous posts include Building
a website with an Open Source CMS and Open
Source CMS Evaluation - Part I: Installation. Based on these two posts,
reader feedback, and my installation experience, the final round of candidates
include Joomla, Drupal, Magnolia,
OpenCms and MeshCMS.
These are listed in the order that I expected the final rankings to be -
just to let you know what my feelings were going into this final process.
The CMS I choose will be used to build Virtuas's website, as well as customers of Virtuas. By using a CMS to produce websites, the design is separated from the content - and the "adding content" process can be much easier for the customer. This greatly simplifies the "creating a website" process for us, and will likely save our customers a fair amount of design costs. In addition, it makes it much easier for site owner's to maintain the site after it's been published.
As for Virtuas's site, it's static right now, and we'd like to change that. We want to ability to show recent blog posts on the front page, as well as make it easy for Practice Leaders to publish articles. In addition, it should be easy for our designers to change the design (1-2 files) and for our marketing team to add press releases and update existing content. Tomorrow, I'll be presenting my choice to the rest of the team, and we hope to design and start publishing content this week. Our goal is to have a new Virtuas site up and running one week from today.
My goal today was to see how easy each CMS was to customize. In addition, I wanted to see how easy it was to publish an article, as well as to aggregate our latest RSS feed titles onto the homepage. To test the design customizability, I tried to reproduce the current Virtuas homepage. Then I published Jeff's Geronimo Article, and attempted to aggregate feeds from Maria's and Bruce's blogs. My main reason for putting the Java CMS'es lower than the PHP ones in my suspected order of finishing is because I don't they don't have the RSS Aggregation feature.
Rather than just jumping in and using each CMS in anger, I tried to start off by reading the documentation for each. My main focus was on how to customize, but I also looked for an RSS Aggregation feature and ease-of-publishing for articles. I read documentation for 15-20 minutes, then dived into creating a custom theme and adding content. I installed each CMS on my PowerBook, and used Safari and Firefox on OS X, as well as Firefox on Windows XP in some cases.
MeshCMS - I spent 40 minutes looking into MeshCMS before I knew it wasn't the one. The main problem I had with it was the upgrade process. To upgrade to a new version, they recommend that you use symlinks to your files and store them in a separate location on the file system. While this may work for some, it seems a little brittle to me. I'd rather use a solution that keeps everything stored outside of the application by default. Creating a new theme was quite easy - but there didn't seem to be any support for multiple menus (i.e. global and local navigation), nor was there any means to customize the menu template.
I did manage to blow up the whole application at one point, simply because I was missing a JSP tag in my template. Since I had this template selected for the administration as well - it hosed the whole application and spit out stack traces for each page. Luckily, renaming the template directory caused MeshCMS change to revert to the default settings and everything was fixed. The interesting thing about MeshCMS is it looks very similar to the SiteMesh+JSPWiki CMS I wrote a few weeks ago. However, mine allowed full menu creation by editing/creating wiki pages.
OpenCms - When I installed OpenCms a couple of days ago,
I initially did it on Windows. Everything worked fine and after waiting 18
minutes for everything to import, I was able to browse and edit the default
site. However, today was a different story. The version I installed on my
Windows XP box no longer works. When I got to http://localhost:8080/opencms/,
I get a directory listing with "resources" and "setup" on it. The same day
I installed OpenCms on Windows, I installed it on my PowerBook. It took 38
minutes to complete, but nevertheless, it said the process worked. Today
I re-ran the setup and now I have the same result as on my Windows XP box.
If the setup and installation is this fragile, I'm not interested. Blame
me and the fact that I'm a redneck all you like, but the Magnolia installation is still functioning just
fine.
Magnolia - I spent about a half hour with Magnolia before I knew it wasn't for me. While the admin UI is impressive with all it's Ajax goodies, creating a new template is cumbersome and not designer-friendly at all. You have to create a "new node" and then a bunch of "data nodes" under that. The documentation (a QuickStart PDF) is 17 pages long and forgets to mention the "title" data node is needed before the template will show up properly as an option. Once you've created a new template in the admin UI, you have to create the template on your file system - inside the web application. This may make it difficult to upgrade if you're deploying Magnolia as a WAR. The worst part is after creating the template, you have to restart the server. WTF? That seems a bit ridiculous to me. Granted you'll likely be designing your master template in a development environment - but good luck installing Magnolia for a client and having them create a new template.
One of the most interesting things about Magnolia is most of the folks who've recommended it have highlighted that it's "built on the revolutionary Java Content Repository Standard JSR-170". While I can admire the technical merits of this effort, it doesn't necessarily make this a good product. A good product, IMHO, is easy and intuitive to use. The admin interface for Magnolia is not intuitive. I like the fact that I can right-click on a page/node/etc., but on my Mac (with Firefox and Safari), the real context menu shows up on top of the application menu after a second or two. I'm going to pass on Magnolia due to the fact that its not designer friendly, as well as the fact that templates can't be edited in the browser. It looks like something that might be very interesting for developers, but it's simply not friendly for HTML developers.
At this point, it's 10:30 p.m. on Sunday night. I need to make a decision before I go to bed tonight and I'm scheduled to meet with our designer at 7:00 a.m. to start implementing his new design. I haven't started the PHP options, and I've had a couple new ones recommended on my blog while doing this evaluation today. Mal recommended Exponent and Jacob recommended MySource Matrix.
Because I'm down to two choices (and I haven't tried to customize either one), I decided it was worth looking at both of these PHP solutions. Exponent installed easy enough, but MySource Matrix failed miserably. Joomla, Drupal and Exponent all had an easy-to-use web installer that *just worked*. MySource spit out a bunch of permissions errors (even after chmod -R 777 *) and told me I had to run .php files from the command line. Since the other options all installed easily, I decided not to continue evaluating MySource Matrix.
Exponent - I didn't spend very long looking at Exponent. At first, I didn't think it had any documentation b/c it was a bit difficult to find on their site. Maybe it's because they don't have a background set on their site and my browser defaults to gray - making the gray text difficult to read. Even w/o documentation, I was able to navigate around the default Exponent site and figure out how to edit content. It's an easy UI to use, but again I was disappointed to find the "corporate" theme doesn't have a white background. Most good web designers know to set a default background color - and it always annoys me when someone misses this step. It's possible they don't set the background on purpose - like Yahoo does.
The deal-breaker with this CMS was that I couldn't edit any files w/in my browser to change anything (all I wanted was a white background). While it's theme management and templating looks powerful - it's another file-based system where you have to configure everything and then upload it. I agree that this is likely the path that web designers will want to use to get started - but I think it's important that files can be tweaked on-the-fly. Using a good FTP tool is certainly an option, but I'd prefer theme-editing to be part of my CMS. The one thing I did like about this CMS was the clean URLs. Granted, they aren't static-looking by any means, but having a simple ?section=# seems cleaner than the multiple parameters that other systems use.
Drupal - This CMS seems to have a lot of things I want/need as first class citizens. A blog, news feed aggregation and the ability to provide pretty URLs (aliases) for more cryptic CMS-type URLs. I couldn't get the URL aliases to work, but I suspect I was doing something wrong and didn't give it enough attention. I didn't spend a whole lot of time with this CMS, but rather just browsed around the admin interface and read a bit about how to create themes. I installed the PHPTemplate engine, but never installed any themes. When I found out I couldn't edit any of the uploaded templates contents, I started to get discouraged by Drupal. One thing I found disappointing, with both Drupal and Joomla, is they seemed to hard-code my server name into many of their URLs. When I installed these applications on my PowerBook, I used "localhost" for the server name. When testing out things from my Windows box, I couldn't even login to Drupal b/c it kept redirecting me to "localhost". Joomla had a similar problem with localhost, except that it only screwed up stylesheet paths. I was still able to administer the application.
Joomla - My time with Drupal was short-lived, mainly because I was itching to start playing with Joomla - which I've heard a lot of good things about in the past week. Furthermore, it's got a really good-looking administration UI. It's the type of UI that a designer would look at and appreciate. When trying to edit pages from my Windows box - everything worked, but I couldn't save the page. No JavaScript errors or anything, there was simply no reaction. Editing pages and content from my PowerBook solved the problem. I was able to easily create a simple theme that looked like virtuas.com and upload it. The theme isn't perfect, but it was easy enough to create using the Velvet theme from Joomlashack.com as a template. The weird thing about Joomla, at least with the default install, is there's no notion of pages. Everything is some sort of news item. In the pages I created, I was also unable to remove all the authoring notation and other junk that I don't want to show. The admin UI had options to remove the stuff, but even after "applying" the changes, they still showed up in the reader view.
It's now 1:30 a.m. on Monday morning and the last three CMS's definitely didn't get the attention they deserved. Nevertheless, I think they're the best of the bunch. Not only were they much easier (and quicker) to install than the Java options, but their UIs are also good-looking and easy to use. Drupal and Joomla both seem like excellent choices. Drupal seems to be more of what I'm looking for since it has all the features I want, and allows aliasing of URLs to make it appear like a static site. However, Joomla is a lot more eye-catching and that alone makes me want to use it. Neither of these CMS'es seem to have a full-featured blogging engine, at least not one that's as good as Roller.
Conclusion: I'm going to recommend we use Joomla,
and look into doing some URL Rewriting to pretty up it's URLs. I doubt
there's a whole lot we can do, but I'd like to figure out a way to make them
a bit more search engine friendly. Drupal seems like an excellent choice
as well, but the fact that I can't edit templates from the UI kinda sucks.
Thanks
for listening y'all - all your comments and feedback during this evaluation have
been great.
I think the open source community has done an excellent job of figuring out how to create frameworks for developing web applications. But what about websites. You know, the web presence that every company wants - for minimal cost. For most companies, it's nothing more than 5-10 pages that tells a bit about the company, show some management folks and tells you how to get to their offices.
I've developed many websites over the years, many that were static, but more that were dynamic. The unfortunate thing about all of them is they required someone technical to update them. Often, the client had to contact me if they wanted anything new on the site. I've often thought there was a better solution - and I think I'm at a point where I know what customers want, and I know how to provide it. The solution is a Content Management Solution (CMS). One of the biggest problems with static websites is they're not dynamic enough. A CMS can alleviate this problem by reducing the bottleneck that a traditional "webmaster" creates.
In my mind, there are a couple of things that make a good CMS: 1) it's open source (to minimize costs to the client) and 2) it's easy to customize. On the customization front, my demands are a bit more rigorous - mainly because I know what many folks want in a website. Here are my main criteria for a good open source CMS - when it's used to power a regular ol' client-updateable website:
For technical companies (such as Virtuas), there are a few additional requirements I'd like to see:
So I've started looking at open source CMS's that fill my requirements. Last weekend, I wrote a solution that fills all of these requirements using SiteMesh, JSPWiki, CSS Framework, Acegi Security and the URL Rewrite Filter. It only took me about 6 hours to complete, but after completing it - I started wondering if I really wanted to start another open source project and maintain it. The answer is no, I don't want to create something new - I want to use something that's already out there. However, since I do have something that satisfies all my requirements, I will use it if I can't tweak an existing OS CMS enough.
Here are a list of CMS's that I'll be looking at in the next week or so. If you're associated with any of these projects, please leave a comment and let me know how many of my requirements you satisfy.
I'm a bit hesitant on Daisy b/c it requires XSLT knowledge for design customization. Magnolia has long URLs and doesn't appear like a static site - and the PHP ones often have .php in their URLs. It should be an interesting investigation to see if these (seemingly) heavyweight solutions can solve a few simple requirements.
