My question seems to be very simple, but I can't find right answer after desperate Googling.

I am writing a Web site in VS.NET. The client has to fill table with DB-configurable set of "parameters". The values entered into the table have to be transferred to server database.

To accomplish configurable set of "parameters", I created "Params[ParID|ParName]" table in DB. "Parameter" values are to be stored into separate "Values[ParID|ParValue]" table.

The way the client table is rendered in HTML code is based on article:

http://msdn.microsoft.com/library/en...mtodataset.asp

Actual "Values" are transferred to client page via WebService delivering XmlDataDocument taken from DataSet filled from "Values" table. Binding between ParValues and table cells is accomplished via ParID used as 'id' attribute in HTML <input> tags.

Client fills-in or updates new values into input boxes, and submits the data. I want to transfer data as XmlDocument formed on client side in analoguous shape like that delivered from DataSet, and passed back to server via WebService.

My question is:

How to construct DataSet on server side which could be initialized from former data from DB, then synchronized with XmlDocument delivered from client, then updated back to DB ?

There are lot of code samples with editing DataSet programmatically or via binding e.g. to DataGrid in WinForm. But in my case, updates are to be performed in distributed Web environment via XmlDocument.

Please provide some explanation - is my design wrong or am I missed something.

P.S. I can't use simple Web Form ASP.NET controls, because my actual tables are more complicated and depend on other issues not described here.

kff

Hi,

After 2 weeks of waiting with my question on 5 forums, not a bad result... (only 1 response on devx) - was my problem too hard?

Of course I could not wait so far with my problem, so I solved it. To keep discussion alive, I am responding to myself - with soem new questions, of course.

My initial problem seemed to be very simple and popular.

I have to pass several records from database to client, let client to change their content, send them back to server and update database.

My design was to use technique like this one, described in MSDN article:

http://msdn.microsoft.com/library/d...mwebservice.asp

but with client part of the application and code implemented on the thin client inside IE browser and using JavaScript and webservice.htc.

Unfortunately, DataSet's are not implemented in JavaScript, so with some anxiety I implemented my WebMethod GetDataSet() As DataSet returning DataSet. Then I realized that on client side - in callback function passed to my webservice.htc - variable that keeps returned DataSet becomes legal IXMLDOMElement containing DataSet implicitly exported to DiffGram format.

So I was happy, designing to complete my scenario like this:

- gathering data values from client controls in JavaScript code;
- comparing them one by one with DiffGram content and store them to DiffGram representation using DiffGram rules for marking added and updated records, keeping old values in <diffgr:before> section;
- pass changed DiffGram via webservice.htc as an argument to my WebMethod UpdateDataSet(data As DataSet).

I did not wanted to implement client part of complicated code (working with DiffGram) without checking that it works. So in my GetDataSet() function, I made some changes to records in my dataset programmatically. While debugging client code I realized that the changes were legally transferred to client, stored in DiffGram representation. Passing DiffGram back to UpdateDataSet() worked, too; so I wrote the server part of consuming DataSet and updating database according to my initial design.

Unfortunately, after implementing JavaScript code that stores client changes from client HTML controls to DiffGram in the same legal DiffGram format, the SOAP code on the server that tried to convert DiffGram to DataSet responded with error 'table name not found in target DataSet', although my DiffGram looked (I debugged and compared them) exactly the same as in first part of my experiment, when it was actually modified on the server, passed to client as modified, and returned back with no problem.

This is my current question number one: why SOAP converion of client DiffGram to server DataSet fails if the DiffGram is modified on the client using JavaScript code? For me, it seems to be Microsoft bug in SOAP implementation of implicit conversion.

Having to implement my code, and willing to do this with DataSet power, I changed my UpdateDataSet() function to UpdateDiffGram(diff as XmlElement), converting diff passed as argument to ds As New DataSet() using

ds.ReadXml(New XmlNodeReader(diff), XmlReadMode.DiffGram)

explicitly. I can assure that this code finally works, so I think my problem is solved.

However, it was not so straightforward due to some stupid question (may be I do not understand something in WebService philosophy of passing objects via SOAP protocol).

When I pass DiffGram from client as an argument to WebService function, it becomes on the server side stripped from top-most element, exposing only its innerXml.

So my second question is: why I have to wrap up my diffgram in additional covering tag to pass it safely to server where the wrapping tag becomes implicitly stripped?

And my third question is: why Microsoft constructs with DataSet - that should work like a snap - does not work?

And my fourth question is: why VS.NET is so server-centric, so I have to implement handling DiffGram in JavaScript manually? Have you heard of any JavaScript-based implementations of DataSet functionality that would be ready-to-use? For my point of view, architecture of website with static HTML pages (or generated on server via ASPX code) and with data interchange using power of WebService, is ideal. But it does not seems to be completed. The missed chain is the JavaScript DataSet implementation.

__________________
kff



kff

I just started working with DataSets and I immediately started to look around for a Javascript Dataset implementation and found your post. I'm amazed you haven't seen more response, this is high on my list of desirables (I'm a big advocate of getting the client to do the hard work).

I wondered if you had any more success elsewhere or if you have any desire to pursue this further?

Barry.

Wow!!! it's taken me nearly a weak of web searching and book purchasing (including Wrox) to find anything or anyone talking about a web based client talking to a webservice utlising datasets. I can't believe there are not more people talking about this.

Nearly every bit of information is about .net providers and consumers or simply ASP.NET. I do not want to use the latters submit / request system - I want to use my browser as a proper application platform and there is no information about bundling up data and passing it to server for updating a database etc. It seems ADO.NET becomes a lot more awkward if you lose "state" - in other words if you don't start with a Dataset that you later update. I start with my own XML doc created in VBScript on the client - I want to post this to a web service and I want to update a DB.

The only working option I have completed is to break down my XML into a series of sql 'UPDATE ...' and 'INSERT ...' statements. Not really utilising ADO.NET - I could have done the same in ASP 6 years ago!!

I have looked at the DiffGram but can't see how to create the initial Dataset - do I need to provide the SQL command statements in the adapter or can I use the SQLCommandBuilder? Do I need to use typed datasets?

Clearly you have worked this out so any help on the server side would be much appreciated.

Cheers.

Your not going to see much on this because it is a fundamentally flawed design.

Using Javascript for anything important, like data integrity, is always a mistake. I would never trust a dataset sent back from javascript to be valid. I could ruin the whole thing by simply disabling JavaScript on my application.

If you really want to have the client do the heavy lifting, you would need to create an ActiveX (or Java) to load on the client page and have that do the communication back and forth. Of course, the idea of sending a .NET "DATASET" type to Java is going to be a pain. In this case you should use XML to transfer the data back and forth.




Hal Levy
I am here to help you, not do it for you.
That is, unless you hire me. I am looking for work.

As you'd expect - I disagree with this. I think you're mixing up different scenarios. If I was designing a public website then, sure, someone could disable JavaScript because I have little control over the client, but for that reason I wouldn't opt to use a browser as an application host for a public website!

I'm talking about an intranet / extranet application targeted for a specific browser and platform. And in the same way you would have to install the .Net framework for an application, you can stipulate that JavaScript is enabled.

Your last point is a little curious because it brings us full circle. This whole thread is about manipulating XML on the client in order to post back to a web service. Your last suggestion is to use Java or an ActiveX control to do the same thing as we are doing in JavaScript! An ActiveX control would even use the same MSXML library on the Windows/IE platform as JavaScript, and none of these methods support the framework - so what's the difference??

The last issue is that of 'Ajax'. The current fuss over Ajax would suggest the methods we are looking to employ are not 'flawed'. The only thing that I find amusing about Ajax is that this method of posting and receving data without form submission has been around as long as XMLHTTP - it's just no-one bothered to give it a daft acronymn.

Hi ga,
Im with Hal.
I dont think "The current fuss over Ajax" gives much weight to the argument.
Yes the technology has been around for a while, and its is gathering some pace now, but its still too much logic in the GUI layer of the application for my liking.
I think there will always be a place for elements of AJAX in sites as there will always be a place for FLASH in sites, but the whole site....?
But i doubt that the AJAX fashion will realistically provide full functionality to a full website in a well designed way.

Why dont you use smart client technology, this is the scenario for it.

PS.I know there are full Flash sites, and they can look good.

======================================
They say, best men are molded out of faults,
And, for the most, become much more the better
For being a little bad.
======================================

Actually, I wouldn't expect that. I would expect you would read my message and say "He's right. This is a bad design." But then, I have a HUGE ego.

I don't see how this matters. Javascript can still be disabled. One of the SVP's still might say "I want Firefox on my PC" and get it. And a user can still save the source code, change it locally, and send it off with bad data. MOST of the hacking done against companies are done by their own employees- either to get information for a competitor or just because they are upset over something. Failing to protect against internal fraud is not only a bad idea, it would be a SARBOX problem if the application is subject to audit.

Until the boss says "what happens if the employee goes into Kinkos and uses the computer there? And now your dealing with multiple browsers and platforms. I was at a hotel once that disabled Javascript by default- and wouldn't let me turn it back on. It would really be a problem if I had to access your application.

Sure, but if you don't have .NET installed- the program won't run at all. If you turn off JavaScript- the person can still mung the return results by hand and insert anything they want into the page- in an EASY way. Encrypt your communication inside a .net object and it's much harder for them to change data.

Yes, because it is more secure and less likely to be manipulated. If your going to have a design like this- you might as well do it the best way you can.

Sure it would. But in a real programming language you would be able to take the results- package up the XML in any way you see fit and connect to the web service to feed your data to it. Javascript doesn't really give you that kind of flexibility- that's why it's got script in the name.


Just because someone gave it an Acronym doesn't mean it's the right way to do things. AJAX is ok in limited situations- specifically I think when your looking to drill down on data. You select something and refresh the data based on the selection to view it. Much like how people handle dependent combo boxes. However, when it's time to post the data- that gets validated and formatted server side.


Hal Levy
Please do your own homework.
I am here to help you, not do it for you.
I do not have sample code for anything

Mmmm - lot of discussion for no real result.

Rodmcleay is some way off the mark. I should stress that the whole project is about an "application" not a website. Flash is irrelevant and so is the choice of tool, to an extent. Ajax was just an example of what web application developers (not web designers) have been doing for some time.

Hal is suggesting that people 'might switch JavaScript off' either because they can or because they are being malicious. I'm not sure what the working environment is like in the US, but I'm pretty confident if someone deliberately disabled their client and was unable to contribute to the operation of the company from which they draw a salary - they wouldn't last long! Secondly Group Policy on a Windows domain can prevent such action and lastly, if someone wanted to saboatge any form of software application, be it web based, .net or native Win32 code there are a host of options available.

This is a red herring. The fact is that a modern browser is a fat client by definition - IE is probably the fattest but also happens to make a superb application platform. And I stress application because it involves using much of the Microsoft specific features - so please assume we have complete control over the client! The application comes with a requirements list - if they're not met the system won't work. Now I'm sure I've read something similar to this on EVERY bit of software I've ever bought.

So what native code can we use within our client without plugins? VBscript or JavaScript. And I think if you devalue a code because it has script in the name then you miss the point about all interpreted code such as .net, PHP and Java. These are all glorified scripts which are interpreted at run time - even if they have had some form of pre-compilation. How do you draw the distinction between a script and a 'proper' language? Security - mmm - no, .net code has to be deliberately obfuscated and VB can be reverse engineered.

The proof is in the pudding - the system works well and outstrips any equivalent compiled windows system. This we know because we moved from the latter to web based software. Not only that but it works with little noticeable degradation on systems which are nearly six years old and with systems on the end of 512K DSL.

The question of manipulation is odd. This is very difficult to do. View the code - yes, examine data being posted to a server - yes, potentially even force an unwanted page load through examining and making up bespoke URLs - but compromising the structure of the application - not easy! Careful design has ensured no sensitive data including table names, stored procedures or connection data is ever viewable on the client. You can insert nonesense and yes you could bypass validation, but any database system will let you enter rubbish as long as it passes validation. But if you work in a corporate environent as I do - ask yourself - why?!! Disgruntled employee? The amount of damage they could cause on this system would be minimal and would take a long time, assuming they had the necessary skills. More damage could be achieved by simply deleting all operational data from a file server for which they had access.

My quest is not to change the platform - but to utilise the power of ADO.NET to replace our server based ASP and custom COM libraries. This brings me back to finding a way of suitabley packaging up XML to post to a webservice - which is exactly what a .net client talking to a .net webservice would do anyway!

How about some advice on the DiffGram rather than what level of control we extert over our employees and their workstations?

Cheers!!

Or they are security minded. Or they use a proxy that mangles the Javascript (as has happened at my last 3 engagements). There are so many "if's" when using javascript, you can not rely on it.

I will never assume we have complete control over the client-because we don't. I have many web applications with lots of "if" statements in the javascript to cover different implementations in different browsers. Anyone can turn on or off anything they wish.

Using your argument- we are using IE only- so we can use ActiveX also.
You really believe this? You want to say JavaScript is the same as c#?
Simple- how powerful it is and the ability to develop in an organized way. JavaScript is weak and does not lend itself to organization.

anything can be reverse engineered.

What system works well? Your comparing it to what? How was the "old" version written? Was it optimized as well as the web system? You can't compare apples and oranges- no even if you paint the orange red.

Incredibly easy. Save the HTML to your local drive. Make any changes you want to anything you like. Post back to the server.

I tell you what- you call all the corporate security groups and tell them they don't need to worry about internal security. While your at it, please call Mr. Sarbanes and Mr. Oxley and tell them they should just get rid of internal controls- Employees won't do anything bad- you can trust them.
ADO.NET was designed with security in mind- so MSFT just won't let you do what you want to do easily. It's not secure.

The only thing I could suggest is have a hidden frame that you can post from. When the submit is done, use the hidden frame to package up the XML and send it off to your web service. Perhaps only send back rows that were changed. Then have the webservice re-load the data- and apply the changes that were returned to dataset- and save it back out.


We are talking about sound architecture. I did a simple A9 search on DiffGram and came up with plenty of articles did you read those to see if they were of any assistance?

http://msdn.microsoft.com/library/de...ce02112003.asp seems like it might be some help for you.


Hal Levy
Please do your own homework.
I am here to help you, not do it for you.
I do not have sample code for anything