Storing input parameters - Forum - OpenEdge Development - Progress Community
 Forum

Storing input parameters

This question is not answered

Need some input and/or good ideas.  

I've got an appserver program that returns our products in a large number of ways depending on input.  It's got something like 25 differnt input parameters, CHARS, DATES and INTEGERS. 

This program is called from a web front that collect various data from the user and then renders a view of our products. Works like a charm!

Roughly what I've got:

RUN returnProducts.p ON ghServer 
( INPUT productTypes , INPUT fromPrice , INPUT toPrice , INPUT fromGrade , INPUT toGrade , INPUT parameter1 , INPUT parameter2 , INPUT parameterN , INPUT sortingOption , INPUT pageToShow , INPUT resultsPerPage , OUTPUT ttFilteredProducts).

Now I want to specify certain fixed parameter settings to use at various points, for instance for background jobs generating xml-feeds with our products as well as webpages returning specific products on sale. Something like 50-100 different such settings will exists. The final goal is for our sale managers to be able to set up these parameters themselves and then make that collection of products into a webpage, xml-feed, rss-feed etc.

What I need is a table in which to store all parameter settings together with some metadata. I can see some options here:

1) Store parameters in a table with one field for each input parameter. Positive: easy to do. Negative: changing parameters will lead to schema changes.

2) Store all parameters in a single character field with some kind of delimiter. For instance first entry in a pipe delimited value is the first parameter, second entry is second parameter etc. Positive: easy and flexible schema . Negative:  harder to maintain, require a more complicated UI to make sure data types are correct etc. 

3) Rewrite the server-side program to take a value-pair TEMP-TABLE (ie tt.parameterName + tt.parameterValue) as input instead. Positive: easy to translate into a matching db table and flexible. Negative: lots of work to redo server-side program as well as existing UI.

Oh, and not OO!

Any better ideas? 

All Replies
  • Actually, Marian, I consider passing objects across the wire anathema.

    Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice  http://www.cintegrity.com