From the Inbox

I've received a number of emails this week filled with great questions. I thought I'd answer two here that may be of interest to others.

1. How is a web team at a large church like Fellowship structured? Do you have a content production pipeline or do you have a more distributed approach (i.e. Open Source methodology) with people from each area contributing?

This is by far the most common question we receive because so many churches, including Fellowship, struggle with it. At Fellowship, we have a communications/graphics department that is responsible for all print materials (bulletins, signage, brochures, direct mail, and more). This team is completely separate from the web team. I would estimate that half of the graphics you see on FellowshipChurch.com are based on images and logos created by the graphics department. The content side is more a story of thirds; one-third from communications, one-third from ministries, and one-third from the web team.

Currently, all requests for website changes or additions come to me and I distribute them to the team. We have reached the point, however, where that system is no longer sustainable. With four sites and four campuses, there is simply too much content for my group to manage. More importantly, I can't have my primary graphics person spending a majority of his time on text.

So, as part of our new site and platform, we are building a content management system to turn over much of the site content to our staff. The content will have an approval process, but the primary responsibility will be in the hands of the people on the front lines of ministry.

2. Can you clarify what aspects of ASP.NET you found more complex than PHP and which tended to bog down development?

ASP.NET takes the desktop, event-driven model of development to the web, which in my opinion brings a lot of unneeded complexity. The best example of this is DLL-centered deployment. Any code behind that is added or changed (all code apart from presentation, including data access and business logic) requires an entirely new DLL to be deployed, even if only one file was changed. The DLL contains the code behind for the entire site, so it's a challenge to develop individual modules without running the risk of impacting the rest of the site.

With the caveat that the best developers on any platform can accomplish great things, our team has already been blown away with the simple, elegant approach of our new direction.

Comments

[Ryan]

Brian, thanks for answering my question here.

I have had trouble finding definitive info for certain aspects of ASP.NET, especially regarding compiling.

From what I understand, you don't HAVE to compile your code-behind into dll files. I was under the impression if you deploy your .aspx and its corresponding .cs files, they will be compiled at run time. And that doing so would incur a slight performance hit over pre-compiling, but nothing serious.

For us, this will be a non-issue, at least at present, as I do all the web dev work for our ministry myself, and therefore would use script blocs instead of code-behind files.

I will keep a close eye on this discussion and look forward to other peoples' comments and further information from you, Brian.

Thank you for putting all this information and discussion about your switch out there for us. It is difficult to find good, balanced discussion on PHP vs. ASP.NET.

[Dave]

ASP.NET... our biggest problem right now is creating modal search popups. You simply cannot do it! Not if you intend to have a pagin mechanism. At that point the postbacks get in the way.

We wanted a modal window because we want to trigger an event on the opener when the popup closes. We accomplished this, and as soon as a postback occurred, a NEW window opens - completely unattached!

We've gone back to a strategy of creating a PostBack event in the caller and raising it, but instead of being modal that damn popup has to be disconnected.

This is just one thing. We've already put in about 230 hours on a webapp - one that I could have written alone in 160 in ASP/COM, but the new company policy states this is "old" technology. Right and left, I'm finidng LAMP is a much easier way to go anymore.

[Brian Glass]

Thanks for answering my question here.

The team structure you describe is pretty much the direction our team is currently headed and it is good to know that
larger, more experienced teams are structuring in similar ways.

I might also suggest checking out Bricolage. It's Perl based and seems to be one of the most sophisticated CMS packages out there. It's not the easiest to install but has fairly sophisticated workflow management and such. It's the CMS Macworld uses to manage its entire site.

I decided not to use it when I chose Mambo because we were using a hosting service and Bricolage requires root access and its own dedicated Apache server, but it would have been my first choice.

[Richard Tallent]

Don't throw out the .NET baby with the ASP.NET bathwater!

I've been doing full-time ASP.NET development since beta2, and have YET to design a SINGLE page that either (a) used postback/viewstate forms or controls or (b) required any sort of codebehind with
compilation.

All of my development is done in UltraEdit and TextPad, source control is done with SourceGear Vault, and my code generally validates to XHTML Transitional, makes heavy use/reuse of CSS, and looks as good if not better in Firefox than in IE.

Once you get outside the training wheels of VS.NET and the default system.web.controls, the power of the .NET languages and foundation classes trumps anything else out there IMHO.

Microsoft made a HUGE mistake trying to promote the higher-levels of the ASP.NET platform by abstracting it to look like WinForms development. The abstraction is terribly leaky, and I don't blame you for dropping it like a bad habit.

However, by leveraging raw, uncompiled ASPX/ASCX with just a few DLLs here and there for global functions, I think you would find your development an order of magnitude easier without having to re-tool completely. This requires that your team actually have a good working knowledge of HTML, CSS, JavaScript, etc., but that should have been a requirement all along.

Another plus: you won't need the VS.NET licenses for this sort of ASP.NET development. You may even find Mono and Apache to be a good substitute for IIS.

[Ryan]

Interesting, Richard.

I am curious - without the apparent convenience provided by web controls, viewstate and postback, what advantages does ASP.NET hold over PHP?

At that point is it merely the presence of the class library?

[Richard Tallent]

Good questions, Ryan...

The OOTB experience of the class library is excellent--with no external modules or configuration, you get pretty much everything you need for web applications: database tools, web scraping, a variety of collections, security, fast string processing, dynamic image creation, full control over the HTTP request/response pipeline, etc. Too many classes to mention, and nothing to dismiss out of hand.

But as a programmer, I am also a fan of the languages. VB.NET and C# have OOP features that I would have killed for years ago when I was using Perl, and later ASP, and the next version will add more (generics and operator overloading in VB.NET come to mind). And since .NET is language-agnostic, there are other choices for syntax and features if I don't like the C# or VB.NET world.

The programming world is divided into two camps: developers and scripters. The former spends all of their time trying to force-fit the world into neat object patterns that are infinitely reusable but ultimately unwieldy. The latter jumps ahead in immediate productivity, but their world eventually becomes an endless cycle of maintaining inconsistent, ad-hoc code.

I've been in both places, now I believe that the secret of good web application development is finding the middle ground between scripting and OOP.

ASPX pages (comparable to PHP pages when you use embedded code rather than code-behinds) and ASCX user controls (like custom controls, but no DLLs and with the same context-switching between HTML and code like ASPX) give me the ability to "wire up" the code using VB.NET/C# as scripting languages, so I have full control over the server response, and deployed changes happen in real-time without disturbing online users. Once you throw away the leaky Webforms abstraction and the senseless code-behind feature, ASPX/ASCX is no less powerful than PHP/Perl/etc., and the FCL is enough for most needs.

However, as a programmer who spent years of college being brainwashed into the doctrine of OOP. So, I do mix my scripting with a good dose of custom .NET assemblies (DLLs) that handle the repetitive "dirty work" of ORM, common UI functions, database query abstraction, form input, security, etc. I share these among all of my projects, they rarely change, and when they do, I get immediate benefit of new functionality or bug fix in all of my apps simultaneously--no copy/paste required.

I don't think ASP.NET is the only way to implement this philosophy. I've heard good things about Ruby on Rails, for instance, and JSP as well, and I'm sure PHP has modular/OOP capabilities that could be leveraged with good planning. For me, however, ASP.NET offers the best combination of language independence, scripting power, built-in classes/features, and powerful OOP language features that are there when they are needed.

[Nick Turrietta]

I'm so proud of you guys for moving to PHP. See then you guys can abstract the CMS and give it to other churches... like we're in the process of doing.

We've got a couple years head start though, but I'm sure you guys'll catch up.

Oh yeah, and if you want some ideas. This list of church CMS's might help a bit.
http://www.greatchurchwebsites.org/content_management.php

Blessings.