NetTalk Central

Author Topic: <div>s and Source Procedures  (Read 3603 times)

Rob Mikkelsen

  • Full Member
  • ***
  • Posts: 107
    • Yahoo Instant Messenger - flashpott
    • View Profile
    • Email
<div>s and Source Procedures
« on: June 29, 2008, 02:27:52 PM »
Simple question for the net gurus, but it eludes me at the moment...

I generate some inline tables via source procedures when a form us submitted.  I would like to either clear the table if a field has changed or regenerate the table with the parameters on the fly.  I think I know how to call the source procedure via server code, but how can I clear the output from the first iteration of the table before creating a new one?

Thanks!

Rob

Mike Grigsby

  • Sr. Member
  • ****
  • Posts: 380
    • Yahoo Instant Messenger - onthedotsoftware
    • View Profile
    • MyHomeAssets! Software (among others)
Re: <div>s and Source Procedures
« Reply #1 on: June 29, 2008, 02:38:07 PM »
Until a real guru gets here, this is my input: Are you trying to generate a table on the fly? Not sure I totally follow you, but I'd start with a browse, perhaps no fields. (not sure if this works). But add a field and see how the browse generates the send packet, then break the original with an omit statement (possibly), and copy and paste that code as the basis of the logic for the table that you want to build below it, in a related embed point in the routine. Another thought is using some sort of session variable, so each field in the column has a condition like p_web.GetSessionValue('Show')=1, then in the server code area set p_web.SetSessionValue('Show', 1) or something. But maybe I'm totally missing what you're doing. MikeG
Mike Grigsby
Credify Systems
Central Oregon, USA

Rob Mikkelsen

  • Full Member
  • ***
  • Posts: 107
    • Yahoo Instant Messenger - flashpott
    • View Profile
    • Email
Re: <div>s and Source Procedures
« Reply #2 on: June 29, 2008, 06:17:09 PM »
Mike,

I think we are looking at the same thing.  I create a table in source below a form based on criteria on a form when the form is posted.  However, after the table is generated, if a field in the form is changed I would like to the table that was created and appended to the form to be removed since the criteria for the table generation have changed.  Ideally, I would like to refresh the table created in source just as an embedded browse is automatically updated, but that may be cumbersome for long table creation.

The only option that I can see for source procedures is to update on a timer, but that sounds incredibly wasteful.  Perhaps there is a simple flag that can be set via an AJAX call that will be spotted by the source procedure and remove the data.  I will look at that.

I will also look at the code generated for a browse update since that is the effect that I am trying to recreate.

Thanks for the reply, Mike!  It sure gave me a bit more to chew on... <g>

Rob

Alan Telford

  • Jr. Member
  • **
  • Posts: 81
    • View Profile
Re: <div>s and Source Procedures
« Reply #3 on: June 30, 2008, 02:06:28 PM »
i'm not sure if I understand you, but ...

I sometimes generate a simple table <table> ... </table> in an html string.
And I have this string a display field on my netWebForm.
Then if any of the fields change on the form, then under the Client properties for the field which changed, then set it to refresh my "htmlstring'.

This works for me to dynamically generate a table, and have it updates when the client changes fields on the form.
You may get some ideas by looking at the capesoft calculator example app.
The html string is refreshed everytime the user pushes a button. It's not a table in this case, but it could be.

Rob Mikkelsen

  • Full Member
  • ***
  • Posts: 107
    • Yahoo Instant Messenger - flashpott
    • View Profile
    • Email
Re: <div>s and Source Procedures
« Reply #4 on: June 30, 2008, 06:37:52 PM »
I think I understand.  The server code would call the source code which returns the result into a string that is defined on the form.  You then refresh that string via the AJAX update which replaces the existing content.  Cool!

I will have to play with that.  I had never considered using a display field to hold all the HTML code.

Thanks!

Rob