Mark Johnson wrote: > Tony: > What's the fastest path for someone who's been providing > the CSV's for the last 10 years and wants to deliver > something more complete. I don't want to spend a lot of > my client's money on packages.
When I originally offered the NebulAnalysis package it was only about $600 per server, which would satisfy the needs of an entire office. As it is today your time=money cost is going to be a lot higher than that no matter what DIY solution you choose. I only mention this because in retrospect it seems everyone assumes a package is going to cost a fortune so they don't even bother to ask about price. But onward we go... The fastest path for someone who doesn't know how to code with Excel, IMO, is to create a nice looking Excel document, then Save-As XML. That XML is now a document template. Break it up into header, detail, and footer sections, and replace any data with unique text like place marker. In BASIC, read the header and use it as a base for a new document. Loop on the detail template, populating it with live data and adding it to the XML stream. When done, add the the footer and write the doc. You can kick off a process to open Excel, read the XML, then Save-As an Excel XLS file. This final file is what your users would use. If I were to write a new one-off Excel integration routine, I might take that approach because it's easy for almost anyone to admininster and extend. It allows end-users or a qualified IT person to create a nice Excel document in a comfortable WYSIWYG manner. The MV side is just filling in the blanks without any understanding that it's creating an XML or Excel document. In fact this is good OOP, Model-View-Controller (MVC) form, separating the UI from the rules, and the output could just as well be a web page, Web Service, or any other medium. For someone who does know how to code with VB, VBA, or a .NET language, the best approach (maybe fastest too, depending...) would be to write an Excel add-in for templates created by users like this, to extract data directly from databases and/or run programs to generate such data. The sheets would be populated without reformatting into XML or writing BASIC code to do string manipulation. This is the approach I personally would take for a real project or a new product. (Inquiries welcome of course.) The new Office 12 will allow us much better access into the internals of Excel and other apps, so the above methods are good and stable for the foreseeable future. So those are the fastest solutions depending on one's experience. The right solutions involve learning the tools of the trade and keeping up with technology rather than to try to get away with doing as little as possible and using 10 year old methods to satisfy the needs of modern end-users. The more end-users see Pick people using ancient methods, the less faith they have in our abilities. Their new solution will be to go pay someone premium buck to do things right rather than waiting for their MV guys to do it on the cheap. As proof of this, I have a client right now who (no kidding) has a $300K budget to make major changes to their MV app, but if they can't get that done they have a $1Millon budget to re-write using MS technologies. Personally I think we Pickies should be doing things the right way, and charge fair market value in the first place. In the end, everyone wins. > The assumption is that the users are using Excel. I've > taken some other advice on this forum to generate HTML > which has had some success but is limited in ease of > adding fields or making changes. Perhaps this is my > opportunity to get into XML. > > Thanks > Mark Johnson XML does afford some more versatility than HTML. Check it out and make your own decisions from there. HTH TG@ removethisNebula-RnD.com ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
