"Pros and Cons of ARS development" Being relatively new to ARS development, my "fresh eyes" definitely agree what I think you're saying: debugging workflow is very awkward. For a tool that calls itself a development platform, this is not a minor drag but a gaping hole. And I too have stared in disbelief at the .def files...
Remedy could be greatly improved if it could better interconnect with other tools. Most Remedy developers have some experience with shell, VB, Perl, and other utilities. And some have experience with programming languages like Java and C. Being able to use these utilities or languages with Remedy would be great. Remedy seems to be too much of a stand-alone development environment. Am I mistaken...? RELATED TO THIS TOPIC is that we have found it nearly impossible to upgrade Remedy after years and years of what I call "casual customizations". A "casual customization" is something small, like adding a field to the HelpDesk form. (Casual customizations are contrasted to building an Application in Remedy -- a full-blown project with its own forms.) I DON'T blame Remedy for this -- it's clearly a hole that we have dug ourselves into. But I have come to believe that Remedy's strength (ease of casual customization) is its greatest flaw when it is time to upgrade. Unfortunately, it is nearly impossible to convince users that after the upgrade they will loose their custom fields on the HelpDesk form. But again, this problem was created by us, not by Remedy per se. (now I feel better...) John -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Pierson, Shawn Sent: Thursday, July 24, 2008 9:00 AM To: arslist@ARSLIST.ORG Subject: Pros and Cons of ARS development - was Buy vs. Build I want to change the topic slightly and go off on a tangent that keeps coming up repeatedly. That topic is of the power of ARS for development. While I agree that ARS is great, I would have to qualify that to say that if you want to build an application that is within its capabilities, it is great. However, having worked with Visual Basic, PHP, Perl, and a few other things, I see plenty of limitations in ARS as a development tool. For example, there is no such thing as a variable in ARS. Yes, you can add a field to a form, even a Display Only field, but you can't instantiate fields during runtime on the fly. You have to purposely create fields for usage later on, and this limitation causes us to often re-use certain fields as generic variables, which can make troubleshooting difficult sometimes. I've worked on a system that someone else built that I had to troubleshoot something on a field that had many different Set Fields actions occurring at different points with different tables. It was definitely possible, but since ARS is missing another major capability that most development platforms have. ARS doesn't have a way to step through code. We can't start up processing on a form, and pause it to see what is going on. All we can do is 1) go through log files and recreate the workflow in our minds, or 2) pop up messages after each piece of workflow we want to troubleshoot. If there was a way to step through each piece of workflow that is running, that would be a tremendous help to us. Another issue that is more of a matter of taste I guess, is the inability to generate flat source-code. Yes, I have learned to read .def files to some extent, but it should be easier to read. Instead of values like " 4\1\1\179\2\4\32\Change Level IA - Implementation\" in workflow, the definition files should display what we see in the Admin tool. These are the somewhat major problems I have with ARS for development. If you want to build an application with a database back end, a web interface, and have most of the standard controls (save, search, displaying tables, etc) just work automatically, ARS is a great too. There isn't anything out there that I've worked with which can top ARS development in terms of speed. In some cases, you do have to make sacrifices for more complex functionality, but it's still a great development platform for what it does. I just wish BMC would change the things I mentioned above, plus a few other minor ones (I'd like to be able to use arrays if they implement variables, I'd like to be able to have workflow triggered off of typing in specific fields, not just pressing enter and gain/lose focus, etc.) What are your thoughts about the pros and cons of ARS as a development tool? Perhaps we can put all of our heads together and go back to BMC and tell them what we want, plus come up with enough positive things about it to show our clients and employers that ARS is a great development tool. Shawn Pierson Private and confidential as detailed here: http://www.sug.com/disclaimers/default.htm#Mail . If you cannot access the link, please e-mail sender. ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" ----------------------------------------- The information contained in the linked e-mail transmission and any attachments may be privileged and confidential and is intended only for the use of the person(s) named in the linked e-mail transmission. If you are not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you should not review, disseminate, distribute or duplicate this e-mail transmission or any attachments . If you are not the intended recipient, please contact the sender immediately by reply e-mail and destroy all copies of the original message. We do not accept account orders and/or instructions related to AllianceBernstein products or services by e-mail, and therefore will not be responsible for carrying out such orders and/or instructions. The linked e-mail transmission and any attachments are provided for informational purposes only and should not be construed in any manner as any solicitation or offer to buy or sell any investment opportunities or any related financial instruments and should not be construed in any manner as a public offer of any investment opportunities or any related financial instruments. If you, as the intended recipient of the linked e-mail transmission, the purpose of which is to inform and update our clients, prospects and consultants of developments relating to our services and products, would not like to receive further e-mail correspondence from the sender, please "reply" to the sender indicating your wishes. Although we attempt to sweep e-mail and attachments for viruses, we will not be liable for any damages arising from the alteration of the contents of this linked e-mail transmission and any attachments by a third party or as a result of any virus being passed on. Please note: Trading instructions sent electronically to Bernstein shall not be deemed accepted until a representative of Bernstein acknowledges receipt electronically or by telephone. Comments in the linked e-mail transmission and any attachments are part of a larger body of investment analysis. For our research reports, which contain information that may be used to support investment decisions, and disclosures, see our website at www.bernsteinresearch.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
