Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 10 of 22 total |
At a development environment crossroad - need feedback |
Thu, Apr 3 2014 10:07 PM | Permanent Link |
Gerald J. Clancy, Jr. | I'm at a watershed moment, a crossroad regarding the issue of development
environments and would love some feedback. Some facts (please pardon the length): * Our main apps are huge legislative reporting "machines." Many, many tens of thousands of lines of code developed over 25 years. All are now Delphi 5 ISAPI apps and almost all functions operate in a similar fashion. The user selects a menu item (function(, which presents him/her with a "parameters" form in which they select bill ranges, date ranges, report options (i.e., include or not bill nos., links to text, sponsors, history, etc.) and report format. The user then clicks the Report button and the server app generates the desired report and sends it back in a new window (popup). Now, we support three report formats: PDF, HTML and MS Word. Initially (like almost 20 years ago) we foolishly, in retrospect, chose Report Printer Pro/RAVE from Nevrona Designs to generate the native mode report which their component converted to a PDF. Another of their components would generate the native code to HTML. Very badly, it turned out, so we ceased using it and instead now generate our own native HTML reports. (Their RTF component was useless from Day 1 and never improved upon.) For Word reports we generated our own native RTF files, which the client's Word program could always open (any version of Word). (We also initially used Apollo for database support until we discovered, one day after their chief scientist did, that they couldn't support more than about 3 or 4 concurrent users -- long story. We switched to DBISAM, our last major rewrite.) So, what has changed? Well, RAVE all but went out of business and didn't offer an update for some 5 years and required conversions to different components which didn't all work properly. Support, such as it was, was total history. As a result, in spite of also owning D2009 and XE2 we could never use them because we were glued to D5 thanks to RAVE. Plus, we already had to rewrite the HTML reports. RAVE is part of a bundle in XE2 and they also have RAVE 11 out. BUT, I no longer trust this company and want out. Then last week it was announced that there was a security update from Microsoft for all versions of Word which, when applied, will nullify all RTF support in Word. In other words, RTF is dead! It is not viable to offer clients an alternate reader when they already have Word. (Many of you may not actually be aware of this.) Now the last piece. We also at the outset decided to generate ISAPI DLLs due to their inherent efficiency on resources and speed. IntraWeb was announced at just about that time and we signed on. Complicated and painful at first, it did settle down but you could only use their components or third-party ones (we use TMS). And it's VERY expensive, as is Delphi with yearly versions and support charges on top. We made the decision to replace both RAVE and our own RTF reports by using Word 2010 Automation, which allows us to programmatically generate native Word reports and, with one command (SaveAs), produce PDF reports. Today we got those packages working in XE2. Then came the next problem: We couldn't generate ISAPIs. Not licesnsed/supported in this version (Professional). Though we used D5 Enterprise, we downgraded to the Professional version for XE2 largely due to the expense (we're a one-man shop) and because we had already purchased IntraWeb. The solution is to rip the bundled IntraWeb components out of XE2 and install our old licensed IntraWeb packages, possibly requiring a very expensive upgrade to support XE2. Finally, throw in the need to accomodate smartphones and tablets. Then it occurred to me: I really want off this train. When Tim first announced Web Builder I was excited. It seemed to offer me what I really wanted, an alternative to Delphi (while keeping the Pascal coding) and IntraWeb. So, my questions to those of you already using Web Builder: 1. Can I use it as a replacement for thses apps? 2. Are its components broad enough and up to the task? We use a small set of components: edit, labels, checkboxes, comboboxes, grids, calendar-pickers, buttons. HTML containers/viewers (e.g., IW's TIWText that will render raw HTML). We don't generally use data-aware components due to their inherent inefficiency, preferring to send the data incrementailly (or range-bound) in non-data-aware grids, etc.). 3. What, if any, third-party components are supported and, most importantly, can I incorporate the Word 2010 automation components now so critical to the generation of .doc and .pdf files? Many of you on this list have been down this road as well. I not only value and respect Tim and his products but also anticipate the longevity of his products. Plus, for me at 75, they don't have to be around all that much longer. :>) The way I look at it I have three alternatives: 1) Stay on the current course, get very expensive upgrades and move all the many third-party packages to XE2; 2) Go with WebBuilder; or 3) Pack it in/call it a day, milk the current apps and then retire. Peharps DataSnap is another alternative to ISAPIs but I've never used it (feedback here would be useful). I also respect so many of you that have spent so many years, as I, developing professional quality applications, so any and all feedback you can provide on these questions would be greatly appreciated. Jerry |
Fri, Apr 4 2014 3:32 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Jerry
I can't help you with your question (downloaded but never used EWB) but >Then last week it was announced that there was a security update from >Microsoft for all versions of Word which, when applied, will nullify all RTF >support in Word. In other words, RTF is dead! It is not viable to offer >clients an alternate reader when they already have Word. (Many of you may >not actually be aware of this.) Do you have a link for this? Roy |
Fri, Apr 4 2014 3:46 AM | Permanent Link |
Matthew Jones | > >support in Word. In other words, RTF is dead! It is not viable to
> offer > >clients an alternate reader when they already have Word. (Many of > you may > >not actually be aware of this.) > > Do you have a link for this? http://nakedsecurity.sophos.com/2014/03/25/microsoft-issues-patch-for-word-zero-day- booby-trapped-rtf-files-already-used-in-attacks/ /Matthew Jones/ |
Fri, Apr 4 2014 4:09 AM | Permanent Link |
Matthew Jones | Jerry,
I think your situation is quite common among Delphi developers. I'm talking to one at the moment, as I've been travelling this path for a while, and for me WebBuilder has worked well. It helps me use my Delphi skills and achieve lots. Whether it is right for others is for them to judge of course. First, I think the most cost effective solution, if you have something that works, is to consider hard if it is better to just pay some more money and stick with your existing solution a while. Depends what you want to do really - if you are wanting to retire soon, and the company closes, then that might be best. If you expect the company to continue after retirement, then that's different, and you would be better off with a more modern solution. I'll answer some questions in the wrong order, if I may. Controls? You get what you are given, but just like Delphi 1, you can be clever. I built a slider control that no one would know wasn't "native". And that's because of course there is no native slider, so any slider is a mix of panels, text and a pointer. WebBuilder has all the events you need to detect mouse down/move/up and make it happen, and you can use a bitmap or panel for your elements. A calendar wouldn't be hard, and a drop down menu is already posted hereabouts. The UI is not the problem IMO, and it will work on all modern devices. Next question has to be about scale. How many users are going to hit your "server" software per second, and for what? On one project I was running a Delphi Windows Service which contained the RemObjects SDK https server. I hit it hard with requests, each of which did a DBISAM database lookup. I could handle 200 requests a second. In the case in point, that wasn't enough, so I worked out a cache mechanism, modified the library code, and was able to handle 1000+ requests/sec. Obviously if there is more work, it would be less. RemObjects also has a way to scale, so you can share session data, but I didn't look into this. But I mention this as a "guide" for consideration. If you are talking 10 people doing a few requests a minute, all done. If you are talking 10,000 people being busy, you need to do your own measurements. And perhaps worth stepping back further - I'm assuming that you are using a Delphi server here as the web server. WebBuilder can talk to any server you like, so you could have it done in C# using ASP.Net, or PHP, or whatever. But if you are generating PDFs etc, then you probably want to stick to Delphi and use those skills. I believe you can use the WebBuilder server, but I've never tried that myself. I will make a blog post about why I use RemObjects SDK, but one advantage is that it gives me all the code for the web server, and I can hack that code to do my own thing. My PDF invoices are stored in some location like c:\data\pdfs\invoices\order-123.pdf but I wanted that hidden. So the web server will take a GUID in the form myserver/pdf/inv-ABCD-EFDE.pdf, and the code translates that to the appropriate file to return. I could, if I wanted, actually generate at that point, so if it was a graph bitmap, I could create it and then cache it. It may be that you can do this as an ISAPI DLL still, or use the WebBuilder server add-ons do to what you need, but I'm not sure. Okay, so I'll mention another benefit of using WebBuilder, and that is that you can easily replace parts if you choose to in future. Business is flying, but WebBuilder isn't cutting the mustard? Hire an Angular2017 JS developer and they can talk to the same interfaces that your WebBuilder code does. Your server isn't changed. Hang on, you are now talking 1000 users, so quick, re-do the server in something else, and your WebBuilder code doesn't change as it supports the same interfaces. Need to support Blueberry that doesn't support Javascript? No problem, you have an interface on the server it can talk to. Need to switch to a new server? No problem, the WebBuilder code can switch from JSON to XML to Data2017 format. Basically, you aren't locked in. If you are a Delphi developer, and want to move to web clients (or PhoneGap) then WebBuilder is a very productive environment for you. The bigger question perhaps arises about what you should use for your server. Me, I have a good and rock solid framework using RemObjects and my own inter-thread communications etc that has worked for years. I personally can take that core, and get a new project going inside a day, and ship it the next day. Making it usable for others is something I must do, but the key will be explaining it as I know it intimately of course. Anyway, the more your code is broken into interfaces, the easier it will be to move to a web server / web client operation. Good luck! /Matthew Jones/ |
Fri, Apr 4 2014 8:53 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew
Thanks for that. I do have a significant problem with the article though -.doc files are in rtf format. Roy Lambert |
Fri, Apr 4 2014 9:11 AM | Permanent Link |
Matthew Jones | > -.doc files are in rtf format.
No, they aren't. RTF may follow the Microsoft internal document format closely, but they are pure text, and a .Doc file is binary. I've just done a quick check, and a ..Doc file I have here starts with hex D0 Cf 11 E0 A1 B1 1A E1 00 00 00 00 00 ... RTF starts with a { brace if I recall correctly. (I did a significant import and export to RTF some years ago, so still shudder at it...) /Matthew Jones/ |
Fri, Apr 4 2014 10:05 AM | Permanent Link |
Raul Team Elevate | On 4/4/2014 8:53 AM, Roy Lambert wrote:
> Thanks for that. I do have a significant problem with the article though -.doc files are in rtf format. Like Matthew said they are not. RTF is an open standard while doc is proprietary and last time we looked into it they're an mess of embedded OLE with containers and other binary data internally. Newer office docx formats are different and are now standardized as well (with some controversy) but technically are xml now. Raul |
Fri, Apr 4 2014 10:31 AM | Permanent Link |
Walter Matte Tactical Business Corporation | Jerry:
1. Can I use it as a replacement for these apps? The simple answer is Yes. But is anything really simple No. You need to view EWB as the tool to build the front end client side. It is perfect for database web application because of Tim's expertise with database's, he has intrinsically built that capability into the EWB framework! I try to keep the front end unencumbered with extra code. It does a certain level of validation, but more detailed data manipulation I leave to the backend server. So a backend server side is needed. You can build/extend the Server that comes with EWB, or use PHP, I even did a small web page with ASP and ODBC to provide data to an EWB site I built, or use RemObjects like Matthew did, or what I do normally is use RealThinClient controls, and built an HTTP server in Delphi, that runs as a service. The advantage of Delphi as the back end to me is that I can completely code logic in Delphi. Leveraging the language and tools available. I have built a Timesheet and Expense Entry portal for an international company with EWB. The backend uses ReportBuilder to generate HTML, PDF, RTF (sad to here what is happening) or XLS files that get sent back to the Client for reporting side of things. Business logic happens in the backend server. 2. Are its components broad enough and up to the task? Download the trial. The component set is small but adequate for me. The do not do a lot of fancy stuff. there was no Calendar, so I made one. It is in the binary section of the forum if you want to use it. Right now there are no 3rd party components. Tim is working on V2.0 of EWB and it will have the ability to be extended with 3rd party components (I believe). 3. What, if any, third-party components are supported and, most importantly.... As indicated above the client side does not have 3rd party yet, but the backend can if you use a Delphi based server. I use ReportBuilder, Tee Chart, Clever Internet Components, NativeExcel in my back end.... I have built several EWB sites and have used DBISAM and DevArt's UniDAC components to access MS SQL. I am happy with my choice to use EWB and I highly recommend it. I been in the game since 1981 and it will be 20 years more for me to be in your shoes... If I was 20 more years down the road I don't know what I would do. Walter |
Fri, Apr 4 2014 10:56 AM | Permanent Link |
Raul Team Elevate | On 4/3/2014 10:07 PM, Jerry Clancy wrote:
> I'm at a watershed moment, a crossroad regarding the issue of > development environments and would love some feedback. Some facts > (please pardon the length): Jerry, Walter and Matthew have already covered this in great detail so only things i'd add are: EWB requires you to re-think your back end since you still need to do fair bit of processing there (data access layer, reports, etc). Hence you would need to make significant changes and would likely still require the export capability to office formats. While i don't use it myself i believe ISAPI is being deprecated as of IIS8 so whether you stick with ISAPI or switch to something else would need to be considered. EWB front end is quite capable already but v2 will add some capabilities so try out EWB trial but really wait til v2 before you decide. If i were in your shoes i would stick with what i have and start fixing components/areas most painful in the current system - sounds like reports, etc. This likely would require upgrading to higher delphi sku to get isapi support back. During the change you can see then see where EWB might fit in and make the backend support it when you're making the changes so you can start trying out EWB in sections. Raul |
Fri, Apr 4 2014 11:02 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Matthew / Raul
I've just had a quick trawl through some of the cvs I have on file with a .doc extension. Some are binary some are rtf. I could probably figure out a cutover point if I worked at it but just because a file extension is .doc does not mean that its in Microsoft's propriety format. Roy Lambert |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |