Hi Rod,
I guess we would NOT want one new action-type for each
PERFORM-/Application- command.
But I would be very glad for an action called something like
Internal-Function, or Run-Function command with the following:
- Function
- Where to run = Client/Server
- Run: Now/Phase 2/Phase 3
- Input Parameters
- Output Parameters
It could work more or less as a Filter API call.
This would be generic enough I think, and also give us more control over
passed parameters.
Controlling phases like that would more or less remove the need for the
$PROCESS$ syntax in Set-Fields. In any event, you could make these
"functions" be available as the ordinary Set-Fields Functions instead of
the $PROCESS$ syntax.
And I totally agree with you about the `! syntax...
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Yeah Misi,
>
> I'm a bit surprised that the run process commands have grown so much
> faster
> than the actions. I guess it's quicker to develop features as Run Process
> commands rather than have dev studio hold our hand and check the syntax
> and
> context on entry. I know that it wouldn't be practical to expect every run
> process to be implemented as an action but for some of the very common
> ones
> it would make a lot of sense. A business time command would be nice. The
> syntax on those process commands is darn tricky even for experts.
>
> The other thing that has surprised me is that the odd `! naming convention
> for overriding filter phasing has survived all these years. Surely it
> would
> be much nicer to have a simple check box field or something to indicate
> this. It would be easy enough to phase out the old method over time and
> just auto set the new check box if the name ended in `!
>
> I'm not a fan of the mechanics of a piece of code featuring in the name. I
> think it should describe what it does rather than how it does it. If you
> change how it does it then you have to change its name also. In Remedy
> since the name of an active link or filter etc. is the key you have a
> problem with version control if you keep changing the names of things. If
> you leave the name the same despite changing how things are done then your
> naming convention becomes compromised.
>
> There's a lot I love about Remedy and it does keep getting better but I'd
> like it if these couple of things were improved.
>
> Rod Harris
>
> On 12 December 2011 16:32, Misi Mladoniczky <m...@rrr.se> wrote:
>
>> Hi,
>>
>> I definitely vote for Commit Changes!
>>
>> Why use the ugly Run-Process bla bla bla syntax, when you have an action
>> that does the same thing?
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
>>
>> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10/11):
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>> > That's a good question Mark. I'm not aware of any differences that
>> would
>> > make one more efficient than the other. Personally I prefer to use the
>> > "Commit Changes" as it seems cleaner to use this rather than one of
>> many
>> > run process commands.
>> >
>> > Rod Harris
>> >
>> > On 9 December 2011 04:51, Brittain, Mark <mbritt...@navisite.com>
>> wrote:
>> >
>> >> **
>> >>
>> >> HI All,****
>> >>
>> >> ** **
>> >>
>> >> Commit Changes vs. PERFORM ACTION APPLY. Is one better to use than
>> the
>> >> other on ARS 6.3?****
>> >>
>> >> ** **
>> >>
>> >> I have one active link that populates data from a SQL query and a
>> second
>> >> active link to commit the changes. These were probably created under
>> ARS
>> >> 3
>> >> or 4. The Commit Changes does the job but always looking to smart way
>> to
>> >> do
>> >> things.****
>> >>
>> >> ** **
>> >>
>> >> Thanks****
>> >>
>> >> Mark ****
>> >>
>> >> ** **
>> >>
>> >> *Mark Brittain*
>> >>
>> >> Remedy Developer****
>> >>
>> >> *NaviSite – **A Time Warner Cable Company*
>> >>
>> >> mbritt...@navisite.com****
>> >>
>> >> Office: 315-453-2912 x5335****
>> >>
>> >> Mobile: 315-317-2897****
>> >>
>> >> ** **
>> >>
>> >> ------------------------------
>> >> This e-mail is the property of NaviSite, Inc. It is intended only for
>> >> the
>> >> person or entity to which it is addressed and may contain information
>> >> that
>> >> is privileged, confidential, or otherwise protected from disclosure.
>> >> Distribution or copying of this e-mail, or the information contained
>> >> herein, to anyone other than the intended recipient is prohibited.
>> >> _attend WWRUG12 www.wwrug.com ARSlist: "Where the Answers Are"_
>> >
>> >
>> _______________________________________________________________________________
>> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> > attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>> >
>>
>>
>> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"
