Brien:
You're right in that a Change Field action cannot make a field become
Required. I think the "no Active Link Guides in Mid-Tier" is an old
limitation, though; and shouldn't affect you with ARS 7.1.
It sounds like maybe you're mixing a couple of different topics:
1. Data Integrity -- many people find it's best practice to use only Filters
for data integrity checking. That being said, there is some benefit to doing
basic checking in Active Links when your application will be run through a
browser, in that the end user will see better performance. Active Links can
also make the uesr experience better by providing visual clues (eg, in the case
of multiple validation failures, changing all failed fields to red labels).
Filters will always enforce data integrity rules regardless of what kind of
client is talking to ARS (not all clients understand Active Links). Setting
fields as Required is a nice convenience, but I've worked on applications where
the development guidelines state not to use the Required attribute in order to
prevent failed DSO transfers or for other considerations.
2. Presentation -- I'd suggest a more modular approach to your application.
Regardless of whether the end user is entering a new employee or updating an
old one, all the same rules generally apply. So why not use the same screen
(form/view) for data gathering regardless of the operation being performed?
Most data entry screens are accessed from a control panel of some sort, so have
the end user choose new/edit from the control panel; then the system will
present the data entry screen, which always looks the same. The basic idea is
to separate the control panel type of functions from the data entry functions.
Alternatively you could have two different forms ("New Employee" & "Update
Employee"), but that increases complexity of the application and can lead to an
overall increase in cost of ownership (maintenance, performance, etc). Yet
another approach can be used when the data entry screens start getting too
complex/crowded, and that is to
use dialogs to build "wizard" type functionality into the application -- BMC
uses this approach extensively in their complex ITSM forms.
Just Some Thoughts,
--Phil (another Arizonan)
________________________________
From: Brien Dieterle <[EMAIL PROTECTED]>
To: arslist@ARSLIST.ORG
Sent: Wednesday, November 19, 2008 2:44:22 PM
Subject: employee setup form best practices?
** I'm building a custom form to handle changes for new/existing employees--
things like account creation, email setup, shared group folder permissions, new
computer setup, office phone setup, furniture and even name changes. I am
duplicating an existing form from a different system that did all of this on
one form using dynamic html to hide and show fields as selections are made.
I was wondering if anyone had any suggestions as to how to handle a big form
like this, or if this is the wrong approach entirely (should it be split up
into smaller forms?). My first problem is that the form starts with a basic
information gathering:
Select employee type: New or Existing.
Now, depending on what you select there are different fields available to fill
out (by hiding/showing different page holder tabs). The pain comes when
certain fields are required only when a certain choice is made. (If you select
"New", well, you better provide a first and last name, right?) It doesn't seem
like you can change a field to be required on-the-fly using "change fields" (is
that correct?). So I am left with leaving them blank and using filters to
check the required fields, or using activelinks to set the unneeded "required"
field to bogus values like "N/A".
Not a pretty picture. My gut says when something is difficult it is probably
wrong. Active Links Guides look like an idea but this needs to be web-based
(ALGs don't work on web?).
Thanks for any tips!
ARS 7.1 patch 003
MS-SQL
Tomcat
Brien
__Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
