July 2004 - Posts
I finally decided to take the plunge and build something with DotNetNuke and threw it away in frustration. Theres a ton of documentation, but it doesnt tell you how to do simple things. And for an ASP.NET newbie, its all a bit too much actually.
Let me explain. All I need is 3 panes. A top horizontal menu, preferably a slim one, one left pane and one content pane. The root tabs need to appear horizontally and for whichever one is active, the left pane should show one level of subtabs. Clicking each option in the left subtab should then change the contents of the right hand side container pane. Is that soo difficult to do ?
I couldnt find a single skin in any of the free skins or even the for-sale skins in DNN that showed this. Cant blame the skin creators. There were some rather nifty ones on display but for my requirements they were pretty much useless. Its beginning to look like no one at all uses simple website structures anymore. Or perhaps the structuring requirement goes beyond anything to do with skins in DNN.
But I can do this easily in Rainbow (using the SubTabsVert theme).
Anyway, thats bye-bye DNN for me.
Maybe one day when i need a radical looking site with DHTML menu's all over the place i will look at it again. In the meanwhile, theres a Rainbow in the sky!!
The book I've currently started to read is SOA - A Field Guide by Thomas Erl. I picked it up at TechEd. It looks really good. I will also look at opportunities to make use of it in my current project.
According to the blurb, its a vendor neutral field guide and goes on to say "This guide consists of a collection of strategies and best practices, and is intended to act as a reference guide, providing advice for a variety of common integration scenarios".
Some other good links on this kind of stuff, that I just came across are
Apparently the XMLTC site will also be publishing some information in Q4 2004 about the XWIF - Xml & Web Services Integration Framework.
I'm sorely tempted to start up a proper website to put all these links and information on. The blog does seem a bit restrictive actually. Anyway, feel free post other similiar links in the feedback section. The more info, the better.
Very Important: Simon Horrell of DevelopMentor has written a detailed article on Web Service Messaging with WSE2.0 on the MSDN site. Go there and check it out right away. Since I attended the Guerilla Web Services course in London last year, I can attest to the fact that Simon is an excellent teacher.
You know what? I have this strange feeling of deja-vu. Around 18 months ago when i started getting more into XML Schemas and stuff like that, i found that there are problems when you try to load in Xml docs where an element name is duplicated. I found this again when trying to use the Xsd.exe to generate a dataset. [I guess, it isn't deja-vu in that case, merely history repeating itself)
Xsd.exe works fine when generating classes, but not with datasets. I have an element named ADDRESS appearing more than once for things like residence address, office address and all that and XSD.exe didnt like it!!
So is this normal? Should I be going in and changing the element names all over the place? Perhaps we should be designing XSD's where the type name only appears once but the element names are different.
Anyway, I shall try out Irwins suggestion and look at SQLXML again. Maybe I can come up with some graphical tool for generating some of this stuff. It should help.
By the way does anyone know a good explanation why DataSets dont support recursive types? Sometime ago I was working with a nice XML schema which had nested types named PRODUCT. Wanted to persist that into a DB using datasets, but couldnt do it. Wonder if its anything to do with nested tables resulting from such a design.
Goodness, I've had a couple of really frustrating days trying to get my head round a knotty problem. We have this XSD with about 30 odd complex types and the data source is a DB with dozens of tables. The XSD is more or less a subset of the data. I was looking for the fastest way to code a component that generates XML files from the DB.
Tried looking at SQL FOR-XML EXPLICIT but gave that up as too complicated. Then started to look at coding classes to represent the complex types and manually write the SQL. Went someway down the road and was then advised against it as the XSD is volatile right now and I would need to regenerate the entire set again. By the way, I used XSD.exe (which I only discovered recently) to do the class generation.
So this evening I started coding up the SQL but in a separate external class, so i neednt worry about overwriting my stuff. In any case, the classes in this component are just data containers. So this may not be a 'encapsulated'/composite approach where I call a Load on the root which calls its children and so on, but it works.
A couple of hours ago I was going through the TDD in .NET book (James Newkirk et al) and in the chapter on testing ADO.NET, there was something on quickly generating datasets.
The approaches are
(a) using the DataSet wizard to generate a DataSet class by dragging and dropping db tables on to the design surface (if i remember the material correctly). I think that if the wizard generates the dataset filling code for me, then it might be easy to serialise that and apply an XSL transform to get the schema i want.
(b) Using XSD.exe to generate the Dataset. The problem I envisage here is that i still have to write all that code to fill the dataset and then i still have to serialise it and it wont match the schema I need (or will it?).
Gotta have a look and see. Will post the results here. Does anyone know of any tools that can simplify this process? I'm sure that this is one of the most common problems in data access.
Now I've decided to hold the knowledge sharing sesion at my office this week, so i'm hard at work trying to type up all my session notes.
The sad thing is, i took my laptop there and then found that for one thing, the power supply outlets supported non UK type plugs and worse, even if I had the right plugs, the sessions were just too long for me to charge the machine unless I went and sat next to some power supplies all the time. Havent the foggiest idea how other people managed with their laptops. So poor ol me just has to type the damn things all over again.
Well, at least this will work as a refresher before the session. Another sore point is that I dont have all the slides. I did download all that were available the day before the trip but then a lot of them got posted during the conference and I couldnt download them on to my laptop for the aforementioned reasons. Guess i'll just have to do the best I can and try and hunt down screen shots of Whidbey and other things from the MSDN site.
I just came across an interesting article on the NewArchitect website dealing with the issue of scaling XP approaches for large projects. I had this opinion that opting for an agile approach was merely a cop-out from writing documentation and then read the Agile Manifesto where one of the key points is that while documentation is fine, living code is considered more important.
Methodologies should never become millstones round a developers neck. But heads down coding without anything to prepare the customer for and and without anything to train new developers on the team with is, IMO, ridiculous. [Again, the manifesto does recommend Interaction with the customer as highly important. The thing is , I've been involved with many customers who need to see up-front a lot of what we are going to deliver, and will not even sign-off on the project until this has been agreed upon. Usually this involves Architecture and Design documents not just working code. They have sent representatives to work with us on the projects, but they have placed a lot of emphasis in the stages of Inception and Elaboration (to use RUP terminology) (not that we use RUP at my workplace anyway. We have traditionally used a (still evolving) methodology which borrows a lot from RAD and DSDM]
Lets consider the other developers who get involved in the project at some stage (some early on and some maybe later, for various reasons) Its all well and good to give them an object model and a set of tests, but thats not all you should give them. How are they supposed to know what patterns you have adopted and how they fit together for the various components in the whole solution? For example, what good is it to just tell someone you used MVC or the UIP app block for your site? Sure, it communicates a certain amount, which is why patterns are so useful as a communication enabler (among other things), but thats not enough.
Now before any XP proponents out there decide to blast me, note that I'm NOT dismissing it off hand entirely. In fact, I'm going to be involved in an XP style project very shortly (which is why I'm keen to get more out of it than just pretty code) . And I DO NOT propose writing a million pages of documentation for every project. In a situation where requirements are fluid, big design up front can be counter-productive. But launching into coding without even setting the scene with some (at least a minimum amount of) proper documentation is, still, in my book, a cop-out.
Martin Fowler, in his article on Agile Handover has some good points and cites an example where the customer interacts with the dev team and drives the documentation so that what is produced is really relevant and useful. I say how about doing that earlier in the project and refining it at the end?
With this in mind, i favor Juval Lowy's more structured approach. The methods he suggested at the .NET Architecture Clinic (at Tech Ed Europe 2004), based on the IDesign Method were really cool. I dont think that asking an architect to write this kind of Architecture Report up-front is too much. I think its essential to better understanding of the project especially if its a big one. What happens if he/she goes under a bus and has carried all the info in their head?
I wonder if MSF and other groups in MS have any guidance or suggestions on architectural approaches in agile-method projects. I just sent a mail to Harry Pierson, the Architecture lead on MSDN, asking him the same. Lets see what they come back with.
Here's an interesting reply from Tom Hollander (from the P&P team) in response to a post on the apparent futures of Shadowfax and the App Blocks by a Tech-Ed blogger. Its good to know that MS is pushing hard to streamline the blocks and make them into a library and that ShadowFax will also be contributing towards the collection.
I still havent got round to conducting the TechEd knowledge sharing session at my office. Tom's points will help in the preparation/collection of information. I'm trying to organise a set of key takeaways from each of the tracks in the form of Principles and Tools (ie) What are the key things to think about /watch out for, what tools are/will be provided to help in that area. This would be a good summary sheet for my colleagues.
By the way has anyone tried the Aggregation / Async blocks in a modified form to work with Remoting instead of WS? I'm going to be working on a generic framework to access a set of remote components for some functionality we currently require and I was looking at the Request Aggregator, Transformation Manager and the Thread Pool for Service Agents and thinking that they could be made to work with Remoting too. If anyone has tried this, I'd value a heads-up. If not, I'll post my progress here.
Been meaning to blog about this for a long time now. Quite a while ago I came across this article on getting into ASP.NET. I'm sure a lot of people loved it. The average rating is 7 out of 9. Unfortunately for me, it wasnt what I was looking for. The application was a rather simple data-centric one and I happened to be looking for a good methodology on how to design a ASP.NET app from the ground up in a more OO manner (ie) once you get the object model done, how do you then map that to screens, navigation flow and all that. (The data tier is usually a breeze especially if you use OR-Mapping, but more about that later) and I was rather disappointed that it started out well with basic considerations and then jumped straight into designing the database.
I know there are times when data-centric will suffice and having started out as a DB person in my career, I will not criticise DB oriented apps right away, but it just doesnt seem right in this case. Im quite sold on OO and SOA now (but I do not consider DB's any less important) as the way you need to design business apps.
There are plenty of small sites with 2 page tutorials on how to design a product catalog DB and stick ASPX pages on top of that. I was hoping that there would be more from MS (especially in an article on MSDN) in the area I'm looking at. I know MS is moving away from UML, but a solid structured approach irrespective of notation would have been good (or is that not possible without resorting to UML at this point in time?)
Still, I guess the author had a certain aim while writing his article and it said what it was supposed to. As for me, I'll keep looking for a nice structured approach to designing ASPX web apps. (Probably all this info is scattered around in various white papers on MS and other sites).
Happy architecting /coding /hacking :-) !!
Life is getting interesting. I'm now involved with building some components as part of a fairly decent sized architecture framework for a project. I may even have to do some of the front end bits as there arent any front end gurus available at the moment.
Now in my mind, there are two elements to ASP.NET or any web building for that matter. Theres the componentry - the controls, structure etc and then theres the layout. IMHO,Classy GUI's need a very different skill set to your average web site developer. I cant think curved borders. All sites have 'square' themes in my head!! Thats what comes from working with VB6 forms and DB Tables for as long as i can remember! This is probably why I like Portal software and dont like creating themes and skins for them!
I'm leaning towards the UIP-Application Block type of approach where I will probably focus a lot on the Model and Controller and may just slap on some 'functional' views and then get some 'professional' assistance in crafting a better GUI. If the promise of the MVC model holds good, then this should work just fine. There no huge complex navigational requirements for the system I'm building anyway.
Wonder what the ASP.NET gurus out there will think about this? Any ideas/gotchas on this approach? Comments are welcome.
So, I'm finally getting started on re-building my church website. We are going to be using Rainbow Portal for it. Spent a long time trying to choose between Rainbow and DotNetNuke. Actually my evaluation was a bit biased initially since when I first started the comparison, DNN was in v 1.0 and was quite poor compared to Rainbow. DNN v2.0 has been a complete rewrite and does look more like a contender but unfortunately, I cannot get it to look the way I want to without writing an entire skin myself. I am not a hardcore ASP.NET developer and I cannot do this!!
The requirements are quite simple. A horizontal menu on the top which when clicked gives me more options on the left - no dropdowns please, thus working like a different front page. In Rainbow I can do this with subtabs, but in DNN i cannot do this out of the box.
I must admit the skinning seems better in DNN. In Rainbow the stuff is all over the place. I nearly tore my hair out trying to use a new skin based on the default Orange theme and found that the developer had simply ignored the main CSS and forced colors into table rows and columns quite arbitrarily. I guess its not the fault of the portal if the developer chooses to ignore basic rules, but in DNN, the skins are done completely separate from the module code so its easier to enforce standards. Rainbow v2 promises to have a new skinning engine and they have a good team already so Im quite sure V2 will have a lot to offer. Besides DNN out of the box has only a few modules and has built up a commercial ecosystem around itself. I havent come across commercial portlet providers for Rainbow but there must be some out there. Not that I'm going to buy any right now. Rainbow has more than 45 default portlets.
I wonder if these portal servers will soon become WSRP compliant? Or is that too much to ask from open source systems? Maybe eventually I will have a site with a rich set of custom portlets that can easily be configured to fit in either a Rainbow or DNN portal server. All for free of course. Was even planning to rewrite the Reports Starter Kit into the Portal Starter Kit framework. For all this though I need more than 24 hours in a day. Its just not happening now.
Anyway, I might still play around with a DNN version of the site and see what happens. Perhaps I would be inspired enough to create a good skin for it myself. I'll keep you posted.
Just came across the blogs of Aravindra Sehmi and Clemens Vaasters. They are doing a great followup job of explaining the positioning of ShadowFax, Proseware and Fabriq and some more details. Clemens also pointed out a link to Benjamin Mitchell's blog where he had explained some more on the Proseware talk that Clemens gave. Its a really, really good summation of the session.
Now let us share the great love that MS has for all developers and architects (except the Java guys!!).
:-). Just kidding.
I'm going to have to start preparing for a knowledge sharing session at my company in return for them sponsoring my trip to TechEd. Not a bad bargain eh? In any case, I'm all for these kind of sessions and was an ardent proponent of the various tech forums we used to have internally, in the good ol days when there were sufficient numbers of us to ensure attendance! Nowadays there are a very few people left and the percentage of folk who would participate in such sessions is even less. Got to coordinate with the chap who came along and attended other sessions so we can give one comprehensive talk. I'm sure that Whitehorse will make an impact on then. Havent had time to download ShadowFax and Fabriq yet, but let me see if I can get round to it before the session which I've planned for sometime next week.
Oh and one more thing. I picked up the whitepaper that Juval talked about in the Architecture Clinic. Its called the IDesign Method. I also mailed him and obtained the Sample Architecture Report which is a fascinating document. One thing he mentioned was that he was involved closely with the VS2005 Team System and perhaps in future versions, the system will allow creation of diagrams recommended in his method. But then again, maybe we can extend the tool right now to do the same. Steve Cook mentioned that there is a shallow extensibility available. Need to download it and investigate the possibilities.
Did you like the title? Sound mysterious? Don't worry. Just read on and all will be revealed.
So here I am at home on Sunday evening, thinking back to the events of Friday and the sessions. Here are the details.
SOA and OOAD - Grey Area: This was an absolute thriller! Maarten Mullender and Beat Schwegler did a great job of explaining how to go about understanding the grey area of SOA just at the edge of the services. While the internal implementation can be OO, there are very good reasons to be ultra careful about the edge and the service interface. They demonstrated the kind of namespace issues that arise when you pass around objects and how to influence the WSDL generation by using the right types of attributes on the classes. Beat demonstrated the WSDL first approach to building the system. Of course, it isnt the rule. Designing the classes first and allowing the tool to generate the WSDL works for a lot of systems, but in the interests of interoperability you need to work on the WSDL a little more. Looking at it like that , the WSDL-First approach seems better in some areas. Anyway, I want to blog this issue in more detail so I'll stop with this for now. Suffice to say I had a good long chat with Maarten after the session and in the lunch break (at the Ask the Experts booth) and he said that he was planning to put this up on a whitepaper shortly on MSDN. He also said that there would be one shortly published on Concurrency in WebServices and why CRUD approaches to WS is not a good thing.
BAM, BAM thank you Ma'am: Oh dear, got a little carried away didnt I? Alex Cobb took a heavy duty session on BAM stuff. It was very deep. He spoke a lot about the Progressive Dimension bit and lots of other things. Need to go and find the BTS documentation and go over it again.
The WHITE Horse: Maybe its just me, but I finally saw the light. Steve Cook closed out the conference with a talk on building SO applications and demonstrated aspects of DSL's and the Whidbey Team Architect. I cant for the life of me understand why he didnt show this for at least 5 mins in the keynote. In fact I told him so after the session. I missed all Prashant's talks on the Whidbey system since for one I was focussing more on BTS and secondly because Whidbey aint gonna be out for another year at least (hopefully sooner). Imagine my surprise when i saw the Application Connection Designer and the Logical DataCenter tool.
Just before he got to those specific things I was thinking how nice it would be to have a executable Visio template that built an entire solution structure with projects, bolier plate code, setup projects etc using standard patterns as well as points from Juval Lowy's talk, and lo and behold in the next few minutes he proceeded to demonstrate just that, or at least something quite like it. I'll blog this aspect in more detail later. This was waaay cool and i left the conference feeling really excited.
Now all I need is a spare machine in the office thats big enough to load WHIDBEY and YUKON and i'll be all set to work with a great set of tools. Way to go Microsoft!!
Today had more SOA and BTS stuff
SOA : Attended the Thomson Case Study on SOA implementation. Interesting but really nothing out of the ordinary. Still its a good case study for Smart Clients and a decent reference implementation. Noted that they used INFRAGISTICS for the rich componentry both on the web as well as the smart client. It seemed that they managed to use MVC well enough to plug in a web view over the same Model and Controller. Now how did they manage that? AFAIK , even in the UIPAB2 , the controller is tied to the view so you just cant remove the web page and put a thicker client in its place - and only the MODEL can be considered re-usable. This is what a colleague's experience is, unless of course he did it all wrong which I doubt. Can anyone shed some light?
I also went for the PROSEWARE session in the afternoon. As expected, Clement V did a great job. Highly technical stuff but very well delivered. I hope Microsoft releases the code and documentation. It would be awesome. Learnt a really cool thing about versioning. We need to ensure that we only pass 'types' as parameters into the messages. This helps in versioning because by controlling the serialisation with XmlAnyAttribute and XmlAnyElement, we can add even more elements in future without breaking existing consumers.
One thing which really fascinated me was how he placed all the XSD's into one project and then in the pre-build stage he used the XSD exe to generate the corresponding types in C sharp. I didnt catch the explanation, he was too quick, but i think the reason is as follows: Since we are passing types around, one way would be to create the corresponding classes in the project and compile them all. But this has a problem in that everyime someone makes a change in the XSD, they also need to go and change the corresponding class. Keeping these in sync would be a beast. Instead we can keep the XSD in the project and then generate the code when we need to. Now, the consumers of this class will have to point to a DLL anyway, so the code generated at build time will be available there and they can easily use them.
Isnt this simply amazing!!! (Or have i got it all horribly wrong? Maybe I should post a question on his blog)
There was even more from Clement in the last session of the day when he dealt with Handling State at multiple layers. He used PROSEWARE as example and there were some valuable pointers. That chap should write a book on Architecture. Insights into his approach would be invaluable for budding architects (and wannabes like myself !!) A key takeaway for me was that I need to start looking into Enterprise Services. I've ignored them for far too long.
BTS: Attended the BTS HOL for Orchestration, or rather, i skipped the 10:15 to 11:30 session cos I couldnt locate anything really interesting and did the lab instead. I also went for the Advanced Business Processes in BTS (or as Scott said, Essential Biz Processes). It was top class. He dealt in depth with Correlations, Compositions, Convoys, Direct Binding. He had very little time to demonstrate Transactions and Role Links which was a pity. But it was an amazing session.
One annoying thing I picked up at the end in the Q&A is that HWS is a lean offering now and they would rather we worked with one of their partners if we needed workflow. Appreciate that TeamPlate and K2 etc are offering good products, but this was the kind of thing that put me off when i was forced to use that awful product CMS2002 sometime ago. Keeping important functionality out of a core product just so that partners can make money isnt a good idea IMHO. More power to TeamPlate and K2 though, but i doubt my client will pay extra for that. I have a hard time making the case for BTS right now.
MYTH BUSTING: This was a panel discussion. Not much time now to post all the details. Im sure someone else will blog it anyway. Or i'll do it when I get home at the weekend. Suffice to say that David Chappell, Clement, Juval, Rafael and Michelle are very knowledgeable and funny too.
So thats it from me at Day 3 (day 4 if you take the pre-conference). One more day to go. Probably wont have enough time to post tomorrow evening since I will be rushing off to the airport.