Re: Webalchemy to convert HTML to PL/SQL

It seems that they might want to give a try to our Dynamic PSP toolkit for this task. Although they stated that they run 8.0.4 and "thus PSP is out of question", Dynamic PSP runs on 8.0.4 (though we didn't test it on 8.0.x, but we are pretty confident that it will work on any 8x platform), uses the same syntax as Oracle PSP, and extends PSP with such features as web-based development environment (no external files, no timely loadpsp's for a one char change), number of predefined functions for flow control, debugging and profiling, ability to call one page from another and either embed results directly in the stream or get them as varchar2 or table of varchar2 and process further before putting out, ability to either execute pages dynamically or compile them into packages for subsequent wrapping and shipping to untrusted parties, and more. Dynamic PSP does not impose any limits on page size or number and/or types of page parameters.
As to this particular task, they will be able to get all their static HTML under DPSP control and add dynamic content generation using PSP syntax (PL/SQL code within HTML) quickly and effectively.

To see live demo of DPSP, or get a trial copy, please visit http://www.dpsp-yes.com

regards,

   Bob.

"Foo Man Choo SE" <foomanchoose_at_yahoo.com> wrote in message news:424fd2be.0109040558.40d9b6e8_at_posting.google.com...
> Comments, anyone? --Rob
>
> foomanchoose_at_yahoo.com (Foo Man Choo SE) wrote in message news:<424fd2be.0108311041.7a2022b4_at_posting.google.com>...
> > We have relatively involved HTML pages created using Dreamweaver.
> > These pages contain a form with lots of tables within tables
> > containing various Select lists and other form objects. We need to
> > convert these into PL/SQL so that code could be added to generated
> > dynamic content for the select lists, etc. Note that this is for
> > Oracle 8.0.4 (OAS 4.0.8) on Solaris so the use of PL/SQL Server Pages
> > (PSP) or other 8i functionality is out of the question.
> >
> > Well, we tried Webalchemy but it generates code containing several
> > levels of nested function (i.e. htf.*) calls instead of separate htp.*
> > calls. The following simplified example shows the result:
> >
> > --------------------------------------------------
> > .
> > .
> > htp.tableRowOpen;
> > htp.tableData( htf.tableOpen( cattributes => ' width="100%"' ) ||
> > htf.tableRowOpen ||
> > htf.tableData( htf.tableOpen( cattributes => '
> > cellspacing="6"' ) ||
> > htf.tableRowOpen( cattributes => ' bgcolor="#999999"' ) ||
> > htf.tableData( htf.para ||
> > htf.bold( '<FONT size="2">' ||
> > 'Enter search text to select User:' ||
> > '</FONT>') ||
> > htf.formText( cname => 'tUser', csize => '35', cmaxlength =>
> > '100', cattributes => ' onKeyUp="foo()"') ||
> > htf.formSelectOpen( cname => 'lUser', nsize => '5') ||
> > htf.formSelectOption( 'LIST LINE 1', cattributes => '
> > value="LL1"') ||
> > htf.formSelectOption( 'LIST LINE 2', cattributes => '
> > value="LL2"') ||
> > htf.formSelectOption( 'LIST LINE 3', cattributes => '
> > value="LL3"') ||
> > htf.formSelectClose ||
> > htf.tableClose);
> > htp.tableRowClose;
> > .
> > .
> > ----------------------------------------------------
> >
> > The problem with this is that it makes it a lot more difficult to
> > insert PL/SQL code to, for example, generate the Select Option lines
> > (e.g. LIST LINE 1).
> >
> > There appear to be four options:
> >
> > (1) Convert the Webalchemy output to change the htp.TableData()
> > statements to htp.print("<TD>") and change the nested htf.* calls to
> > serial htp.* calls (of course, not all would have to be changed this
> > way). This would then permit the direct insertion of PL/SQL
> > statements. PROBLEM: The required changes are very tedious and
> > error-prone when dealing with large and complex HTML pages.
> >
> > (2) Leave the nesting as is but write own functions to return
> > concatenated htf.* generated strings. In the above example, the three
> > calls to htf.formSelectOption would be replaced by a single function
> > call. This new function would query the database and generate a bunch
> > of htf.formSelectOption calls whose output would be concatenated into
> > a single return string. PROBLEM: Due to the large number of potential
> > items in the Select list, it could exceed PL/SQL variable (or other)
> > limitations. Limitations could include: number of parameters on
> > function calls, size of parameters, nesting levels, etc. This is just
> > a guess on my part--anyone know if there would be any problems taking
> > this approach?
> >
> > (3) There appear to be at least two other conversion utilities which
> > take the "dumb" approach of converting all HTML lines using
> > htp.print() calls only. These utilities also provide rudimentary
> > ASP/JSP/PSP style support of imbedded PL/SQL so updates can be based
> > on single source. PROBLEM: Not sure other than it doesn't appear to
> > be the Oracle recommended way. I'm also not sure if there are any
> > performance implications of using only htp.print calls vs. the
> > specific Oracle calls.
> >
> > (4) Webalchemy claims to support imbedded PL/SQL (within HTML) as
> > well. However, running it against non-trivial HTML, results in
> > incorrectly placed PL/SQL within nested htf.* calls. PROBLEM: Doesn't
> > work.
> >
> > Does anyone have any suggestions or approaches I may have overlooked?
> > Thanks.
> >
> > --Rob
Received on Thu Sep 06 2001 - 08:41:33 CDT