I'm fairly new to DNN. I need to spin up dozens of similarly skinned sites, all of which have to eventually call a web service that will allow users to submit information.
I want to find a module that will let me point it at said web service, then let me define the workflow (e.g. fill it out over multiple pages?) and select the controls (textbox, checkbox) to fill out a message to post to that web service.
I've seen things like Dynamic Forms and Enterprise Forms, but I cannot find any information as to whether this is possible.
Anyone know of a module or optional idea that will allow me to do this? Am I making something like this up? An absence of answers makes me think "I'll just build it..."
My experience with DNN modules is that they're rarely an exact fit for a particular technical issue. So I'd try the following
1) Email the people behind the tools you mention
2) Buy them anyway, with source, and learn the architecture of a well structured DNN addin - the time saved with more than repay the cost
3) Make your decision based on that knowledge.
Joshua,
I am not aware of any forms modules out there at this time that integrate to a web service.
However, you might want to look at potentially extending an existing module, and simply changing the persistance mechanism for it, rather than a whole custom solution.
Related
Background
While this is not a theoretical question, I would like to ask for suggestions on how to best approach the modularization of features of a mobile app.
If it helps, I usually use Ionic for mobile app development, so it would be great if the best practices would work with Ionic, but any general recommendation and suggestions would be very much appreciated.
Ionic is a cross-platform mobile app development framework that supports creating Android and iOS apps using Angular / TypeScript.
Problem
Let us assume we have an application that lets users register for an account. Upon registration, this application will offer various services to the user, a really wide variety. Let's say the user can receive notifications (both in-app pages and push notifications), receive discount coupons (either from coupons given by the admin using a management dashboard, or via doing things such as achieving a certain amount of steps recorded by the app as a pedometer, etc), and various other features.
Having so many features in an app will make it huge indeed, and since as a software development company, we would like to tailor the app so that it can provide what a client needs, and not provide the other things.
The problem in short becomes something like:
What is the best way to separate the different features of an app, make it modular and non-dependent on each-other so that some features can be easily disabled and the others enabled?
Is there a way so that the disabled features are not included at all in the resulting compiled app?
My own idea
The most logical way I can think of right now is to have a core app that includes all features. The features are enabled (shown in the app menu bar) by configuring the app's build environment file; for example, setting coupons: false, would cause all coupon-related feature to not get enabled most probably by using if statements and ngIf directives around the app. This core app will have all features enabled by default, but once a client requests for a specific app configuration, a new Git branch will be created from the latest branch, configured to the client's needs, and remain as a separate branch (or project).
However, my boss has complained that "that solution sounds like it's coming from the year 2010, there has to be another way," and unfortunately, I can't think of anything better than this. There will definitely also be design changes (like logos, color themes, and layout changes and font size changes) that can never be customized just by changing flags on a build environment file (is there? Maybe I'm the one who doesn't know.) so I don't know how to support those by using something 'better than Git'.
Conclusion
Modularization of an app by implementing various features as modules so that they can easily be enabled or disabled upon client request is probably feasible in some way, but I'm not sure if there is something better than Git in order to facilitate the management of different versions. My boss seems to be expecting it to be as easy as the flick of a switch (and enabling/disabling features can probably be made to be this easy), but attending to the unique needs of the client (text, design, layout, etc differences) is quite hard to do as easily.
I would be really thankful for any suggestions, or ideas on how to approach this scenario.
Thank you very much!
I'm trying to develop a hybrid app which will deliver a range of simple teaching material to the user. I am planning on using Telerik App Builder in conjunction with Cordoba 3 to create the app. What I cannot decide is how best to package the actual content into the application. I'd like to achieve a separation of the content from the code, and just combine the two when building the delivery packages. (The content is being prepared by a subject matter expert.)
Is there a way I can use Cordova or Telerik AppBuilder to pre-populate a SQLite database as part of the app install process? Or am going about this in completely the wrong way? I have been researching this in the Telerik documentation but without success so far. If someone could point me towards a suitable example or even the correct places in the Telerik or Cordova docs I'd be very grateful!
I recently ran a techie webinar on the topic. The main idea is that you need a centralized system to host this content and this system needs to expose some kind of a service layer that will feed content to your app. To me this seems like a very growing market opportunity, but feels kinda the same as the web 1.0 days where all of us were trying to figure out how to feed cotnent to websites and everybody was building their own CMS in a way.
Telerik Backend Services provides an editing interface, so it can fit some requirements, but it's not a publishing system, plus you may not want to pay developer licenses to your back-end users or provide them with access. The premise of the webinar I am talking about was that we discussed how to integrate with another telerik product - Sitefinity to do this job for you instead. The first 20-25 minutes are an overview of the platfrom, so if you have seen it already, you can certainly jump to ~;0:25 to see the rest
http://www.sitefinity.com/campaigns/webinars/build-content-driven-mobile-apps
Now certainly it doesn't have to be Sitefinity or CMS for that matter, Sitefinity provides a bunch of App Builder related features that are handy, but you technically have a few options:
- Build your own applicaiton and back-end.
- Use any type of CMS or platform that will give your SMEs the back-end interface to publish and the service layer to expose to the app. In the webinar I also go through some neat tricks such as using push notifications upon publishing.
This way you get a clear separation of content and code - you can even get a separation of content structure and code, which is an idea i talk about in greater detail.
I hope this helps!
Svetla
I posted a question on the Drupal forum about whether I should build my database in Drupal using content-types or the database abstraction layer and schema module: [here][1]
Any advice would be greatly appreciated.
[1]: https://drupal.stackexchange.com/questions/98020/should-i-use-content-types-or-database-abstraction-layer
I'd recommend using content types.
For a PHP coder, sometimes using the Drupal User Interface to build things feels non-intuitive, but in the long run you're going to benefit a lot from doing things "the drupal way.
Once you reverse engineer your need into a content type and all it's associated fields, install the modules that provide those field types and set things up, you'll start to see the benefits.
Validation on all the data-entry froms will already be done for you.
Multiple display modes are available for your data (email addresses can be shown with or without mailto: links, images can be shown using any of Drupal's image styles)
Integration with other Drupal modules already exists, and will be supported (almost anything built with fields is available to views)
By writing your own schema you'll need to handle all these things yourself (and more), and not just once, but you'll need to maintain all that custom code over time.
Learn to leverage the community and all the great work that's been done already, you'll save yourself time in the long run :)
What i see you are going to have shop site.
You may tray this:
https://drupal.org/project/commerce_kickstart
, i've found it usefull once. It's drupal distribution with nice themed shop rady to use straight forward.
And of course do it with content type + views + entity reference modules.
Here is a link to a comment that answers the question I asked. It backs up what arpitr outlined in their answer on the orignal post on the drupal forum, whose answer is also in agreement with jenlampton's suggestion above.
https://drupal.org/comment/7848011#comment-7848011
I will implement my system using node entities until the need arises to build a custom entity (if it ever does).
The top answer in this forum give a good way to evaluate whether to use nodes or custom build an entity:
https://drupal.stackexchange.com/questions/22586/when-is-it-appropriate-to-create-an-entity-versus-just-adding-a-new-content-type
First I'd like to make it clear, I'm not looking for a "my tech is better than yours" type of post; this is a real case scenario and I have been faced with this decision. With this in mind, let me explain:
We have a WinForms application. It started in the early .NET 1.0 but the first shipping version was using .NET 1.1. There are layers (like BusinessLayer.dll, Datalayer.dll, Framework.DLL, etc.) but at some point during the "long" development cycle of this application, the "presentation" layer (Win Forms) got infected with some code, thus the "separation between the code and the presentation with code behind" is some sort of myth.
Bad practices or whatever, the truth is that the application is there and it works.
Years passed and we had .NET 2.0, we slowly migrated and it mostly worked, had to change a few calls here and there. Last version did the same thing, but for .NET 3.5sp1. We needed some sort of Webservices thing, and decided to use WCF instead. It works fine.
But despite all these .NET upgrades, most of the application's codebase is still the same old rock and roll from 5 years ago. We use Gentle.NET (old and unmaintained now) for our dataobjects (it was a blessing 5 years ago!).
Our presentation layer, the winforms, are "nice looking" since we employ 90% of completely gdi+ custom controls. (whenever possible without having to hack the WinAPi). The application is touch based (i.e.: it makes use of the Ink but it doesn't rely on that), but the buttons, labels, etc, everything is "designed" to be used with a tactile device. (TabletPC or Touchscreen). Of course some users use keyboard/mouse.
With all that in mind, and with all this web2.0 and Internet fuzz (plus Jeff's posts ;) ), we are considering the possibility of rewriting the application but using a web technology.
The idea is obviously bringing more availability for our customers (they can use the system whenever/wherever they want), and less maintenance (we can upgrade and it is an instant upgrade for 'em all), etc. You know, the usual Internet vs WinApp thingy.
The problem is that given that this is the healthcare industry, not all of our customers might be willing to "move" their databases to our server/s, which is acceptable, and would force us to install a webserver/database server in their own servers so they have their own copy. Not a big problem (except we would have to update those manually but that's not an issue, given that we've been updating win32 apps for 5 years now!).
Now, back to the main "question".
The team has little Asp.NET experience, we did program a lot in ASP 2.0 (in 1999/2000) but that was a spaghetti of HTML+VBScript+CSS, so I don't think it counts. After all that experience (the Internet bubble!) we went back to VB6 then C#.NET 1x and you know the rest of the story. We're a small team of C# developers for WinForms. We've acquired some Linq To SQL Experience in our last .NET 3.5 ride, and we liked it. We felt it very natural and very "if we would have had this five years ago…" like.
Given all this, rewriting the application is not a "simple task" (not even if we wanted to do it in the already known C#.NET), it would take time and planning, but we could correct dozens of mistakes and with 5 years of experience working with the application, we now can say that we have a better idea of how the customers would like to use the software and what limitations we created (by ourselves) when we designed the current app.
All that "knowledge" of the application and the way the business works, could be applied to produce a much better application in terms of design and code and usability. Remember in .NET 1.1 we didn't even have generics! ;) (you'll see lots of ArrayList's hanging around here).
As an additional note, we use Crystal Reports (and, as usual, we hate it). We don't think the ink control is a "must" either. The HTML/CSS could be shaped to look the way we want it, although we're aware that HTML is not WinForms (and hence some things cannot be reproduced).
Do you think that planning this in MVC (or WebForms) would be too crazy?
I like the MVC (ruby on rails like) idea (I've never programmed in ruby beyond the basics of the book), so no one in our team is an expert, but we can always learn and read. It mustn't be "rocket science", must it?
I know that this whole question might be a little bit subjective, but would you replace an aging Winforms application with a new ASP/MVC/XXX web application? Do you have experience or have tried (and had success or failed) ?
Any insight in helping use better decide what to do will be appreciated.
Thanks in advance!
UPDATE: Thanks to all who responded, we'll evaluate whether this is a good move or not, it sure is a hell of work, but I am afraid the the desktop app is getting older (using old net 1.1 hacks) and tho it has been more or less working without problems in Vista and W7, I'm afraid a future update may break it.
Also, lots of "more or less core" parts of the application are exposing some badly designed ideas and we had to hack here and there to accomplish certain tasks. Part inexperience, part lack of 100% knowledge of how the business worked (and Customers not sure what they wanted).
A new application (in any form) would allow us to create a better foundation while retaining all the user knowledge.
But, it's a L O T of work :) So we'll consider all these options here.
As some of you have mentioned, maybe a thinner client and some (ab)use of WCF here and there might be more appropriate.
Once again, thanks to all!
It would be best to ditch all your efforts of reusing the desktop application code when you recreate the web app. Following are the reasons:
Web apps especially asp.net use a different model. For starters note http is stateless. Each time the browser talks to server you have to explicitly send the current content of all the controls on the current page. You would not have used such a model in your Windows application.
To decrease load on the network you want to optimize the size of viewstate and how frequent you make http requests. Again your existing window app does not have any such provisions.
Updating view. You might have different event handlers, threads and what not in your windows application to update the GUI in different scenarios. All of that will need to be replaced. Javascript is a totally different animal.
Security. When using a browser your access to the local disk is highly limited whereas you will take the same for granted in windows application. If there is any code in the windows app that requires local resources, then that is going to be a trouble spot for you.
I would recommend the following:
Verify if your current application has any local disk access requirements (e.g. read/write to local file etc).
As you write the different http modules or handlers, you can try leveraging some of the backend/ business logic part of the existing windows application.
Give some thought to what part of your application can become a web service.
It sounds like the application needs a lot of refactoring to clean it up. If you want to move to a web model, and have maximum reuse you will really need to do that. Before you move to a web model I think you need to understand if it will be possible to replicate your user interface in that model. Is it your unique selling point from a customer perspective? You want decisions like this to be user driven rather than purely technical decisions.
It sounds like your application is the perfect candidate for a thick client application, rather than the lowest common denominator web model.
Some things to consider:
How will the web interface impact the Tablet interaction?
What new customers will having a web version bring you?
Will existing customers abandon your product?
Do you have access to consultants or outside resource with the right skills to mentor you in web technology? If you don't you can rely on StackOverflow or other web resources to help. You need some good mentoring and guidance on the ground with you.
What happens if you start this effort and it takes much longer than you expect? You know the app but don't sound like you know the web. Past experience shows that massive rewrites like this can end in disaster (it never sounds so difficult at the start)
Can you possibly write new features in a web-based version?
Could you move to ClickOnce deployment to make the application easier to deploy to customers. One of the benefits of the web is easier (zero) deployment. Can you get closer to that?
Would it be easier to migrate to WPF and create a browser application with that?
Silverlight or Flex might be better options for creating a rich experience, and may be more approachable for WinForms developers. Is this a possibility?
It seems like your app. is one of those that works best as a desktop app. Though you want your users to be able to access your app. using a browser.
I would suggest refactoring as much as possible so that the GUI gets cleaner and don't have "code".
When you've done this, start developing a asp.net mvc app but keep your desktop app. You should be able to use all layers except the UI layer, making it easier/faster/... Now that mvc exists, I'd say webforms is more about letting non-web devs do web. But you know web, sort of, and you want control so mvc is the way to go.
i have played around with dynamic data website. is there something similar for winforms.
if there isn't anything out there for doing the same with winforms than the question would be why not? we have a massive ERP application that we want to migrate from AS400 to .Net
Winform application. my initial thoughts were to have all the maintenances be as simple as Dynamic Data Website project.
I would think that WPF would be a better starting point then WinForms, as it has support for style to say how item of data are displayed.
Dynamic Data makes it easy to edit your DB on the web. For desktop (and web) apps take a look at the new Microsoft LightSwitch:
http://msdn.microsoft.com/en-us/lightswitch/gg441300
LightSwitch doesn't use Windows Forms. Rather it creates a Silverlight App that can run both on the desktop and the web. Pretty cool.
Dynamic data is using the routing functionality of the MVC framework. In Windows forms we don't have this approach of fetching data with URLs from a server.
I am not sure how this model could fit into Windows forms.
I think it's pretty hard to create something like dynamic data for Windows Forms.
My biggest concern is here, once you created that Framework, how do you configure it? I mean if you want to change 1 form to be a bit different than the others :-)
I think its better to generate Forms for the various tables in the Database context, using a powerful Grid control from one of the big vendors. And then you can configure those.
Remember this is a different approach then the dynamic data one, where no code is generated before compile time
I think the reason you don't see something like this in winform applications is because it's much easier to store a HTML page inside a database and then display it on the screen formatted properly when using a web application because your browser knows how to format the HTML.
You would have to, stored in the database, know where each label and field would go on the form in some sort of co-ordinates fashion (or you could use a layout 3rd party control) but the amount of work that would take might be tedious to do properly.
The dynamic data website I worked on did not take input from the user. It only displayed different web pages to the user and allowed the admin person to easily make changes to the content. If you wanted a user to beable to save data then that would even be more complex because you have to worry about validation, required fields, etc.
If you have lots of users that need to see different information based on their access level then I would just suggest having a table in the database that tells the system whether or not they should see the field on the form. Then use a 3rd party layout panel to format the visible fields.
my 2 cents
As much as Dynamic Data looks simple and cheap enough to access a database it wouldn't work for an ERP system anyways. Business systems are more than moving data between database and the user interface, they require business rule actions when saving data and while retrieving the may require some massaging to ensure meaningful presentation of storage optimized data.
If you still like to pursue this option it would be very easy to create an application that is build on top of Entity Framework.
I'm not aware of a Dynamic-Data-alike, but (having written one before, years ago, for ASP) I don't actually think it would be that hard, particularly with WPF and its templating support.
Actually if you were really clever you could probably 'borrow' the backend from Dynamic Data, and just reimplement the UI as WPF.
Would make a fun little project actually.
Alternative answer: Use Microsoft Access. No really.
Alternative answer #2: So why not just use Dynamic Data then?