About twenty years ago now, I wrote my first "C" program on Midland College's PDP-11/44. It was, of course, "Hello World" from the K&R Book. And now, 20 years later, I'm still writing "Hello World." Don Box must be right: There is but one program and it is still being written.
declare @greetings xml'
set @greetings = '<greetings><greeting language=''en''>Hello World.</greeting><greeting language=''es''>Hola Mundo.</greeting></greetings>'
select @greetings::value('/greetings/greeting[@language="en"]','nvarchar(max)')
Google Zeigeist that is.
I'm fascinated: Why is wallpaper such a popular search in Japan?
Here at HDR (http://www.hdrinc.com), we're looking at various commercial Content Management products for our public web site. Our preferences at slanted towards:
- Keeping the purchase cost as minimal as possible
- The system must make templates and content easy to generate
- Good built in search
- Must be possible (and preferably not neurosurgery) to integrate custom applications into the presentation layer
I've been spending time today setting up Content Management Server 2002 in a test environment (gotta love that Universal Subscription and Virtual PC.) So far, I'm more a bit more than luke warm to the product. My first concern though is writing ASP.NET application that integrate with it. I hoping that one or more of my faithful readers can address that concern. I think its relatively likely that we'll write our data access and business logic layers as Web Services and just use ASP.NET and CMS to just integrate with the presentation layer.
- Is this good idea?
- What will be easy?
- What will be hard?
- What traps should I be wary of?
- Is there a better product choice?
One bad feeling I have early in is that CMS2k2 feels overly powerful and complex for our simple needs. Its not that mind having that all its features as options, but I concerned that they will making doing simple things harder than they really need to be.
I'm intentionally selecting ASMX. At least some part of this knowledge may only exist behind some DMZ and other firewalls. Please don't flog me for thinking DNA over SOA. Yes, I grok SOA (thanks to Mr. Rieck), but in this case, we're introducing both .NET and Web Services to folks that have been hooked on writing COM+ services for the last few years. Baby steps first.
I'm also planning to look at Windows SharePoint Services as a option, but I doubt its going to pass muster. SharePoint Portal is way more than we need. The "nukes" need not apply since we want a commercially supported product with brains we can rent to help deploy and support as needed.
Thoughts? Recommendations? Warnings?
Being philosophical on four hours of sleep... let's see how this goes.
- Why is there only one National Doughnut Day? Every Friday should be
share a doughnut-with-somebody-you-didn't-know-before-day.
- Having a team from Florida competing for the Stanley Cup feels like
having a Nebraska in the World Surfing Championships. It sounds so wrong.
- Speaking of the Cup (and by "the Cup" I mean Lord Stanley's Cup, since
its the only cup that matters in my little world), if you ever want to
define the idea of a championship having been won by an underdog, you'll
have your chance if the flames pull it off. They will have beaten the best
team in the Eastern conference plus the best, second best and forth best
teams in the Western Conference.
- Is the idea of an API that represents data in a tabular form with a
connected provider dying? I'm talking about APIs like those build up from
concepts like IDbProvider and IDataSet. William Vaughn got me started
thinking about this with a non-question he posed at TechEd. My first
reaction to what he said was different than what he meant. Now I understand
that he wants Microsoft direct their data access investments more into
fixing the deficiencies he see in ADO.NET and less into technologies that
aren't as mainstream like ObjectSpaces and perhaps Web access methods like
SOAP. But I think the investment in in-process XQuery is telling. If
you stop to consider that a Mort like me will be able to easily write a
single query and expose that as a WebService, the need for a simplified Data
Access API partially goes away. What a "killer" XQuery implementation really
needs next are insert, update and delete semantics beyond the child node
level. Give it that while making it simple to expose XQueries as Web
Services and you've got a little reason, IMHO, to use a Connected Provider
style API.
- That said, XQuery still feels very young. I know that its been very well
considered, thought-out and specified by the Einsteins. That doesn't worry
me. What worries me about it is what happens when Morts-Like-Me start making
heavy applied use of it. What changes -- for better or worse -- will we
inflict on it to make our lives easier? My concern here is stemming from how
I see Microsoft evolving other things, like VB'05 and the data types in
Yukon to fit the needs of the vocal few instead -- perhaps -- of the laconic
many.
Update: No, I'm not making the "National Doughnut Day" thing up, but it appears that I am a couple of days off. More details from Hoover's