G
G. Tarazi
If you are planning to write a small app, here is an idea:
Microsoft has a new addition to Office 2003, and it's called InfoPath 2003; the product is brilliant, but unfortunately there are many things missing yet.
The product is capable automatically of storing, retrieving and extracting data from Microsoft SharePoint services; it also can connect directly to a database, or a web service, but that web services part still need a lot of work.
The product is cool, the forms it designs are attracting the big companies, and there are many project (like the one currently I am working on), that are using InfoPath instead of ASP.NET or Windows Forms.
The forms are very powerful, not that complicated to program "not as easy as Windows forms, but I don't think that will last for long
", and businesses are using it.
Although InfoPath uses Xml, most of the businesses are still using the relational database modules for data storage, and here is the real problem, mapping all that Xml to the database using the web services.
Today most of the company's standards are having the middle layer as a web service, not connecting the form directly to the database, achieving that standard is easy, create a data set as a schema, load it to InfoPath (web service), and the InfoPath side is done.
But what about the web service part?
Usually there are multiple stored procedures, some times over 50, that are managing the data of all that form, all of them have their own datasets, the biggest problem today is finding the best way to map the main Dataset that InfoPath uses with all those datasets, and to make it work as fast as possible.
Of course there are many solutions out there, but none of them is perfect, you can use BizTalk 2004, but it not designed to work with changing database structures, and it is not supporting rollbacks on the database levels.
You can try to use XSLTs generated from XMLSPY, but you cannot debug them in VS.NET, and they are slower anyway, and if the schema changes the compiler will not let you know.
If you are planning to write software, here is the idea: mapping schemas between InfoPath and VS.NET datasets, and generating a C# code that does the job, you'll probably make a good income of it
http://LiveTechnologies.ca
Microsoft has a new addition to Office 2003, and it's called InfoPath 2003; the product is brilliant, but unfortunately there are many things missing yet.
The product is capable automatically of storing, retrieving and extracting data from Microsoft SharePoint services; it also can connect directly to a database, or a web service, but that web services part still need a lot of work.
The product is cool, the forms it designs are attracting the big companies, and there are many project (like the one currently I am working on), that are using InfoPath instead of ASP.NET or Windows Forms.
The forms are very powerful, not that complicated to program "not as easy as Windows forms, but I don't think that will last for long
", and businesses are using it.Although InfoPath uses Xml, most of the businesses are still using the relational database modules for data storage, and here is the real problem, mapping all that Xml to the database using the web services.
Today most of the company's standards are having the middle layer as a web service, not connecting the form directly to the database, achieving that standard is easy, create a data set as a schema, load it to InfoPath (web service), and the InfoPath side is done.
But what about the web service part?
Usually there are multiple stored procedures, some times over 50, that are managing the data of all that form, all of them have their own datasets, the biggest problem today is finding the best way to map the main Dataset that InfoPath uses with all those datasets, and to make it work as fast as possible.
Of course there are many solutions out there, but none of them is perfect, you can use BizTalk 2004, but it not designed to work with changing database structures, and it is not supporting rollbacks on the database levels.
You can try to use XSLTs generated from XMLSPY, but you cannot debug them in VS.NET, and they are slower anyway, and if the schema changes the compiler will not let you know.
If you are planning to write software, here is the idea: mapping schemas between InfoPath and VS.NET datasets, and generating a C# code that does the job, you'll probably make a good income of it
http://LiveTechnologies.ca