Hi.
Iam quite new to CGI Programming, but have some good experinece in Perl
Programming and have found HTML::Template to be useful even for non web
related tasks. It is from there I learnt about C::A and when I had a CGI
related task at my hand C::A was my first choice.
I have written a reusable input validation system using C::A and I
thought I will seek advice from the experts about the design and how
better it can be done.
The problem at hand is to validate a set of IDs. These IDs have by
construct more details packed into them and hence at times we may have
to resolve some ambiguity in the input by asking the user "Your id has
A and B. What do you want A, B or both ". After resolving the
ambiguity the app will build an extended ID( that will have more
metadata ) and pass it to the actual webapps that might use it and do
some meaningful work. These IDs are primary input for many small
applications and hence I thought I will make a C::A with run_modes for
validating these inputs. This is what I came up with. Please critic on
the design and suggestion on how best it can be done is most welcome.
The IDs are basically keys joined by a '#'. I have called my ID
validating system as IDBuilder.pm.
There are two things that can be done with the id
=> validate - Just check for correctness
=> prune - Resolve ambiguity and return extended ID with metadata
These will be the two modes in which the IDBuilder can be used. An
application will first receive the data from the user and call the
IDBuilder in either of the two modes. Also it needs to pass a few
mandataory parameters
1. id_list => list of ids to be validated or pruned
2. do => [ validate / prune ]
3. callback_url => URL to call when the action is done
4. callback_mode => run_mode of the callback app
5. extra_params => param1, param2, param3 [ optional ]
[ if extra_params is specified ]
param1
param2
param3...
After receiving the input it will do validation of the IDs and show a
error screen with a back link for the user to correct the inputs. If
asked to prune the IDs it will show up another form with checkboxes
and textboxes which will help in getting more information to build an
extended ID and then it will pass the metadata to the callback_url
setting the run mode to callback_mode. The App also has features to
pass in extra parameters to the callback_url by using the extra_params
parameter.
.---------, .---------,
| | | |
| Input | .----------| Input |
| Page | | | Resolver|
| | |p | in |
| of |rm |r | |--+ ..........., callback_url
| | |u | IDB | | . Auto . .---------,
| App | |n `---------' | . Redirect . | |
`---------'<param1> |e .---------, | . Page . | App |
| <paramn> | | | +---. .-----| screen |
| id_list | wrong | Error | | . to . | using |
+----------------+-----------| screen | | . . | id_list |
| callback_url |v id | in | | . callback. | |
| callback_mode |a | | | `..........' `---------'
| extra_params |l | IDB | | id_list
.........., |i `---------' | rm
.Optional . |d | param1
. Input . do |a | paramn
. Page . |t | action=callback_url
. . |e | <form is auto submitted>
. of . +------------------------+
. . id_list
. IDB . extra_params
`.........' param1
paramn
callback_url
callback_mode
Let us call the reusable input validator as IDB and the external
Application that is going to use this input validator as App. Then the
picture describes the flow of the data and the hideous parameters that
gets passed along with each oh the pages.
o There is a data entry form in IDB which can be used to get the data
from the user. This has to be called with
. callback_url => The page to show up After validation
. callback_mode => The mode in case of C::A ( will be called as
callback_url?rm=<callback_mode> )
. do => Do What with the inputs Prune ? or Validate only
[ will be the next runmode in the pipeline ]
. extra_params => Name of the additional parameters to be passed to
the callback_url
. param 1..n => additional params to be passed to the callback_url
o The input is validated and if there are any ERRORS in the ID an
error page is shown
o If there is any ambiguity in the IDs then they will be taken to
another screen with a form where the user will enter more
information which when combined with the ID to form an extended ID
will resolve all ambiguities.
The parameters are also carried along to this form
. callback_url
. callback_mode
. extra_params
. params 1..n
. id_list
o The final id_list will be passed to another form which will have an
auto submit to the callback_url
Iam expecting comments on this. As I have to do some more processing
after the input resolver I cannot directly set the action to the
callback_url in the Input resolver page. Once the extended IDs are
built they need to be sent to the App's page. A simple Meta redirect
did not work and I have to resort to this form and auto submit. But
this POST method is also advantageous as it leaves the URL clean in
the browser.
My questions are :
1. Is there a better way of doing this.
2. Is there any way I can keep passing these default params to the
successive pages. ( callback_mode, callback_url, extra_params,
param1..n) so that even if I have mutli-page input validation these
params will get passed along all the way without me having to bother
about it.
Hope Iam clear.
Regards,
Thens.
--
-----------------------------------------------------------------
Thenappan M,
APDC, Texas Instruments India Pvt. Ltd.,
Email : suppressed, suppressed
Phone : 91-80-5048273
-----------------------------------------------------------------
Don't worry over what other people are thinking about you. They're
too busy worrying over what you are thinking about them.
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/suppressed/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.