Archives
-
JavaScript Oddity in FireFox
I have a web page that opens another popup page, and now I needed to also have it automatically redirect back to a previous page after it opened the popup. I thought this would be very easy to do, and it was in IE, but it turned out to not be so easy in FireFox.
This is what I thought would work -- it does in IE, and each of the individual lines works on their own in FireFox, but together in FireFox you don't get a popup:
window.open('NewPage.aspx');
document.location = 'PreviousPage.aspx'; // window.location doesn't help, neither does location.href
The following is what turns out to work in both IE and FireFox -- I hope this trivial piece of JavaScript helps someone out there since it took me a few minutes:
window.open('NewPage.aspx');
location.replace('PreviousPage.aspx');
-
Yang Cao started a Blog Finally
Yang Cao has finally started a blog -- he's one of the best .NET and C++ developers I know -- and he taught me quite a bit when I had the pleasure of working with him for 2 1/2 years. I remember trying to get Yang to give us a presentation on threading for a good while and he finally did -- I have never ever seen anyone else create such a complex app (multi-threaded socket server) without using little steps along the way to try to compile and fix mistakes -- no Yang just wrote it all and it compiled and worked the first time! Jerry Dennany was another of our colleagues back then that has taught me a few things -- not to mentioned saved my hide a few times.
-
VS 2005 CTP and SQL 2005 Beta Together
I swear I've seen it mentioned several times that you can run the December CTP of VS 2005 and Beta 2 of SQL 2005 together on the same machine. Can anyone tell me if it is possible, and if so where I can find the correct procedure to do so?
-
Atlanta Code Camp - Register Now
Registration for the Atlanta Code Camp, to be held on May 14 at the MS Alpharetta offices, is now open -- but limited to 200. I'm thinking of presenting something, possibly on O/R Mapping or UI Mapping, but no commitments have been made yet.
-
When Do You Recommend DNN and When Do You NOT
My client is looking at expanding into a new venture soon and I've been asked what I thought about using DNN (DotNetNuke). The rationale for this request as I understand it is that DNN can get us up and running really fast, we can build on it easily, and its proven to work, perform, and be scalable. Now I'll be the first to admit that while I have looked at DNN, I've also not actually used it in a long time, so I may be biased or ignorant. But I honestly don't see DNN getting a site up any faster than anything else unless that site consists of the canned modules or other existing modules. That may be the case for a lot of "portals" and "community" sites out there, in which case I'd recommend DNN (or Rainbow) myself, but is it really helpful in other cases? I already have MasterPages for site consistency, I already have a lot of the "content" and business-specific knowledge that my client depends on, and I already have a working role-based security and menu implementation. We'll also need to create lots of new "content" or "modules", but I don't see how DNN will simplify or speed that up -- it just seems to add constraints that aren't necessary to me -- unless of course we were creating a "portal" that DNN met most of the needs for already. I also seriously question the notion that DNN is proven -- so hopefully I can get some feedback on this one here -- no matter what the outcome. I've searched, and while I see lots of sites running DNN, I can't seem to find any hard numbers or case-studies about sites that run across multiple servers and support a very large number of concurrent users. My personal experience is that DNN is very functional if it has what you need, but the sites I've seen are typically not very "pretty", and the few larger ones I've seen seemed to really suck when it came to performance (I know of one such large community site that switched to a different CMS since they found their site basically unusable on DNN when the site kept growing). Maybe my personal experience is very limited, and maybe my googling isn't very good -- but I can't find any huge success stories (sure they are numerous small-to-medium successes) while I can easily find some people with complaints and other issues. I'm also a little concerned about the fact that I won't get to control my own schema completely, nor use things like MasterPages (and CSS seems hard too with DNN from what I've read), and I don't like having to give the aspnet user account full control over the website directories either. But I know there are a lot of people out there with real DNN experience -- so please post or email me your thoughts, both positive and negative, keeping in mind that my client is not really going to be able to use the existing modules out there for the most part (if any at all), so this is going to be a custom application -- its just a question of using DNN as a quick and proven starting point.
-
Getting Ready for my UI Mapper Release
As my readers know, I've been working on something I've called a "UI Mapper" for a little while now. Well I'm hoping to finally release something soon and I was wanting to get some opinions on how to actually do that. The "issue" is that there are several pieces to this "product", some of which I want to make an open-source standard, but some of which I would still like to make a little bit of money on ($50).
First there is the central UIMapper "framework" which totally makes sense to be open-source so that anyone can target it as a standard. This piece defines and parses the actual xml UI Mappings and contains the interfaces that must be implemented for the actual UI functionality. For instance, there is an IORMapper interface so that theoretically you can use any ORMapper, or even your own "old-fashioned" DAL for that matter. There is also an optional IResources interface so that you can localize all text using any approach you prefer. Then there are IListView, IEditView, and IEditWidget interfaces that the actual UI controls should implement if they want to be "standard" and somewhat interchangeable, at least as far as the basics go of course. My idea here is that you should be able to "map" your UI and later change the actual UI controls between those available by myself and other vendors. I hope you realize at this point that I'm trying to avoid vendor "lock-in" since you can swap any of the parts, using my ORMapper and UI controls today, and some other ORMapper/DAL and/or set of UI controls tomorrow. So this part I feel very comfortable making open source -- but I have a few questions even about this part -- should I name this part something different than "WilsonUIMapper" to make it feel more open, and does using ProjectDistributor for this make sense?
Then there are the actual UI "controls" that I have made, but which should in no way be required since I hope and encourage others to also make UI controls that target my "UI Mapper" framework. These are what I want to somehow try to sale for $50 since they represent some significant work -- but I still have several options so I still need some feedback. What I have are both Web and Windows versions of ListView (think grid) and EditView (think details) UI controls. The ListView controls allow you to specify which properties, and in which order, are columns in the list, as well as letting you specify header labels (localizable), width, alignment, format, and sortable. The built-in functionality is full support for selecting a row and paging and sorting, and filtering if you add the UI you want, as well as "links" for CRUD with optional deleting from the ListView with a confirmation dialog. A lot of people will say this isn't that different from the standard grids, and that's somewhat true, but the benefit here is that you can easily layout multiple "views" on the same data, either for more flexibility or for different languages or for different "roles", and you can even make it all user-definable if you save their preferences in your database. I also think the automatic support for paging and sorting, and deleting if you like it, is pretty slick, since the built-in grids use huge bloated datasets to "simulate" paging and sorting. So what are my options here, before I describe my EditView controls -- I can release the real executables for these ListView controls and keep the source for sale, or maybe release just one of the Web or Windows versions, or release just demos like I do now for my ORMapper. Maybe I even release the source for both of these and rely on only selling the EditView controls -- what do you think is a reasonable compromise to get people interested in "UI Mapping" while still making a little bit of money?
Finally there are my EditView and EditWidget controls, all of which come in both Web and Windows versions. The EditView controls create the overall "details" view of a single entity, existing or new, in either an editable or read-only manner. But note that the EditView controls do NOT actually "handle" the individual fields -- instead it creates an EditWidget for each field, and you can specify any EditWidget you want that implements my IEditWidget interface. I have 10 EditWidgets right now (maybe I'll have a couple more before release) that use the standard .NET controls, but you could very easily create (or get one from somewhere else maybe) versions that support your favorite 3rd party controls or your own business-specific needs. The types of things I have are "widgets" that represent single-line text, multi-line memos, read-only fields, boolean check-boxes, integer fields, number fields, date fields, single-select combo-boxes, multi-select list-boxes, and double-entry passwords. My integer and number boxes use just the standard text-boxes in Web and Windows flavors, with the appropriate validation, but you could easily create your own version using Infragistics or something else and plug them in with just a single configuration line in the mapping file. You may also want to create a more complex business-specific control, like an Address control or a custom Person Selection control -- that should also be easily doable. I think the EditView and the EditWidgets are where its more obvious how this can be a significantly "better" way to do things, at least for most of your basic "admin" screens anyhow. No longer do you have to carefully lineup 100 controls on a 100 different screens -- nor change them all when the designers want something slightly different. No longer will you have inconsistencies in your UI because integers or dates were handled one way on some screens and another way on another. No longer do you have to create separate versions for the Web and Windows, or different languages/locales -- you could even create another version of controls for cell phones if you wanted. So this I'm thinking I would only release in demo form, but I'm certainly still willing to hear your opinions as long as you keep in mind that I'm NOT going to just open-source everything.
So what do you think I should do -- and why? And what do you think of what I've laid out here -- any concerns or things you see missing that simply must be included from the beginning. Again my vision is to release the "framework" as open source so that others can also build on this, although my hope is that people will buy something from me to help compensate for my time. I also think there's a lot of value in a community of paid users from what I've seen with my ORMapper -- that may sound weird but its been very true. I get tons of feedback and suggestions and even bug-fixes and new features from my paid ORMapper users -- but I get nothing from my open-source things, unless you count tons of newbie questions that paying users seem to avoid for the most part. So please give me your thoughts now while I still have some choices remaining -- and thanks.