Franklin Lee, Note: This post may sound "negative" towards ARSPerl. It is not intended to be. My understanding of ARSPerl's reach and range may be limited as I have not seriously used it for some time now. ( FWIW: I have moved on to the Java API. ) I do still use it some, for the tasks that it is "best suited" for, but I have often found limits in my abilities to use the wrapper to do "complex tasks" with ARSystem.
In general, I have often found that people that I will call "true programmers" look at the ARS api and are left scratching their heads over the choices that were made when the api was being laid out. To be clear, what you think of as "inefficient" may not be as bad as you think. (And there maybe options that ARSPerl simply does not yet implemented, or exposed to it's users too.) FWIW: The C and Java api's support a great deal of granularity as to the level of details that you can get about the objects in the get* api calls. So you do not have to get all of the field details when all you want is the "fOption" settings for all of the fields. Yes you do have to make a trip to the server for every field. However that is simply because there are no advantages for the vendor (Remedy, and now BMC Remedy) to have a single API call that returns that specific range of details for all fields on a single Form or even "All Forms on a server" for that matter. I am however, unclear if the ARSPerl wrapper around the C API offers the ability to limit the details that will be fetched for the ars_GetField call. (It looks like there are no inputs to achieve that goal.) For that matter I can not tell if ARSPerl has implemented the ARGetMultipleFields API call either. The published HTML docs do not appear to reference theARGetMultipleFields function specifically. In fact the HTML docs give the impression that ars_GetFieldTable specifically uses "ars_GetListField and ars_GetField". But I must add that it is possible that the ARSPerl wrapper does include a way to call the underpinning C ARGetMultipleFields API and it may not be documented yet too. You may also find that getting all details about a form will produce the data set you need. However, you may need to walk the data returned in ways that are not provided by the ARS API too. The AR System is a 3 tiered system. Client, Server, and RDBMS. The vendor has made decisions about that tasks will be done by each of those layers for their own reasons. (And there is no written explanation that I have ever come across.) Often programmers expect the Server (ALA: ARS API ) to do things that I believe were deemed to be the responsibility of the client layer. (There are many examples, not the least common of which has to do with desires to programmaticly dissect, construct, or manipulate ARS objects in mass. Which are generally not implemented in the provided clients. Even when they are simulated in the provided clients I greatly suspect they are simply looping over the objects selected and calling multiple single get/set/create API calls for each one.) However, over they years as the AR System application reach and range improved the ARGetMultiple* API calls were added to help with some (not all) of these needs that the vendor started to face for their own clients functionality. Please keep in mind that while the AR System API is expose to the customer that I have long believed that its design and purpose is very vendor centric. The gaps may be there simply because the vendor does not have the same needs, or they might be there to intentionally leave gaps that make it harder for customers to totally replace the vendors clients. ( You can reach either conclusion easily and likely can find "evidence" to support both positions fairly easily.) But long story short... So as a wise teacher often says.... The rest is left to the student (er.. Client in this case) to implement. If you speak Java, you should will find the Java API to be more complete. (and in theory, "supported" directly by the vendor.) I hope some of that helps. -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Mon, Dec 1, 2008 at 2:02 PM, Franklin Lee <[EMAIL PROTECTED]> wrote: > The getField function will get me field information on a _single_ field. > But what if I want to get field information on _all_ the fields in a > form at once. > > I could, of course, call getField multiple times, but that seems very > inefficient. > > What I need is an ARSPerl version of ARGetMultipleFields. Does such an > ARSPerl function exist? > > > > jeff murphy wrote: >> On Dec 1, 2008, at 12:45 PM, Franklin Lee wrote: >> >>> I can, by querying against the field table, get field information such >>> as fOption and default value for all the fields in a given form. To do >>> this, I need the schema id. >>> >>> Is there any other way to get this information without knowing the >>> schema id? >>> >> >> >> >> For default value, etc, I think getField() should return that >> information. You don't need the schema ID to use getField() >> >> >> http://www.arsperl.org/manual/ds_field_hash.html >> >> -- >> Arsperl-users mailing list >> Arsperl-users@arsperl.org >> https://lists.sourceforge.net/lists/listinfo/arsperl-users ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- Arsperl-users mailing list Arsperl-users@arsperl.org https://lists.sourceforge.net/lists/listinfo/arsperl-users
