I have a requirement to route between different pages in a mobile app (hybrid) based on the output from one page. The routing should be configurable, able to be updated independently of the App and ideally be able to edited visually.
Server-side this is handled by BPM Solutions (jBPM, IBM BPM, etc), however on the client-side I can't find anything suitable.
What I need is a JSON based set of rules that define which page to route to if a set of conditions are met. For example, if on page1 I have 2 fields: name and age and the User clicks Next then the rules might define that if age >= 21 then route to page2, however if age < 21 route to page3.
Is there any technology out there that currently does this? I've seen that there are Javscript Rules Engines such as Nools, but they aren't BPM-like enough. Please don't suggest writing it myself - that's already being seriously considered.
BPM isn't designed for "page flow". Most do include some sort of page flow technology for their own UIs, but I don't know of any that really promote that as a feature for building UIs in other technologies.
Fundamentally, what you are looking for is an MVC framework. You have your pages (views) and assumably you have your model already, but you are looking for a controller to link them together.
I'm aware of Cordova conceptually, but I don't have any hands-on experience so I don't feel comfortable making a flat out recommendation. I do know that Sencha Touch has some MVC functionality, and that it works fairly well with Cordova/PhoneGap, so that might be a direction for you to start in. Even if that doesn't work out for you, I can see that "Cordova MVC" and "PhoneGap MVC" provide several links and examples that seem very close to your use case.
Related
I recently added a roles/permission functionality to a somewhat old web forms app in ASP.NET and C#. Now I need two simple functions: add/edit roles, add/edit permissions to roles (permissions are in a table but not modifiable). The tables are somewhat like this (I need an interface for the bold ones):
Roles table: RoleID, RoleName
Permissions table: PermissionID, PermissionName
Roles_Permissions table: RoleID, PermissionID
How can I make them interactive, in the sense of not having a post-back, and having both functionalities in the same page? I visualize a dropdown for the Roles, that when one is chosen, the list of Permissions refreshes for that role, and right there the user can change the permissions, RoleName, or even add/delete a role. The page needs to use an existing master page to match its appearance to the rest of the web app; I do not know if that would limit functionality.
I need the implementation to be as non-intrusive as possible (no strange plugins, and work with current browsers without any configuration on the client side). I found breeze, knockout and angularjs, but can't find if/how I can add the functionality to an ASP.NET C# Web Forms in Visual Studio 2012 (version 11).
What is the fastest/easiest way to build the page, that will be easily maintainable in the future, and be a good starting point to begin "modernizing" the rest of the web app based on it?
You can add a standard blank aspx page to your application and get it working as normal for a Web Forms application. Wire up the navigation, make sure that it picks up your master page (if you are using one), etc.
From here, depending on various circumstances, you can do a couple of things.
ASP.NET AJAX
This was originally introduced for ASP.NET Web Forms, and uses Web Forms controls and a small amount of work in the codebehind to glue everything together. It's less flexible than other solutions, but should be fine for the scenario you cite. This would be the preferred method if you are more comfortable with Web Forms than other programming models. Policies or the structure of the existing application may also make this more preferable.
Single Page Application
You mentioned frameworks such as breeze, knockout, and Angular. So, let's focus on those. Again, depending on your experience, and the app, these might be compelling options. I wouldn't go as far as Angular for the time being, since it's more appropriate for a full rewrite. It could work embedded in another application, but is probably too much work for the scope of your project.
At minimum you could make do with plain JavaScript and AJAX, but you'd need to write a lot of your own code. If you add in a little jQuery, that will help with DOM manipulation and AJAX calls to your services. I've had success in enhancing older apps with jQuery for DOM manipulation, and Knockout for databinding. You can probably make do without jQuery, but I wouldn't. These two libraries don't make any assumptions about the environment that you are using them in, and should be content to be constrained within the limited scope of a single page within a larger application.
I will start to develop a new Project and i want use Asp .NET core and angular.js but i have a question what is the better way, use asp.net and angular together or separately?
I defined my architecture in this form
Cliente1(Angular)->RestApi->BussinessLogic->DataAccess->DB
yes, i see that my architecture says me that i need manage asp .NET and angular js separately, but I'd like to hear any suggestions.
UPDATE:
thank you for your answers, in the end both they have their pros and cons, i would like to share with you this articles:
Together: http://proudmonkey.azurewebsites.net/asp-net-core-getting-started-with-angularjs-2/
separately:
Part one: https://chsakell.com/2016/06/23/rest-apis-using-asp-net-core-and-entity-framework-core/
Part two: chsakell.com/2016/06/27/angular-2-crud-modals-animations-pagination-datetimepicker/
In general in programming you should separate your logic the most you can.
You will want to separate both projects for so many reasons :
You have a web app right now (angular) but maybe in a near futur you will need to have a mobile app (hybrid or native)
You can be more than one person working on the project, for example you will maybe need some designer/integrator to work on the app, and you dont want to share with him your back end, same applies if you have a back end guy.
two projects means maybe two source control repositories, means more control on branches, versions, rolling back ...
etc ...
I hope this can help.
If I see other benefits, ill update this answer.
Keep them separate, your MVC Part will be mainly REST APIs which has nothing to do with the JavaScript, HTML and CSS in the Angular Project, besides, if you want to build another client, EX: Mobile, then it will have its own project as well, this way you will have a clean structure for your solution.
So, you should have the following:
YourProject.REST
YourProject.Angular
YourProject.MobileClient
Also, the separation will make it easier for the teams working on the project, the one who will work on the front end doesn't have to worry about any other code not related to his tasks, the same for the developer working on the APIs, and each project can be structured as per the best practices for its technology.
You question is opinion based more than facts, so here is my opinion.
I have done few projects with ASP.Net MVC, Web API and AngularJS. They all stay in a single Web Application Project. Note: I have few class libraries for strongly typed Angular Helpers, Business Logic and Data Access.
Here are the advantages
I authenticate user using Owin Middleware, then redirect to Angular. The main advantage is I do not have to maintain Bearer Token or Authentication Cookie explicit inside Angular.
Second, I use csthml as strongly typed Angular view rather than plain html. It is the best of both world.
Last but not least, you can debug it easily rather than starting two projects at the same time, so that I can save resources on development machine. Everyone know Visual Studio is a memory hungry IDE.
So I'm afraid I might be missing something pretty fundamental here, but I really can't get my head around this - Why? Why would we want to use those JS MVC frameworks, instead of sticking with Rails, Django, PHP and so on?
What do these JS frameworks give us that can't be achieved by the old web frameworks? I read about SPA, and there's nothing I couldn't do there with ASP.NET MVC, right?
I'm really baffled by hearing all the people at work wanting to leave our current framework for these new ones, and it's much more than just for the sake of learning something new.
I am totally up for that, and I've always tried playing around with other frameworks to see what I'm missing, but perhaps these new technologies have something really big to offer that I simply cannot see?
Single page applications provide a better experience by having all page transitions be seamless. This means you never see the "page flash" between user actions, in addition to a few other user experience improvements.
Front-end frameworks also generally provide a common way to interface with APIs. So instead of writing an AJAX wrapper for every page in your site, you just say 'This page has this route (path), hooks data with this schema from that API endpoint and presents it with these templates and helpers.' There are many proponents of APIs, because there are many good reason to write you applications from a service standpoint. This talk sums up a lot of the points in favor of APIs. To summarize:
Orchestrating your web offerings as services makes them inherently decoupled. This means they are easily changed out. All the reasons behind strong Object Oriented design principles apply equally to the larger parts of an application. Treat each piece as an independent part, like a car, and the whole platform is more robust and healthy. That way, a defect in the headlights doesn't cause the motor to blow up.
This is very similar to how a SOAP WSDL works, except you have the auto creation tools right out of the box.
Having well defined touch points for each part of your application makes it easier for others to interface with. This may not ever factor into your specific business, but a number of very successful web companies (Google/Yahoo, Amazon AWS) have created very lucrative markets on this principle. In this way, you can have multiple products supported by the same touch points, which cuts a lot of the work out of product development.
As other point out, the front end framework is not a replacement for the backend, server technologies. How could it be? While this may seem like a hindrance ("Great, now we have two products to support!"), it is actually a great boon. Now your front and back ends can be changed and version with much less concern over inadvertently breaking one or the other. As long as you stick to the contract, things will "Just WorkTM".
To answer your additional question in the comment, that is exactly correct. You use a front end framework for handling all the customer interaction and a completely separate back-end technology stack to support it.
I'm forgetting a few good ones...
Angular, Ember, and Backbone are client-side JavaScript frameworks. They could be used interchangeably with a Rails, Django, or PHP backend. These JavaScript MVCs are only responsible for organizing JavaScript code in the browser and don't really care how their data is handled or persisted server-side.
Django/Rails etc are server-side MVC frameworks. Angular/Backbone etc are client-side Javascript MVC frameworks. Django/Rails and Angular/Backbone work together - in a single-page app, usually the server-side MVC will serve the initial HTML/JS/static assets once, and then once that is done, the client-side router will take over and handle all subsequent navigations/interactions with your app.
The difference here lies in the concept of what a "single-page application" is. Think about how a "regular" web Django/Rails website works. A user enters your app, the backend fetches data and serves a page. A user clicks on a link, which triggers the server to serve a new page, which causes the entire page to reload. These traditional types of websites are basically stateless, except for things like cookies/sessions etc.
In contrast, a single-page application is a stateful Javascript application that runs in the browser and appears to act like a traditional webapp in that you can click on things and navigate around as usual, but the page never reloads, instead, specific DOM nodes have their contents refreshed according to the logic of your application. To achieve a pure Javascript client-side experience like this in a maintainable fashion really requires that you start organizing your Javascript code for the same reasons you do on the server - you have a router which takes a URL path and interacts with a controller that often contains the logic for showing/hiding views for a particular URL, you have a model which encapsulates your data (think of a model as roughly one "row" of a database result) which your views consume. And because it's Javascript there are events going on, so you can have your view listen for changes in it's associated model and automatically re-render itself when the data is updated.
Also keep in mind that you don't just have one view on the client side, there are usually many separate views that make up a page and these views are often nested, not only for organizational purposes but because we want the ability to only refresh the parts of the UI that need to be refreshed.
The intro to Backbone is probably a good starter on the topic: http://backbonejs.org/#introduction
Check this article, there is well explained how a modern web application should looks like in the client side, server side and the communication between them.
By the way:
Client side -> Ember, Angular, Backbone, Knockout.
Server side -> Django, Node, Rails
Ok this is a bit of a rant and a question combined - Why the hell is magento so reliant on javascript?? This goes agaisnt all usability guidelines. WHats so annoying is that it even uses buttons instead of correct form submit elements. Why? This makes no sense what sense at all to me.
Why is this and is there a way around it?
The past five years have seen an increase of web application developers eschewing the common wisdom of of the late 20th and early 21st century by creating applications and require javascript as a baseline technology. Magento is following this trend because they want to provide a moden, AJAX enabled experience, and providing both a Javascript and non-Javascript experience increases both development and testing time.
Most decisions in the e-commerce industry come down to the ROI of increased sales. Magento has calculated/bet/decided that sales lost due to people having Javascript off are less than the cost of developing both a javascript and non-javascript experience.
As for their use of the HTML button attribute, Magento isn't a web page, it's a web application. Their architecture takes a Java like approach, including a UI that's abstracted away from the browser. This means PHP is used to tame the browser rather than using PHP to work with the browser. In this context button elements (driven by Javascript) make more sense. Take a look at Google Web Tools for another example of this.
The way to "get around" this is to not use Magento, or to customize Magento such that it fits your model of what web development should be. If your first response to this is "woah, that would take way too much time", then congratulations, you're thinking exactly the same way that Magento is. Magento, the company, isn't Microsoft, or Oracle, or SAP. They're a 200 person company, and expecting them to solve all your problems (for free) isn't realistic.
Welcome to 2010.
Magento's JS reliance is unusable in exactly one way: you cannot use the store without it. That's a big one (losing 1/20 of your customers is not a small thing), but ultimately it's a tradeoff that they decided was worth it.
As an example of the flexibility that you get as a result of this decision, consider the case of configurable products, especially with pricing differences. Magento allows you to create products that are configurable over N axes, in a ragged manner (some color/size combinations of clothing can be missing, for example), with different pricing for every single option. Doing that without JS would be tough, doing it elegantly (which Magento has, for the most part), is nigh impossible. By enforcing JS, the developers at Magento, Inc can spend their time implementing these kinds of features more quickly, which is to everyone's benefit.
To answer the question at the end of your post, no you cannot get by without it -- at least without writing a new frontend theme that reimplements everything from scratch, which nobody so far seems to have been able to do. Personally, the number of JS libraries that Magento uses seems pretty heinous to me, but nobody seems to have solved that problem either. The app is too complex and tightly woven to unwind that far.
Sorry it's not better news, but I hope that at least clarifies some of the thinking for the way things are.
Thanks,
Joe
"Why is this and is there a way around it?"
Although the front end uses Javascript heavily it is only essential in a couple of places. Configurable products is one. The one-page checkout is another but that at least can be disabled in System > Configuration > Checkout > Checkout Options.
Buttons with event handlers can be rewritten as a matter of theming, in some cases their destination URL is not the same as their form submission so a little forethought is required. In some cases buttons are not in the form element they are submitting, that is why they use script.
I will assume when considering accessibility you are not concerned about luxuries like image zoom and search suggestions. I notice HTML5 provides the datalist element for input suggestions but some sort of script would still be needed to update it beyond the initial suggestion.
Overall Magento is quite functional without Javascript, just not as out-of-the-box. An 'accessible' theme would make a valid extension should someone want to develop it.
We've just been looking into this when I came across this post (first time we've used the magento platform and our first project with it).
Typically we'd ensure that every site we develop degrades gracefully without javascript, but this is looking like it might be too much work for us on this particular project at least for the first phase (tight deadline alongside steep learning curve).
While I agree that javascript can offer some great usability enhancements, providing a non-javascript fallback isn't just about supporting the odd akward person who insists on turning it off.
Some users using disabled access devices (screen readers etc) as far as I know, might not have the option to use javascript either (or may find javascript interfaces more troublesome to use if not impossible in some cases). In these cases if it doesn't degrade gracefully for them, then I'm a bit concerned that it may conflict with disability discrimination legislation in the UK/EU (where our client operates).
For this reason, I'm not sure we can take the position the magento developers have in the long run (we'll probably end up backtracking and resolving this ourselves ultimately and I'm guessing that will take us longer than if it degraded gracefully from the start and we could simply build upon that).
The admin area is less of an issue, but the front end should work without javascript imho and I was a bit surprised when I discovered that it didn't work without it (the client came to us specifying magento so there isn't much we can do but run with it at the moment).
I think you'll find that the Javascript in most cases significantly enhances the usability. Trying to implement something like the Manage Products grid, Manage Categories tree or Promotions editor without Javascript would be a usability nightmare. When you look at the stats, well over 95% of browsers have Javascript enabled, so what's the problem?
Try using this site with java-script disabled. It works but start counting the post backs and you will see why usability trumps the few folks who insist on disabling java-script.
We have a few dozen web apps on multiple servers/platforms owned by 5 teams at our company and want to merge them into a single site. The UI part is straightforward - a common header with login/status info, tabs for the major sections of the site, and yui menus for navigation within a section.
The hard part is finding a way to do this while making minimal changes to the existing apps, which are easily breakable and a pain to deploy. We want to minimize updates to the apps and try to get it right the first time.
The only working solution we have now is to include a Javascript file to write the site header/navigation at the top of the page, which lets us easily deploy changes to all of the apps:
script src="..../site/include?appid=xxx" // app id determines which tab/navigation to display
Is there a better way to do this, especially one with better performance than remote dynamic Javascript that writes the entire page header? Are there existing frameworks to simplify this?
Consider using a portal framework like uPortal. You could aggregate all those webapps -- no matter what technologies they're written in -- by leveraging a web proxy solution.
This suggestion might be overkill if your needs are really & truly simple; but uPortal (and others) provide scores of additional functions -- like administration, statistics, SSO, and integrations with other platforms and services -- that quickly add to their attractiveness.