Will be starting a web app that will have to provide many different HTML forms for data entry, so I was wondering if there is a web framework out there that does this in a clever way. generally when you have forms you have many considerations like navigation, validation, etc. that are not handled very efficiently by he frameworks I've seen so far.
Has someone taken the pain out of forms?
Have you tried looking at Grails? It can take your domain classes and dynamically scaffold them into web forms and apply server-side validation. The default scaffolding provides navigation, pagination, validation, and all kinds of other -ations that are pretty good!
Here's a good tutorial.
Try Qcodo.com, It is written in PHP (but fully OOP). It manages both database layer with nice Form templating system.
I think forms are handled pretty cleverly in Ruby on Rails. And also in .Net. The latter goes pretty far in letting you reuse the database logic for validating data and also has "automatic" handling of security issues like XSS and XSRF.
Related
Let's suppose I was going to design a platform like Airbnb. They have a website as well as native apps on various mobile platforms.
I've been researching app design, and from what I've gathered, the most effective way to do this is to build an API for the back-end, like a REST API using something like node.js, and SQL or mongoDB. The font-end would then be developed natively on each platform which makes calls to the API endpoints to display and update data. This design sounds like it works great for mobile development, but what would be the best way to construct a website that uses the same API?
There are three approaches I can think of:
Use something completely client-side like AangularJS to create a single-page application front end which ties directly into the REST API back-end. This seems OK, but I don't really like the idea of a single-page application and would prefer a more traditional approach
Create a normal web application (in PHP, python, node.js, etc), but rather than tying the data to a typical back end like mySQL, it would basically act as an interface to the REST API. For example when you visit www.example.com/video/3 the server would then call the corresponding REST endpoint (ie api.example.com/video/3/show) and render the HTML for the user. This seems like kind of a messy approach, especially since most web frameworks are designed to work with a SQL backend.
Tie the web interface in directly in with the REST api. For example, The endpoint example.com/video/3/show can return both html or json depending on the HTTP headers. The advantage is that you can share most of your code, however the code would become more complex and you can't decouple your web interface from the API.
What is the best approach for this situation? Do you choose to completely decouple the web application from the REST API? If so, how do you elegantly interface between the two? Or do you choose to merge the REST API and web interface into one code base?
It's a usually a prefered way but one should have a good command of SPA.
Adds a redundant layer from performance perspective. You will basically make twice more requests all the time.
This might work with super simple UI, when it's just a matter of serializing your REST API result into different formats but I believe you want rich UI and going this way will be a nightmare from both implementation and maintainance perspective.
SUGGESTED SOLUTION:
Extract your core logic. Put it into a separate project/assembly and reuse it both in your REST API and UI. This way you will be able to reuse the business logic which is the same both for UI and REST API and keep the representation stuff separately which is different for UI and REST API.
Hope it helps!
Both the first and the second option seem reasonable to me, in the sense that there are certain advantages in decoupling the backend API from the clients (including your web site). For example, you could have dedicated teams per each project, if there's a bug on the web/api you'd only have to release that project, and not both.
Say you're going public with your API. If you're releasing a version that breaks backwards compatibility, with a decoupled web app you'd be able to detect that earlier (say staging environment, given you're developing both in-house). However, if they were tightly coupled they'd probably work just fine, and you'll find out you've broken the other clients only once you release in production.
I would say the first option is preferable one as a generic approach. SPA first load delay problem can be resolved with server side rendering technique.
For second option you will have to face scalability, cpu performance, user session(not on rest api of course because should be stateless), caching issues both on your rest api services and normal website node instances (maybe caching not in all the cases). In most of the cases this intermediate backend layer is just unnecessary, there is not any technical limitation for doing all the stuff in the recent versions of browsers.
The third option violates the separation of concerns, in your case presentational from data models/bussines logic.
I am looking at backbone for a project. I have many legacy services which are non-restful that I have no choice but to use them as is. I see that I have to override Backbone.Model.sync, parse and many other methods and handle the ajax service calls. I am not sure how the routing is going to work but I can see that there will be a lot of extra code to make that work. My question is: Is Backbone really recommended if I have to work with non-restful services? I don't find any examples or discussion anywhere online which talks about it.
Backbone's automatic understanding of REST conventions boils down to probably about 50 lines of code. If your back-end APIs are all odd and unique, yes, you'll need to write code to talk to them, but you'll need that no matter which framework you use because no framework is going to understand the unique weirdnesses of your back end services. If you feel good about the basic MVC with event bindings design of backbone, stick with it. That's the core of it. And it's a tiny core, that's why it's called backbone.
As per routing, that's really handled in the browser as a single page app and the browser URL routing and associated backbone router/view code is entirely separate from the API patterns and URLs that provide the back end services. The two can be utterly unrelated and that's fine. You'll still be able to define your own browser routing however you see fit.
I have an idea to add a edit-layer to website as a Plack middleware.
Explanation: let's say, we create a website, based on some framework and templates and CSS (requesting it like /some/page). Now we could create a middleware so that every request to pages starting with adm (like /adm/some/page) shows the same page, but adds a layer for content editing. So we could easily look and use the page as visitors do, but with double-click on block-level element we could modify or add content. So middleware should bind certain block-elements with certain events (double-click) and set handlers too (with some Javascript library).
For now it is just an idea and i have not seen such approach in any CMS. I am looking for hints and ideas and examples, how to start and implement such system. I hope, there is already done something like that.
You could do it, but I don't think you want to do this. My understanding is that Plack::Middleware's are supposed to be generic, and implementing a CMS as a plack middleware limits its re-usability, and its out of place, there is no inherent connection between a middleware and a CMS.
See these as examples Plack::Middleware::OAuth, Plack::Middleware::Debug, Plack::Middleware::iPhone, Plack::Middleware::Image::Scale, Plack::Middleware::HTMLMinify
It would be trivial to add a middleware filter to insert a form in your html based on /adm/ or /admin/ or whatever ... and mapping the url to the dispatch would highly depend on the underlying CMS model/view/controller framework, which is why frameworks such as Catalyst, Mojolicious and other already provide this feature
See http://advent.plackperl.org/2009/12/day-23-write-your-own-middleware.html
Basically, I think this is a job for a view/controller of your application, a plugin, not a wrapper for your application (middleware)
I know my explanation is lacking but hopefully you catch my drift
I'm in the middle of converting an existing app built on top of zend framework to work as a plugin within wordpress as opposed to the standalone application it currently is.
I've never really used zend so I've had to learn about it in order to know where to begin. I must say that at first I didn't think much of zend, but it's funny because the more I understand how it works the more I keep questioning why I'd want to remove dependency when it's a clearly well thought out framework. Then I'm reminded that it's because of wordpress.
Now I already know there are WP plugins to make zend play nice with WP. In fact I'm aleady using a zend framework plugin just to get the app functional within the WP admin area which is allowing me to review code, modify code, refresh the browser, review changes, debug code, again and again.
Anyway, I really don't have a specific question but instead I'm looking for advice from any zend masters out there to offer advice on how to best go about a task like this one.... so any comments, advice, examples or suggestions would be super.
One area I'm a little stuck on is converting parts of zend->db calls to work as wpdb calls instead... specifically the zend->db->select.... not sure what to do with that one.
Also on how to handle all the URL routing with automatic calls to "whatverAction" within thier respective controllers files.
Any help would be great! Thanks
You're probably facing an uphill battle trying to get some of the more major components of ZF to work in harmony with Wordpress. It sounds like you've got a full MVC app that you're trying to integrate into a second app that has very different architecture.
You probably want to think about which components handle which responsibilities. Wordpress has it's own routing and controller system that revolves around posts, pages and 'The Loop'. This is entirely different from Zend's Action Controllers and routing system.
It's possible you could write a WP hook to evaluate every incoming request and decide if it should be handled by WP or a ZF controller. However, it is doubtful you would be able to replace WP's routing system outright with ZF's or vice versa.
Same idea, where Zend_Db is concerned. There's nothing stopping you from using Zend_Db to access Wordpress's database, but trying to somehow convert or adapt Zend_db calls into wpdb calls sounds painful. If you have a large model layer, you probably want to hang on to it, and find a way to translate data from those models into the posts/pages conventions that Wordpress uses.
Personally, I would use ZF to build a robust business layer that can be queried through an object model via a Wordpress plugin, and then rely on Wordpress to do the routing and handle the views.
Zend_DB_Select is simple SQL query (but created using objects) that can be used like any other query. Just turn it into string. Ex.:
mysql_query((string)$zendDbSelectObject);
How would I model a system that needs to be able to provide content in a format that would be consumable by iphone, Android or web browser (or whatever). All a new consumer would have to do is build a UI with rules on how to handle the data. I'm thinking something RESTful returning JSON or something.
I'm really looking for suggestions on the kinds of things I'd need to learn in order to be able to implement a system on this scale.
As an ASP.NET MVC developer, would that be the best framework/archetectrue to go with?
Thanks
I think you're on the right track with REST returning JSON. This is a format that's consumable by pretty much any language on any platform.
As an ASP.NET MVC developer, you should have no problems making a web service that's RESTful and passes data via JSON.
iPhone, Android, and modern web browsers such as Firefox, Opera, Safari, Chrome, have excellent Javascript implementations, splendid CSS, and reasonable subsets of HTML5 -- but you can't use either fact if you also want to support Internet Explorer or other old browsers. Fortunately, Javascript frameworks such as jQuery and dojo can compensate in good part for such issues (I personally prefer dojo, but jquery's more popular, and the choice between two such good frameworks is more of a matter of taste -- plus, there are advantages with going for the popular choice, such as, you can probably get better support on SO;-).
For REST returning JSON, just about any decent server-side arrangement will be fine, so, you may as well stick with what you know best, in your case ASP.NET MVC (just as I'd stick with Python and Werkzeug on App Engine, and people with other server-side preferences would stick with theirs -- ain't gonna matter much;-). Client-side, pick one of the two most popular frameworks, Jquery and Dojo, and go with it -- both have good books if that's your favorite style of study, but also good online resources. (Less-popular frameworks surely have a lot going for them as well, but there are risks in getting far away from popular choices;-).
As a general/philosophical approach, Thin Server Architecture is well worth a look (except for one detail: they used to recommend XML rather than JSON -- dunno if they've seen the light since, but JSON's clearly the right approach so ignore any suggestion to the contrary;-).
I am working on a project now that has to do this very thing. While searching the net on this I found Aleem Bawany's article on how it could be done in ASP.Net MVC. I really like the fact that it uses an action filter to handle the response. I modified the code in his article to look at the extension of the request instead of the content type.
For example /products/1.xml would return the xml representation of the
product whose id is 1 from the database.
Also /products/1.json would return the json representation of the product whose id is 1 from the database.
And /products/1 would return the html representation of the product whose id is 1 from the database.
The nice thing about returning data this way is that it lets the consumer decide how they want to consume the data.