Ok so we have an upcoming development that will involve a level of off line processing of dynamic forms. Here's what we have to do:
Create a asp.net web application whereby users can download dynamic forms, fill them in then upload them to be published.
We also have a windows mobile application that will do something similar.
The forms will requires images to be selected for uploading when publishing.
Upon publishing the completed form certain server side validation needs to occur which may trigger additional work to be done i.e. send out emails or update a database etc.
From what I know of InfoPoint (which is next to nothing) it seems like it may be a nice fit. I know its quite highly tied to SharePoint (which again I know nothing about), but can it be used without a SharePoint instance?
Either way, I am just firstly looking for validation that InfoPath is a good fit for what I describe. If it is the I am also after some good online resources.
Thanks in advance, Chris.
I don't think that there is an InfoPath client for mobile devices. What you would want to do is use Forms Server (comes with SharePoint 2007 Enterprise edition) to render InfoPath forms as aspx to the mobile device.
Everything else you describe could be done with straight ASP.NET and the InfoPath client. The mobile piece sounds like it will require SharePoint (for rendering the InfoPath forms as aspx).
See this blog post on using Infopath forms on mobile devices: http://blogs.technet.com/vik/archive/2008/02/25/filling-out-infopath-forms-on-windows-mobile-devices.aspx
Also the Formotus solution may work for you: http://www.formotus.com/
Before delving into whether or not InfoPath (+ SharePoint) is the right solution, what's the reason for not using ASP.NET with which I assume you are familiar? While InfoPath + SharePoint is sexy and hot right now, the learning curve is very high.
Back to InfoPath, I don't believe InfoPath supports uploading files. At least not out of the box. So if having your users upload images is a requirement, I'll say infoPath is out. Apart from that, InfoPath, with the addition of SharePoint Forms Services and workflow, can be used to accomplish what you want. I just wonder what the cost would be versus using straight up ASP.NET.
Related
I have to develop a phone application on every platform so I thought of using phonegap. Seems pretty nice.
I have a web application coded in classic Asp and it's this webApplication that I need to strip down to be a phone app.
At first I thought it will be simple, my classic Asp render some html so phonegap is able to put it as an app.
But it's not that simple, because in my asp I have some code that is rendered server side, I've talked to some who tell me that some html could call the asp pages and this html could be used in phonegap. Don't think it's possible ...
Well if someone could help me here, maybe i've said something wrong in my little text don't hesitate to correct me :)
My solution (I think) : code some webServices in asp.net that will use the same database as my asp classic web application. And some html and jquery will call the webservices and those html and jquery will go trough phoneGap
What is the best way to transfer and asp classic web app to a multiplatform phone app ?
EDIT : After looking everywhere, effectively phonegap can't use asp pages. So I'm questionning myself should I do a mobile website or a mobile app with webservices?
EDIT 2: I'm going for an asp.net mobile website, someone have a great way to do this, I've seen the answer proposing mvc... more details?
You are on the correct path in wanting to use PhoneGap to create a multi-platform phone app via HTML5, and some mobile framework like jQuery Mobile.
Yes, you can leverage the power of ASP.NET to serve up your data but I wouldn't create an asmx web service. A SOAP-based service serving up XML may be too fat/overkill for your mobile web app. Instead, you may want to investigate using JSON which is more lightweight (remember, bandwidth is a concern with mobile apps). One can rapidly create an API to serve up your JSON data via the new ASP.NET Web API. With your API exposed, you can make an ajax call from your html page to retrieve the JSON and bind it using jQuery.
The bonus to using the ASP.NET Web API would be when it's time to upgrade that classic ASP web site you have there, you could leverage the API you already created.
I'd really consider rewriting the website using Mvc.Net. You may want to consider using the iUI for the views.
It will be much cheaper long-term to use modern technology than trying to shoe-horn legacy code into new usage areas.
It looks like you've made up your mind to go with a webapp instead of native apps via PhoneGap. I would recommend that you pick up this book by Jonathan Stark. It's very short - shorter than it should be when it gets into using PhoneGap - and although it focuses on iPhone development, much of the content is applicable to most mobile devices. The first few chapters give a great introduction on developing attractive, responsive, highly usable web apps for mobile devices. If you familiarize yourself with jQuery and jQTouch you can get some really great looking apps with relatively little effort, regardless of the server side technology you go with.
So i'm questionning myself should I do a mobile website or a mobile app with webservices ?
The answer to that question is always mobile website... given an outdated website that the client is wanting duplicate functionality in an app.
Do the work to convert the website or at least the portions that you need to use ajax and webservices. Once you have that in place pulling the same data to place in a mobile app will be easy... you've already done it once.
So my approach would be to convert this dataview into two separate elements Data and View.
You can probably even keep the current asp pages without a lot of modification to the code since you can still call these web-service functions the same way as before in your asp code.
Well, if you really want to reuse your existing webpage you can do the following.
Create a index.html and the body.onload event, redirect to your webpage.
Then build this index.html with phonegapbuild, and you will get your "native" application that simply loads your existing webpage.
If you want to serve mobile users, you have 2 main options:
Create a mobile website. You can render html on the server all you want, no javascript programming needed. Maybe look into jQuery mobile, it can be a cheap and easy way to make the website better for mobile users.
Create a html web app (and package it inside PhoneGap if you want). This is basically a html page which loads just the data from the server in json format and updates the page contents dynamically with javascript. You need good js skills to implement this, you're server is just a REST api that server json - technology can be anything, at least asp.net mvc makes it easy. On the client side you'll want to use some good structuring frameworks, backbone.js ( http://documentcloud.github.com/backbone/ ) is a good option. Check out http://m.linkedin.com for an example of what a mobile web app can be.
3rd hidden option: just create a native app for each platform, that'll get you the best user experience.
I want to implement rich reporting features in one of our asp.net mvc based web applications. The required features in the reports are
Graphs
Charts
Grouping, sub totals, page breaking, etc
Ability to export to excel, pdf, csv and other formats
Printing Support
We are ready to purchase commercial controls(if free ones are not available). Please suggest us the best of available options.
I do not know what rich reporting packages are out there that are 100% ASP.NET MVC-driven. I've seen a few talk about MVC.
But technically, you don't need an MVC-version of reporting controls. ASP.NET MVC allows you to use standard ASP.NET functions, such as WebForms, postbacks, server controls, etc. This is easy as a drop-in-place solution because ASP.NET MVC's default Convention-over-Configuration programming checks to see if a directory or file exists first, before being routed through the controller logic.
So, if there are no Asp.Net Mvc versions of graphs and charts you like - then fear not, you can fall back to the ones you've used for your previous asp.net forms projects. Even though I recommend sticking it into a dedicated directory (i.e. /reports) to keep a clean website.
I suggest you try and use a regular web form for the reports, with graphic, charts, and any other ontrol you might need. MVC views and web forms can live in the same project, noting wrong with that. At least until you find a way to do it using a MVC view.
In my own opinion, you don't have to do everything MVC in a project, you are "allowed" to do whatever you need to do to make your application work the way you want to.
You can use the asp.net chart control which is free to download and supported with ASP.net MVC
I found this while searching for something similar.
http://www.componentsource.com/products/syncfusion-essential-studio-aspnet-mvc/index-gbp.html
I haven't used it though. There is a trial download.
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.
Sorry, really newbie question, but if I was to create an ASP.NET website application, such as a calendar of events linked to a database - would the user interacting with this Calendar be using Active X?
Don't really know how to put that question any other way. Reason I ask is that my works system blocks Active X controls and therefore there would be no point in using ASP.NET to develop anything.
As a side question - What doesn't use Active X?
Thanks
ASP.NET is a server side technology and does not necessarily have anything to do with client side technologies such as ActiveX or anything else.
ASP.NET doesn't use ActiveX unless you make it do so, via interop.
There are many ASP.NET controls etc that will do what you want and use JavaScript etc rather than ActiveX. For really slick dynamic stuff MS are pushing Silverlight, which is their competitor to Flash in many ways.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?