portal development


 
Thread Tools Search this Thread
Top Forums UNIX for Advanced & Expert Users portal development
# 1  
Old 05-30-2008
portal development

i am trying to develop a portal kind of thing where all the scripts will reside in unix.in our company we areusing Solaris.My requirement is to develop a portal which can be accessed from any where inside the oragnisation.If some one types a address 3.256.63.56/xxx.html the page should open.There should be many requests one user can put and for each request one button should be there.after pressing the button one shell script will run in unix and desired out put will be displayed.I have scripts developed in unix for all the stuff.only thing is to make it more interactive.i know a bit of html.how can i do this.the most imp thing is conncectivity between unix and the weblink.the restriction is i cant install any additional package in unix server.

please suggest me how to do this or some link where this can be found
Login or Register to Ask a Question

Previous Thread | Next Thread

1 More Discussions You Might Find Interesting

1. Programming

Need help in Ecommerce Portal Redirection?

Hi, I created one host ecommerce portal with complete ecommerce solution including payment gateway. To be clear I created ecommerce portal look like bigcommerce.com. I have already done with 98% backhand coding and also added a unique recognition number for each user after registration... (0 Replies)
Discussion started by: AimyThomas
0 Replies
Login or Register to Ask a Question
SPI_CURSOR_OPEN(3)					  PostgreSQL 9.2.7 Documentation					SPI_CURSOR_OPEN(3)

NAME
SPI_cursor_open - set up a cursor using a statement created with SPI_prepare SYNOPSIS
Portal SPI_cursor_open(const char * name, SPIPlanPtr plan, Datum * values, const char * nulls, bool read_only) DESCRIPTION
SPI_cursor_open sets up a cursor (internally, a portal) that will execute a statement prepared by SPI_prepare. The parameters have the same meanings as the corresponding parameters to SPI_execute_plan. Using a cursor instead of executing the statement directly has two benefits. First, the result rows can be retrieved a few at a time, avoiding memory overrun for queries that return many rows. Second, a portal can outlive the current procedure (it can, in fact, live to the end of the current transaction). Returning the portal name to the procedure's caller provides a way of returning a row set as result. The passed-in parameter data will be copied into the cursor's portal, so it can be freed while the cursor still exists. ARGUMENTS
const char * name name for portal, or NULL to let the system select a name SPIPlanPtr plan prepared statement (returned by SPI_prepare) Datum * values An array of actual parameter values. Must have same length as the statement's number of arguments. const char * nulls An array describing which parameters are null. Must have same length as the statement's number of arguments. n indicates a null value (entry in values will be ignored); a space indicates a nonnull value (entry in values is valid). If nulls is NULL then SPI_cursor_open assumes that no parameters are null. bool read_only true for read-only execution RETURN VALUE
Pointer to portal containing the cursor. Note there is no error return convention; any error will be reported via elog. PostgreSQL 9.2.7 2014-02-17 SPI_CURSOR_OPEN(3)