generating filepro HTML code using clerk !?

[Henry Arredondo]

-----Original Message-----
From: filepro-list-bounces+hxarredondo=lkqcorp.com at lists.celestial.com [mailto:filepro-list-bounces+hxarredondo=lkqcorp.com at lists.celestial.com] On Behalf Of Bruce Easton
Sent: Tuesday, March 13, 2012 11:36 AM
To: filepro-list at lists.celestial.com
Subject: Re: generating filepro HTML code using clerk !?

(inline response - Bruce)

On 3/13/12 11:29 AM, Henry Arredondo wrote:
> I'm currently using filePro's "HTML :id" code to generate HTML files (webpages) by running the "report file command" using index search "-i.." and it works really well and fast, but when the file gets hit real hard by many web surfers each new hit makes the report run slower and this drags all the rest running hits to a halt:
>
>
> 1)       If I stop using "report" and move it to "clerk" would the filePro's HTML code still work ?
Maybe.  Obviously our code will be triggered differently.  I rely on @menu for most output for browser from *clerk.  If you are using *report to produce web reports (and not input forms), then, although you may be following the same automatic index (as you've been doing with -i), you'll have to consider, under *clerk, how to achieve the same record selection and whatever final output sorting and sub-total breaking you've been using (where *report helps a lot with its @wbrk triggers, the 1-8 level sorting spec, and the ability to override any portion of that in selection processing).
>
>
> 2)       Is "report" mandatory to generate the HTML file using HTML :id commands ?
No.
>
>
> 3)      Would using clerk be faster that report ?
Hard to say.  I think it would really depend on the specific task.

<dream>I wish there was a 'for browser' version of *clerk (or a way to flag that the call is for that use), so that all of the memory and processing time dedicated to screen output could be eliminated.  It could even be dedicated to only run as @menu (so all code related to @when-field, @key events, @entsel, @update would be eliminated).  
Because all that is needed for that type of *clerk session is to be able to do lookups, have variables, call other similar processing, read & write files, plus the current set of commands and functions other than those relating to screen io. Ideally, it would be better to have a specific type of *clerk for this purpose rather than calling *rclerk with some new flag, since I suspect, removing all the unneeded code would reduce the size of the *clerk executable quite a bit. </dream>

>
> I have been splitting the Data in different qualifiers and this distributes the hits and speed things up.
>
> I'm using SCO Unix filepro 5.0.14.
>
> Thanks
>
> ________________________________
> Please consider the environment before printing
> -------------- next part -------------- An HTML attachment was 
> scrubbed...
> URL: 
> http://mailman.celestial.com/pipermail/filepro-list/attachments/201203
> 13/c46184f3/attachment.html 
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes 
> http://mailman.celestial.com/mailman/listinfo/filepro-list
>
>


I took your filePro HTML course in Las Vegas, the day we got hit by that rocking 7.0 earthquake, and since then I've been using the html :id ran by *report and it works so great , I use it a lot with forms and input tables mixed with some java (html :tx "<java>" ) for field validation.

I'll vote for your <dream></dream>

Thanks