Our little department has been working with WPF for a number of years now, there are only two of us, a designer and a programmer (me). We produce business applications for our company such as shipment tracking and the like.
We've recently began looking into a redesign of our company website and part of this has been a long running discussion on moving our desktop applications into web applications via the website, there are numerous reasons for this I wont go into.
Now the problem I'm having is actually wrapping my head around what HTML5 is and isn't I've spent long hours googling and finding mainly arguments for an against this and that, but i still lack a fundamental understanding of a few points, which I'm hoping to get cleared up.
1. Does HTML5 still need back-end code, such as PHP or ASP.NET?
This is a sticking point for me, our needs are pretty standard. We need to produce an application that can collect and display data from a database, it will need to do some data manipulation but nothing to heavy. Can HTML5 actually do this standalone? or is it still pretty much just the UI front-end?
2. HTML5 Applications - are they actually applications?
This is one that seems to give us the most confusion, different sources say different things on this subject, is HTML5 able of producing an actual application? or is it still just a website with an "app like" UI, much like what is achieved currently with JavaScript.
I'll answer the first point. HTML5 is just a markup language, it has nothing to do with getting data from database. If you want to create a dynamic html website, then you need to have some server engine to exchange data with UI. With ASP.NET server engine you can go different directions.
Have just pure HTML pages inside ASP.NET project (e.g. MVC, WebForms), and use services (like Web API/ServiceStack) to provide data. Typically you would use jQuery to get/post data to server and back.
Use ASP.NET MVC to create a html5 compliant page and exchange data with the server using controllers.
Use ASP.NET WebForms type of project. Here you would create aspx pages, which would contain only html markup (no server controls). In order to pass data from server to the view, you can use hidden fields here.
Related
I am currently a front end developer. I know HTML and CSS pretty well, I'm OK with jQuery and know some Vanilla JS. I have an idea for a website I want to create where I will be storing data for products (data that I will be grabbing from various websites around the web). It's basically a help me choose application where the user will go through some steps and be given some choices based on their selections. This site is nothing new, but it's more for learning purposes/portfolio work.
Most of my co-workers use ASP.NET and I've seen that you can setup a website like this using ASP.NET and the provided server controls along with C#, however, I want to take another route that allows me to do the same thing NOT using ASP.NET (C# is OK and preferred if that is possible) in that I can grab data, store data, and bind data to my page.
In addition to this, I would like to do this on the Mac.
Here's a list of things I have looked at:
MongoDB (I was really confused by the setup and didn't read anywhere that this would definitely be the solution).
AngularJS
EmberJS
BackboneJS
Several other JS frameworks
Ruby on Rails
Note about the above: Some of the above might be the solution, but I don't want to start spending time learning them only to realize a week in that this is not going to help me get to my goal.
If this post would be better suited for another stack site please let me know. Thank you.
To create a basic website with a persistence you'll need to deal with three parts the front-end (client), back-end (server) and the persistence (database). Of the things that you've listed Angular, Ember and Backbone are all front-end frameworks. They each have their own way of approaching the issue but they all work in the client facing part of the project so views, interaction and dispatching data to the backend. Rails is the only thing that you've listed that's a back-end framework, another option for the back-end if you're more familiar with JS might be Node and Express. Node allows you to build a server in JS and Express is one of the more popular Node frameworks. That section will be responsible for getting the calls for data and calls with data from the front-end and dispatching the appropriate response. Rails typically works with with a SQL database like MySQL or PostGres out of the box because Rails' active record is meant to work with SQL. Mongo is a NoSQL database and I think people are getting it working with Rails but I don't know that it's highly common. Mongo's shell is pretty much javascript and it stores data as JSON (not technically but close enough) so it's been a comfortable choice for JS developers learning back-end. Either Rails or Node can get a server up and running locally on your machine so you can work with the full architecture. So what it comes down to really is picking one of each from those sections and making them play nicely together. For your purposes I would think that the way to go would be either a basic Rails app (probably with MySQL) and using jQuery ajax calls to manage some calls from the front-end or building something with the so-called MEAN stack (Mongo, Express, Angular, Node) which is all JS and using Angulars built in http functionality to handle those calls. Hope this at least narrowed the field of research a bit. Really thats a pretty open question and there are a lot of options.
What is your webhosting site? I suggestPhpmyadmin Or Mysqldatabase You can create tables and strings where you can put the websites you wanna "grab" data from and put a little javascript in there to tell your website if blahblahnlah =blahblahblah then get id="website1"
Some clarifications:
At first, you need to distinguish between a server side language (used to program the functionality) and a database (used to store data).
C# is a language of the .net framework. Regarding websites, there's no C# without ASP.net.
There are two major groups for realizing back end solutions: PHP (market share ~ 40%) and ASP (~ 25%). PHP is a programming language, ASP.net incorporates several programming languages (mainly C# and VB.net).
Both worlds are able to connect to databases: For PHP, this is mainly MySQL, for ASP.net it is mostly Microsoft SQL server.
I've built several database driven web sites with ASP and I'm trying to migrate the basic functionality to an ASP.NET architecture.
I want to have each link in my navigation tree correspond to a different function that will step a user through various requests and provide sequential database driven responses and possible follow-up questions. I typically do this in ASP by using the query string to execute different parts of the code in an SSI file. Each link in my navigation tree basically calls a different SSI file.
In ASP.NET I think I have a pretty good handle on web form basics, data binding, site navigation tools and master pages, but I'm having trouble with the overall design picture.
Do I want to have each link redirecting the user to different pages? My understanding is that ASP.NET is much better at maintaining state information and so I shouldn't have to rely on the query string to keep passing values to an SSI file to do sequential parts of each task.
Should I be using BLL and DAL to do this and/or stored procedures and managed code? Or could I do this sort of thing more simply with ASP.NET web pages, as opposed to web forms?
Feedback that would include a reference article and/or web example would be greatly appreciated. Thanks!
You don't necessarily have to abandon your whole way of thinking and take up ASP.NET Web Forms.
I've been making sites with ASP.NET Web Forms since it came out in 2001. But I think ASP.NET MVC would be an easier transition for you. I mean, some things are more difficult in MVC than in Web Forms. But on the whole, MVC will promote more web friendly practices and it's what I prefer now.
For example, the whole idea of postbacks and viewstate in Web Forms certainly makes a lot of things easier. But they also have a problem of hurting SEO and breaking the back button. MVC doesn't rely on any of this and it's easier to refine the user experience with the way form posts, redirects, and URLs are handled.
I wrote an article awhile back comparing MVC vs Web Forms...
http://swortham.blogspot.com/2009/10/when-to-use-aspnet-web-forms-and-when.html
Based on what I'm seeing, it looks like you've got wizard-style navigation across multiple ASP pages, and you want to have wizard-style navigation in an ASP.NET (WebForms not MVC) site.
If I'm misunderstanding this, I'll gladly delete this answer.
I'd recommend the Wizard control, (Video demos available all over the place) which will provide such an interface in one page, reducing a lot of the complexity. there's no need to keep track of variables across pages - it's all in one page, and therefore always accessible.
Wizard pages do tend to have a LOT of code and markup, but the trade-off is that all of the wizard functionality is in one pace, not scattered across files, and it's inherently obvious what's happening at each step. With the multiple-file approach, a maintenance developer needs to trace which page posts to which page and spend more time understanding the design.
The article on MVC vs Web Forms was quite interesting, although after looking at a few training videos I got the impression that the coding is quite a bit different from ASP. (Most of the examples I also see involve C#, although I have seen a few with VB, which is preferred since I'm already learning a lot of new things in a short time.) Also, I wonder if MVC will let me use the validation tools, which will be quite necessary in a different aspect of this project that involves several different and quite long forms. Given that I've invested a fair amount of time in learning about ASP.NET, I'm wondering if I should just go the extra mile (or two) and learn how to create business objects (BLL) and a data layer (DAL).
I have been told that Microsoft OCS is a bit like Windows Messenger.
Can it be added to a web page by inserting and configuring some standard code so we end up with something like this:
I know there is an OCS API but I don’t want to spend days piecing an OCS app together from this.
I was hoping there would be a component that allows me to stick the whole app on a web page and configure it to operate correctly. I presume this is something that would take less than 2 days if it is possible. Can someone advise if this is about right for an experienced developer?
I understand the web page would need to be in an Intranet with Active Directory.
Sort of a yes and no answer, this... There is no simple way to embed the entire client in a web page, but you can embed the important stuff - a list of contacts with their presence, and the Click-to-Call functionality. This approach relies on the end users having Communicator, Office and IE installed.
See my answer about NameCtrl here. There's a bit of javascript and state tracking involved if you're displaying more than one contact, so 2 days feels about right.
It's worth bearing in mind that this will work if the web page itself determines which list of contacts to show. If the contact list instead needs to be pulled from the user's Communicator, this isn't supported for web pages (some parts of the Communicator API are marked as NotScriptable for security reasons). You'll need to use the Office Communicator Automation API, and create a .net COM Interop wrapper around it. I've detailed a workaround to that here (this example discusses Silverlight, but it should be the same for javascript). I'd give this another couple of days on top of the original 2.
It's also worth bearing in mind that this approach will work with OCS, and will continue to work if the customer upgrades to Lync Server 2010. If they are already on Lync Server 2010, then the simpler approach is to use the Silverlight controls. Probably only a day for this approach.
I think many of us used to face the same question: what's the best practice to port existing web forms App to MVC. The situation for me is that we'll support both web forms and MVC at the same time. It means, we create new features in MVC, while maintaining legacy pages in web forms, and they're all in a same project.
The point is: we want to keep the DRY (do not repeat yourself) principle and reduce duplicate code as much as possible. The ASPX page is not a problem as we only create new features in MVC, but there're still some shared components we want to re-use the both new / legacy pages:
Master page
UserControl
The question here is: Is that possible to create a common master page / usercontrol that could be used for both web forms and MVC? I know that ViewMasterPage inherits from MasterPage and ViewUserControl inherits from UserControl, so it's maybe OK to let both web forms and MVC ASPX page refer to the MVC version. I did some testing and found sometimes it generates errors during the rendering of usercontrols.
Any idea / experience you can share with me? Very appreciate to it.
Background:
This UI project has been created for years and there're 20+ people working on that. Before I start the common master page trial, there're about 50+ web forms pages and only one MVC page. We create new features on MVC, but the old pages keep remaining in web forms.
This situation will keep for a long time, probably because this's a business-driven company so new features are always in a higher priority. This means we need to support both at the same time.
There are several integration problems using ASP.NET MVC master page with web forms pages and user controls. Since the execution pipelines of the two frameworks are not exactly the same it is normal to have some problems.
One of the things I've faced is that web forms uses single interface pattern (it has one <form> tag with runat="server" on the page). In your master page or pages using it you'll have to create this tag yourself if you want to use server controls. Note that this will work for read-only controls. If you need post-back & event handling you'll probably face more problems with event handling and event validation.
Also one trick is to create html helpers that render existing controls to string. You can check this out for more info http://www.abadjimarinov.net/blog/2009/10/29/HowToRenderAspdotNETControlToString.xhtml This is also a partial solution as it will not work with most user controls.
It will be helpful to provide some code or error messages so I can give you more concrete answers. At this level I can only say that the two frameworks are compatible and you can integrate them but this will not be painless and will require some changes in the existing code.
Let me use an analogy
This will sound harsh but will make it easier for me to pass the idea across. Exaggeration helps sometimes because it emphasizes certain things that need to be understood.
Ok. We're using bicycles to get from A to B at the moment. We're considering buying a car but we want to make transition from one to the other as painful as possible. Consider the fact that we enhanced our bike so it uses custom pedals etc. Is it possible that we use these pedals and other enhancements with the new car we're considering?
Essentially it's possible. But without making a huge mess out of it it is definitely not advisable.
Suggested transition is to change pages one by one to use the new technology (new ones of course in the new technology) and not to introduce some MVC functionality to a webforms page. Either MVC or WebForms for a particular user process. Majority of non-UI code can be reused (business services, data access layer code, data/domain model when applicable). But if you're cramming all the code in your code-behinds... Well bad luck for you. If you haven't separated your code you will more or less be repeating code. Unfortunately that's not Asp.net MVC's fault. It's your bad design without SoC.
Don't combine/mix/blend two UI technologies if you're not suicidal. You can go from A->B using either bike or car, but not both at the same time. This means you can have WebForms part of your application and MVC part of it, but not likely on the same page. And this is only possible if you use Web applications not Web sites. Asp.net MVC can't work as a Web site (on demand partial per page compilation).
Re-usability related to my analogy
Bike and car are two UI technologies. What you do or the purpose of you taking the route from A->B is not important. That's business logic. If you're delivering newspapers that's not related to transport. So you can see that other layers can be reused.
Asp.net WebForms vs. MVC
Asp.net WebForms
Server-side controls (web/user) use the event pipeline execution model. Hence they (unless completely presentational nature) have server side events that some code subscribes to. Platform is completely state-full and everything executes in a manner that abstracts the HTTP completely away. Everything looks like you'd be running a desktop application.
Controls usually encapsulate presentation, code (as in server-side and client side script) and style (as in CSS). That's why it's a lot harder to have SoC using WebForms.
Asp.net MVC
This platforms is completely suited for the stateless nature of the HTTP protocol. Every request is completely stateless (unless you store some state data in persistent medium - Session, DB, etc.). There's nothing like an event model. It's basically just presentation of data/information that is able to transfer data to the server (either as GET, POST, DELETE, PUT...). Server side doesn't have any events. It's only able to read that data and act upon it. And return some result (HTML, Script, JSON, ...). No events. No state. No complex abstractions.
Asp.net MVC abstracts away some common scenarios that are related to data. Like automatic conversion to complex object instances and data validation. Everything else is gone.
Asp.net MVC using WebForms
In case you would like to use server-side controls in an MVC application you would be able to put them in your ASPX/ASCX, but they would only be used as pure presentation. You'd provide some data to render. And that's pretty much it. Postbacks wouldn't even work (unless you'd put a submit button on it), because there's no __doPostback client side functionality that would make a POST request to the server. So if there's any server side code that these controls have (even when they didn't initiate a postback) and are related to it's state-full lifetime after they've been loaded, you can say goodbye to them. More or less.
Other than that, you can read a lot about differences between Asp.net WebForms and Asp.net MVC on the internet.
Sharing MasterPages: see this thread.
User Controls:
This is one of the banes of my existence with MVC; in MVC2 and previous revs, there's no direct equivalent to webforms user controls. A sort-of workaround is creating HtmlHelpers - (effectively extension methods to the Html object available in views that return HTML), but that means you'll have to render your HTML in code. Teh suck.
With MVC3 and the Razor view engine, a new class of Html Helpers is available that provides most of the benefits of user controls, including the ability to place them in separate assemblies (and therefore can be used in multiple projects). I'll see if I can dig up an example link, but Scott Guthrie's blog had an example in one of his recent MVC3/Razor posts.
You can do a certain amount of integration between the 2, but you end up with something more complex & less satisfactory from either approach. A comprise in other words.
I've had this same problem in the past & server side includes worked for me. Old school I know & not something I'd generally recommend. But we don't work in an ideal world.
Background:
I am an intermediate web app developer working on the .Net Platform. Most of my work has been defined pretty well for me by my peers or superiors and I have no problem following instructions and getting the job done.
The task at hand:
I was recently asked by an old friend to redo his web app from scratch. His app is extremely antiquated and he is getting overwhelmed by it breaking all the time. The app in question is an inventory / CRM application and currently each customer requires a new install of the app (usually accomplished by deploying it on a different domain on the same server and pointing to a new database).
Currently if any client wants any modifications to the forms such as additional fields, new features, etc my friend goes in and manually adds those fields to the forms, scripts, database etc. As a result all installs of this application are unique. There is no one singular source repository and no one single version of this app. Generally new features are overtime rolled into the other sites, but still this is done on an individual site by site basis.
I will be approaching this on a very modular basis. Initially I will be coding a module that will query an external web service for some data, display and store it, and periodically update it automatically. The next module will likely be for storing and displaying inventory data. This way I want to over time duplicate the current feature set of his app 100% but do it incrementally.
The Million Dollar Questions
I want to make the app have user
configurable form fields. The user
should be able to go to an admin
page, create a new forms page of a
certain category, and then specify
what fields he wants in there. He
could say 'create a new text field
called Item # and make it a
requirement" and that will get
stored somewhere. All forms will be
dynamically rendered to screen based
on what the user has configured. Is
this a good way to go about the
problem of having no idea what a
customer could want in a form? and
thus be able to store and display
form data of any sort ? What sort of
design pattern should I follow here?
I am familiar with asp.net and
the .net framework in general and
have decent knowledge of javascript,
html, silverlight, jquery, c# etc
etc. I can work my way around web
apps in a good way, but I am not
sure what sort of framework or tech
I should use to accomplish this
task. Would ASP.net 3.5 webforms be
the way to go? or should I look into
ASP.NET MVC? Do I use jquery and ajax for
complete decoupling of frontend and
backend ? or will a normal asp.net
page with some spattering of ajax
thrown in working with a codebehind
be the order of the day?
Just looking for general advice before I start.
I am currently thinking of using ASP.NET 3.5 webforms, jquery for clientside animation, ui, manipulation and data validation, and sqlserver + a .net or wcf webservice for backend.
Your advice is much appreciated as always.
I've recently implemented a white-label ecommerce system for an insurance company that allowed each partner to choose their own set of input fields, screens, and order the flow of the application to suit their individual needs.
Although it wasn't rocket science, it added complexity and increased development time.
Consider the user configuration aspect very carefully In hindsight both my client and their clients in turn, would have been happy with a more rigid system.
As for the tech side of your question, I developed my project in VS2005, using asp.net webforms and webservices with a SQLserver back end, so the stack that you're looking at is definitely capable of delivering a working product. ASP.net MVC will almost certainly help as far as testability goes.
The biggest thing I would change now if I was going to start again would be to replace the intermediate webservices with message based services using nServiceBus, MassTransit or the like. While the webservices worked fine, message based communication should be quicker and more reliable.
Finally, before you start to code, make sure that you understand the current system's functionality inside and out. If the new system doesn't do something that the old system did, it will be pretty obvious to the end users straight away.