Hi guys I need to exposed my application configuration files that can be edited on the fly and some reports on a web page. All of my application are either console / win forms app.
I'm planning to use XSLT and http listener class of .net for the implementation is this a good idea to start or not? or is there any implementation of this kind ?
Editing web.config or app.config should be avoided in lieu of storing such settings that need to change dynamically in another data store, like a database. If you store such settings in a database you can easily create a UI to administer such settings.
If I'm understanding you correctly then what you want is a web interface that users can use to modify some configuration properties and/or generate some reports based on data that is being used/generated by one or more desktop applications.
You need to define a central database, like SQL Server or something similar. Your desktop applications then need to store their data in this database. Then it would be super easy to build a web user interface that could also use the same database and view/manipulate data.
You're question is kind of vague so for now that's the best answer I can give you. I'm thinking you need to re-think your architecture.
Related
Not sure how to ask this question but I'm looking for a clean way to solve a problem for a project. I'm trying create a class library that will allow someone to create a randomized character for a game and use the data for a web app. I have a CharacterModel class that has all the needed data publicly exposed, however I need a way to edit this information without making the setters publicly available. Also, if I have multiple characters in the future, how do I get the editor to effect specific objects? Is there a design pattern for this type of problem?
Make the setters public. If someone is using your library to create instances of CharacterModel and they plan to use it in a web app, they will know how to wrap access to the data in a safe way.
They will most likely use your library to create instances of your class, then store them serialized in a data store. When they send the data to a user of their app to look at and interact with, they'll either expose it through a web api of some kind to be accessed by a front-end SPA client or they will use a framework to render the data as HTML (e.g. ASP.NET Core w/ razor pages or mvc).
Whenever the user of their app requests changes to the object they will pass requests from the webpage or from the SPA client back to the server (either controller endpoints or through form posts) and they will use an auth system, character model identifiers and other code to determine what changes the user can apply before they save the changes to the data store (usually a database or a document/nosql system).
In other words, in relation to your question:
"...if I have multiple characters in the future, how do I get the editor to effect specific objects?"
...you'll let the consumer of your library figure that out when they are building an application with it.
As per requirement, we need to convert the existing MS Access database to a web application. Is there any easy way to convert the MS Access database to web application? As of now they are inserting the data to access db using access Forms. User also wish to continue access form feature even if we create new web application for the same. That means user should have the option to access the MS access database through Access forms as well as web application.
Please guide me away to solve this issue.
Best Regards,
Ranish
You can use Office 365 and have somewhat of a web-based application.
https://blogs.office.com/en-us/2012/07/30/get-started-with-access-2013-web-apps/
Or, store Access in SharePoint, but your functionality will be quite limited. Keep in mind, no VBA will run on a web-based application.
The alternative is to use SQL Server Express, and ASP.NET, both of which are free from Microsoft. I'll tell you now, though, the learning curve will be quite steep if you have never used these technologies before. This combo, however, will give you the most control!
You can get the .NET framework from here.
https://www.microsoft.com/en-us/download/details.aspx?id=30653
You can get SQL Server Express from here.
https://www.microsoft.com/en-US/download/details.aspx?id=42299
Four years after and according to this:
https://www.comparitech.com/net-admin/microsoft-access/
still a question for many. Access can be converted to an Web App in almost no time. Particularly Access Forms are super easy to crate with the library like Jam.py.
The process was discussed on Reddit in April 2021:
https://www.reddit.com/r/MSAccess/comments/mj4aya/moving_ms_access_to_web/
I see quite a few Access databases with more than 100 tables, all converted successfully to SQLite3. After inspecting the imported tables via provided link, Forms are automatically created. Which leaves the Access Reports and Business Logic untouched. Reports can be designed in LibreOffice for Jam.py as Templates. Business Logic can be moved from VB to Python, if there is a need to do so.
The SQLite was selected as the default DB for the conversion, since it is very portable. Looks like the converted App can be moved to any DB that Jam.py supports, by Export/Import.
Cheers
First of all, Database and Web Application are not mutually exclusive.
Back to original question, I have done multiple projects like that. A client started with small Microsoft Access database with a couple of user; then they migrate to to web application when they get more traffic.
At first, you want to convert data from MS Access Database to SQL Server. MS Access Database is not meant to access multiple users simultaneously. Then you develop the Web Application which uses SQL server as back end database.
Right before you go live, you convert the data again from MS Access Database to SQL Server very last time. Then do not let them use old MS Access Database anymore.
Easy way to convert the MS Access database to Web application
Most of the time whoever created MS Access database are not software engineer, so table are not normalized and do not have relationship at all. I normally create new normalized database in SQL Server. Then write a small program to convert those data from MS Access to SQL database.
There are generally two approaches with more details covered in this article looking at ways to convert microsoft access to web application
Direct Port means simply a basic migration whereby you port more or less verbatim basic Access forms into a web portal i.e. Microsft Access to a browser-based version as is using a third-party tool. Some of these are quite mundane in that it just allows you to run the Access application inside an internet browser (whoopee!) or can be quite drawn out and then limits you on how much you can change afterward. With even more complex cases requiring a consultant to help you migrate the system. Though it does help to know your user count as the higher you tend to be, the less appealing a third-party porting service becomes due to subscription-based models.
Upsize -the more involved or complex your data structure is an upsize using custom development and splitting the system across web and data tiers might be worth it if
You've got a special process or some secret sauce you're looking to keep.
Likely going to have a significant user count and want to avoid subscription
Inherently cynical or cautious, and want to handle your own architecture and security
Looking for a specific user experience
If you mean how to convert automatically and you want to keep both Access and the Web application (I don't recommend that, I would move everything to the Web app) I would do the following:
Export your Access data in CSV/Excel
Use a platform like DaDaBIK to import the CSV/Excel file and automatically create a Web app based on that file, with data stored on SQL server, MySQL, PostgreSQL or SQLite.
connect your Access to the SQL Server (or Mysql, ...) database created by DaDaBIK, from now on Access will only be used as a frontend.
Now you have a web app created with DaDaBIK and your Access frontend both working on the same DB. As I said I would skip 3) and keep only the Web app, this helps with handling data integrity when two users are accessing the same record.
Depending on how complex is your Access Application (e.g. complex validation rules or custom VB code you added), you could reach your goal without any coding or with some coding.
I am developing a MVVM WPF application that requires storing large amounts of relational data. I would like to use a database platform, as it will simplify the task and the resulting software would be more robust. There are concerns, however that the users will not be able to install or configure a database.
Are there any options that allow a database to be used, but also created and configured automatically by the application? Are there any that can be 'hidden' inside the application's resources so they cannot be accessed directly?
I am storing location data. Each record has a time of occurrence, and an x and y coordinate. A Tag can have many records of location data, along with custom data items that can be added by the user. The database would likely have 5 tables at the most. Is a database the right choice, or should I really be creating and loading custom files into the MVVM WPF application? I'm really not experienced with managing all of these file operations, creating directories so they can be used in the application and I feel that I can build a much better application using a database. Are there any resources relating to what I'm looking for?
IF you want to use a database take a look at SqlCompact or SqLite
Both of these allow you to store relational data and embed the database engine into your application.
Shameless plus: SauceDB also supports both of these.
I am working on a Silverlight client and associated ASP.NET web services (not WCF), and I need to implement some features containing user preferences such as a "favourite items" system and whether they'd like word-wrapping or not. In order to make a pleasant (rather than infuriating) user experience, I want to persist these settings across sessions. A brief investigation suggests that there are two main possibilities.
Silverlight isolated storage
ASP.NET-accessible database
I realise that option 2 is probably the best option as it ensures that even if a user disables isolated storage for Silverlight, their preferences still persist, but I would like to avoid the burden of maintaining a database at this time, and I like the idea that the preferences are available for loading and editing even when server connectivity is unavailable. However, I am open to reasoned arguments why it might be preferrable to take this hit now rather than later.
What I am looking for is suggestions on the best way to implement settings persistence, in either scenario. For example, if isolated storage is used, should I use an XML format, or some other file layout for persisting the settings; if the database approach is used, do I have to design a settings table or is there a built-in mechanism in ASP.NET to support this, and how do I serve the preferences to the client?
So:
Which solution is the better solution for user preference persistence? How might settings be persisted in that solution, and how might the client access and update them?
Prior Research
Note that I have conducted a little prior research on the matter and found the following links, which seem to advocate either solution depending on which article you read.
http://www.ddj.com/windows/208300036
http://tinesware.blogspot.com/2008/12/persisting-user-settings-in-silverlight.html
Update
It turns out that Microsoft have provided settings persistence in isolated storage as a built-in part of Silverlight (I somehow missed it until after implementing an alternative). My answer below has more details on this.
I'm keeping the question open as even though Microsoft provides client-side settings persistence, it doesn't necessarily mean this is the best approach for persisting user preferences and I'd like to canvas more opinions and suggestions on this.
After investigating some more and implementing my own XML file-based settings persistence using IsolatedStorage, I discovered the IsolatedStorageSettings class and the IsolatedStorageSettings.ApplicationSettings object that is a key/value collection specifically for storing user-specific, application settings.
It all seems obvious now. Of course, in the long term, a mechanism for backing up and restoring settings using a server database would be a good enhancement to this client-side settings persistence.
I think in general the default would be to store on the server; only when there are specific compelling reasons to attempt to store on the client should we do so. The more you rely on storing in a medium you can't control, the more risk you take on.
That having been said, and setting myself on the "database" side of the argument, I would ask what the downside of a database is? You mentioned using XML - is your data only semi-structured? If so, why not store XML in a SQL database? Setting up something this simple would not generally be considered a "burden" by most standards. A simple web service could act as a go-between between your Silverlight client and the settings database.
If it is an important feature for you that users have access to their preferences while offline, then it looks like isolated storage is the way to go for you. If it's more important that users be able to save preferences even if they have turned off isolated storage (is this really a problem? I'd be tempted to call YAGNI on this, but I'm not terribly experienced with the Silverlight platform...) then you need to host a database. If both are important, then you're probably looking at some kind of hybrid solution; using isolated storage if available, then falling back to a database.
In other words, I think the needs of your application are more important than some abstract best practice.
Most CMS' have a way to create forms for users or anonymous users to fill out. Is there a mechanism for creating forms like this in Sitecore 6?
As far as I can tell, the only way to make forms like this would be to manually create them in a sub-layout (user control), and then add that sub-layout to a page. Does anyone know a better way?
It depends on who you want creating the forms.
If you want content authors or admins to be able to use a wysiwyg-like interface for creating and updating forms, then I would recommend using the Web Forms for Marketers Module that is available for Sitecore. While certainly not the panacea for allowing content authors to create forms, it is pretty robust and also very extensible.
However, if it will primarily be developers creating and maintaining the forms, then it will probably be easier for you to go with the sublayout approach.
To ctford's point, the Web Forms for Marketers Module does use it's own database for form data storage, not the typical Sitecore content databases. And you'd probably want to do something similar for your forms as well, rather than writing data back into Sitecore. But that will depend on your business requirements.
Your UserControl suggestion is the way I would do it.
Sitecore, like other CMSes (such as RedDot), has a disconnected publishing model. Content is populated in a separate editing environment before being pushed to a live environment.
Consequently, the live environment is read-only as far as the CMS is concerned. This disallows native form processing because Sitecore doesn't expect updates to be made to the live database. To store data from anonymous users you would need to create custom database tables outside the control of the CMS.
As far as I know, there is no forms API comparable to Drupal's.