Python with Rev and postGreSQL?

[John Tregea]

Anything that avoids complication is good by me.  :-D

The project has been incredible to work on. I have had to map and model 
1,600 data objects in releation to each other in the database and find 
naming conventions, permission models, role management methods etc. for 
the whole thing. The db is now done and the front end is taking shape. 
Rev is a perfect match for an environment where the structure of named 
elements within other named elements can enable you to find the 
corresponding data in a db structure.

We have one situation (in the middle east) that requires integration of 
CCTV, access control, RFID, GIS, fire alarms, intrusion alarms and 
traffic management as well as logistics, vessel and cargo tracking 
database systems. Over thirty data streams in all... I hope Rev will 
enable us to bring it all together on one screen in an emergency 
command, control and communication centre.

Regards

John T

kee nethery wrote:
> I'd suggest a standard HTTPS connection and just pass it XML as part 
> of a POST. Simple, easy to troubleshoot with a browser. SOAP is a 
> complication and there is really no need for it.
> Your project sounds like fun.
> Kee
>
>
> On Jul 13, 2006, at 5:34 PM, John Tregea wrote:
>
>> Thanks Kee,
>>
>> While the database structure is complete, the front end is not, (that 
>> is why I am evaluating Rev), I believe python is a good tool to 
>> connect to the database, but not sure if it is used by any other 
>> Revolutionaries or if anyone can say what has worked well for them? I 
>> believe SOAP is used by some as well?
>>
>> Regards
>>
>> John T
>>
>> kee nethery wrote:
>>> If I were you ... starting from the database working outward:
>>>
>>> Build a CGI that talks to your database. Host that CGI on your 
>>> servers. Give it the ability to access your database with a username 
>>> and password that only it knows and give it the ability to execute 
>>> any SQL that makes sense.
>>>
>>> Have your app talk to the CGI. Have it log in either with a stored 
>>> password in the app or have the user enter a password that you give 
>>> to them, or both.
>>>
>>> Have your app only send requests for SQL to be run. Don't send the 
>>> SQL, send the name of the SQL and the parameters. For example:
>>>
>>> SelectGameScores
>>> Team = Dallas
>>> Year = 2006
>>>
>>> That gets converted in the CGI into
>>>
>>> SQL = "select date,teamA,teamB,scoreA,scoreB from teamScores where 
>>> date >= 'Jan 1, {year}' and date <= 'Dec 31, {year}' and (teamA = 
>>> '{team}' or teamB = '{team}')"
>>>
>>> SQL submitted = "select date,teamA,teamB,scoreA,scoreB from 
>>> teamScores where date >= 'Jan 1, 2006' and date <= 'Dec 31, 2006' 
>>> and (teamA = 'Dallas' or teamB = 'Dallas')"
>>>
>>> Just make sure you do some validation in the CGI on the parameters 
>>> that come in to prevent SQL injection.
>>>
>>> If you do this, it doesn't matter if they can get direct access to 
>>> your CGI, they can only run the SQL you have predefined.
>>>
>>> Kee Nethery
>>>
>>> _______________________________________________
>>> use-revolution mailing list
>>> use-revolution at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your 
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>>
>>>
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your 
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>