I need to develop an application that will allow a manager to keep track of what equipment is being used, for what purpose, and for how long. This application would allow this division to see current equipment in use and what has been scheduled for the coming week(s), and also assist in forecasting for future work or possible bids.
I really do not have any constraints imposed on me for what development tools I can use, whether its or smart client or thin client mult-tier application (I suppose I could even use MS Access, but am not considering such an option...). Does anyone have any suggestions on not only on what might be the best architecture, such as web-based vs. smart client, but if they are aware of any good resource scheduling components that I could purchase to augment the application? This is a very broad and open-ended question, but any input on this is greatly appreciated.
Thanks!My experience comes from the ASP.NET side. Yet, I used to build Windows apps for a living and feel that they provide a FAR better UI for a business app. The decision to make it HTML or smart client is significant and not one we should make for you. It determines the limitations and choices you will have due to different platforms.
ASP.NET has a rich variety of third party tools. You are asking about scheduling. There are date entry controls (mine isPeter's Date Package) and scheduling tools that provide the UI. These sites offer lists of them: this site's Control Gallery, www.123aspx.com, and www.411asp.net. IMO, www.123aspx.com and www.411asp.net present the category better (more products listed).
But don't stop after finding date and scheduling tools. You are building an application. There are a multitude of elements you will add to your pages or windows. On ASP.NET, think about numeric entry textboxes, validation, data grids, menus, tabs, etc. (MyProfessional Validation And More handles numeric entry textboxes and validation for example.) All of these can be found on the sites I mentioned.
I also recommend posting very specific product category questions in the Component Reviews forum here on www.asp.net.
Thank you very much for the suggestions. I like the tools you have on your site and have made not of them. Although ASP.NET is a huge improvement over previous scripting languages, I am aware of the fact that there is still a bit more technology involved in thin client development than a smart client may require. I first disliked thin client development, but grew to enjoy this type of work, especially when it came to implementing changes.
When I see such rich UI interaction available in tools such as you provide, my pride kicks in and says that surely I can develope an enterprise wide application in ASP.NET (as if Smart Client were a cave in on my part?). There really is only one consideration that I have that would push me in the browser based development direction, which is the fact that my company would like to have an internet/extranet presence. As a result I justify that learning and developing a solid foundation for our internal clients could then be extended to those outside our network. After 10 years of development experience I would think that I would be able to easily decide which development path to take. I believe I am concerned that if I choose the ASP.NET route, I may find myself in no-man's land and regret the decision.
Thank you so very much for your time and I will keep you in mind for future development needs!
Here's another bit of info that will further confuse the issue: The "Longhorn" initiative from Microsoft. It is the next generation Windows platform. Pretty much a rewrite the same way Win95 was to Win 3.1. It uses the .net technology. My understanding is that Windows apps written in .net are "native".
Here is what I gathered about it so far. Consider these interpretations. Read the MSDN site for published statements...
Part of this initiative appears to be the goal to replace the browser for business apps. Smart clients is the way to go. I personally like this idea because I crave tremendous improvements in the client-side toolset that are already there in the Windows side of app development. While the browser won't disappear, Microsoft seems to want to marginalize it to a specific class of uses and my guess is those are really want the browser was originally intended: browsing pages!
0 comments:
Post a Comment