A very complex problem. I'm exASPerated!

[RadarBob]

Now that I've gotten your attention, I really need some help here thinking about a solution to my problem. Every tack I take presents new and different problems to solve. How the client-side is solved affects the server-side so I'm dual-posting to the JavaScript DOM forum. (http://codingforums.com/showthread.php?s=&threadid=9459)

I've posted a previous thread (http://codingforums.com/showthread.php?s=&threadid=8202&highlight=window) on this issue, but I need to think about it differently somehow to find a solution, if there is one. I know what I want for a solution but that is looking like a dead end.

The big picture
I have a pretty big HTML page for data entry. I'm using ASP and SQL Server 7 on the back-end to store and retreive the data.

I have a data sub-set on this page (ie a M:1 relationship to the whole page) where want to dynamically create new data entry rows.

The sub-data is the key/crux/focal point of the problem. What kind of interface do I give the user to enter all the data? I'm obsessed with a "one HTML page" solution. But I've seen absolutely nothing in ASP or DHTML that supports data entry or data manipulation with a 1:m relationship. I believe a "one pager" is best for the user, but as I struggle with this, the light at the end of the tunnel is getting dimmer!

In a perfect world I want to have all my data visible and editable from this one page. This design should also facilite sending to the server when the user clicks SUBMIT so that ALL the data goes at once and then on the server I don't have to sort out data coming from different pages (which would presume a specific data entry order by the user!) to get everything tucked away in the DB and maintain data integrity. NOTE: I don't use, and don't know how to use ADO transactions, so I don't know if this could be part the overall solution.


My Current Path of Exploration
I open a child window. In this child window, using DOM I dynamically create HTML table rows, each row representing a data record wherein. This is working great. Now the sticky wicket is getting the data back on the parent page.

Technical Issues, Questions, and current expimental track
Communication
* From the child page I need to be able to "reach out and touch" the parent.

** Looks like I cannot reference my parent page using DOM, Yes? No?

** I thinking of building a javascript object out of the "DOMinized" table - a little coding, but doable. Now I have a structure that is referenceable using either DHTML or DOM... Then what?


* NOW WHAT?
** I have some challenges at this point.
......(1) Reproducing the data on the parent page.
..........(a) I've found no handy DHTML methods to help out. For example it's possible to build new <select> options with "new Option()", but there's no equivelant for creating <TD> or <TR> for a <table> - is there?
..........(b) The only thing I can think of is "window.opener.document.write..."
..............(i) now the challenge is getting the table in the desired spot on the parent page.
..........(c) Utilize Cookies?
..............(i) now the challenge is referening a cookie from the parent page that was written from the child page. I'm pretty darn sure it's possible, but I don't know how.

......(2) Assuming #1 is solvable in any way, how do I get the table in it's desired place on the page?
..........(a) Using the 1.b solution above I imagine the table showing up on the very bottom of the page, below my buttons and page footer. Not good.

Brain Storming
Would having this "sub-data" in a separate form help in any way? As this data is visually between other data elements on the page, now I'd have 3 forms - and some of my data going to the same DB table will be split between two forms.


Don't even have the data displayed on the parent page at all. Store the data from the child page in a cookie, and when the SUBMIT button on the parent page is clicked, the cookie is fetched, the data values are all put in simple (hidden) text boxes inside the <form> so they also go along for the ride to the server. OR maybe the cookie itself goes along as an ASP cookie collection - but it was not built by the parent! Is that a problem?


Chuck the whole thing and put in a fixed number of rows for data entry. That's too easy :)


***** added to original post ************

OH, I forgot...
Are a mix of DOM and DTHML referencing allowed on the same page? In other words could I simply port all the child-window code to the parent page? when I try to execute "addRow()" I get a "object expected " error. Keep in mind this code works fine as a stand-alone window/page:


function addRow(thisTable){
var tbody = document.getElementById(thisTable).getElementsByTagName("TBODY")[0];
var row = document.createElement("TR");
row.id="reportRow";
...
} // end of addRow()

. . .
<body>
<form>
. . .

<table name="DBReportsTable" id="DBReportsTable" cellspacing="0" border="1">
<tbody>
<tr>
<td rowspan="2">Delete</td><th rowspan="2">Title</th>
<th colspan="4">Formats Available</th><th rowspan="2" colspan="2">Web Page</th>
</tr>

<tr>
<th>Not Avail</th><th>Printed</th>
<th>Electronic</th><th>Web</th>
</tr>

</tbody>
</table>
<BR>
<table id="controlPanel">
<tbody>
<tr>
<td colspan="2" align="center">
<input type="button" name="delReport" id="delReportID"
value=" Delete " title="Checked Reports will be deleted"
onclick="deleteRows('DBReportsTable');">
</td>

<td colspan="2" align="center">
<input type="button" name="addReport" id="addReportID"
value=" Add Report " onclick="addRow('DBReportsTable');">
</td>
</tr>
</table>

. . .
</form>
. . .
</body>
. . .
</html>



Whew! TIA
Daniel Boone
"Blazing new trails since 2001"

[whammy]

Wow. You have made your request extremely complicated.

If I were you I'd take it one step at a time... it sounds to me like this is mostly a client-side issue.

I would make sure all of your server-side variables are working first, and then figure out how to pass them between windows, etc. using javascript.

:confused:

Either that or perhaps you are looking for ASP.NET controls?

[fractalvibes]

Since we don't know what your data structures are that you are trying to update...and specifcally what you are trying to accomplish...

It sounds as if you might be trying to have a do-all page that might be difficult to write/maintain.

Try breaking the process down into discrete steps and see what
type of structure programmatically you have then. It may well require several post-backs to accomplish everything. i.e. select the gizmo you wish to edit and click 'edit'. postback. Edit and
postback to save the changes.

Break the process up into manageable chunks!

Phil J.

[whammy]

I usually write self-contained applications, even in Vanilla ASP. I don't think that's the problem... but I don't know.

[BrainJar]

In a perfect world I want to have all my data visible and editable from this one page.


That would be fairly easy in ASP.Net, asssuming you want to or can go that route.

Basically, you would bind a DataGrid object to your database table or view. ASP.Net would then generate an HTML page containing a table with the corresponding rows/columns. You could optionally add links that would let the user edit or delete each row individually. Then tack on some input fields for inserting new records.

Behind the scenes, ASP.Net just creates a new page each time, with a form that posts back to the same URL. It's not necessarily dynamic HTML but it does fit the "one page" concept. It's just a very complicated server-side script.

It can actually do some stuff on the client-side, such as simple form field validation via javascript and DHTML. Unfortunately, by default, it generally assumes that only IE can handle that sort of thing.

You could conceivably do the same in regular ASP. The advantage of using ASP.Net however is that it does a lot of stuff for you automatically. If nothing else, you could look at some of Microsoft's demos and documentation to see how .Net does things. That should give you some ideas.

[vihv]

I you have not found the solution take a look of this:
www.ex-isb.com then use helper/helper as a userid/pwd that will take you to a "report menu" go and create a new one.

click in the calendar, you will see a pop up asking u to enter all some expenses, enter 1 or two expenses, then click enter or the add expense button, that will take u back to the main window

as you can see, you just entered "data that is not showed in the main window" still that data is passed back and forw.. between the popup and main window, at the end is passed to the database....

then try making a "view" or edit same thing happens, data is not showed in the screen but still there......is this something like you're looking for???

[Spudhead]

I'm afraid I only got about halfway through that first post before I lost track of what I was reading about, but my small contribution woud be: Iframes.

The one-to-many relationships - it just sounds a little bit like something I did when i had to build an intranet-based workflow management system.

We had projects, and on those projects you'd have jobs, and on those jobs you'd have timesheets, and on those timesheets you'd have... well; me, trying to disguise 6 hours of quality Napster time as billable website development. But I digress.

Anyway, we'd have a page that loaded timesheet entries for a job, all set up as a nice editable table-type thing, and then just load that into an iframe on the main 'project' page, along with a bunch of similar iframes dealing with stuff like purchases and billing and developer stuff like version control. All laid out as these editable tables - datagrids, really, but before .NET.

And you didn't have popups all over the shop, and you never had to leave the project page you were on. Took a month of Sundays to load but hey, you win some you lose some. Anyway, your problem sounds just a tiny bit similar and I thought I'd share my wonderful little nugget of Iframe glory with you, just on the offchance.

As you were .... :thumbsup:

[RadarBob]

Wow, my original post is a year and a half old!

That was a time when I had no clue of the possibilities and techniques of how HTML, JS, DOM, etc. all work together.

Basically I wanted the user to be able to enter an unlimited (theoretorically) number of rows of data w/ associated data validation. Our corporate smarts here where I work was primitive (still is, *sigh*). I knew how to build a fixed number of rows server-side, but I wanted something slick.

The Document Object Model is the coolest thing since the web browser.

P.S. DEATH TO ASP!

[whammy]

Don't you just love these old posts that come back to haunt you?

:P