What is a good approach to building a web interface for updating xml documents in a marklogic database.
I came across roxy, which is a ruby gem for configuring and deploying marklogic applications, but after playing around with for a while it seemed that it was more helpful for querying and displaying data rather than updating documents.
Roxy is also a framework that allows you to:
- use/extend MarkLogic's REST API
- use Roxy's REST API - with CRUD rewrite rules in place for you to map to your controllers
- The mVCframework itself is also neatly organized and not overly complicated. We use it quite a bit.
So, if you do CRUD via MarkLogic's REST api or Roxy or any other, none of these actually give you a frontend of their own.
Our usual formula is a 2-tier solution using Roxy within the MarkLogic app server that also serves the front-end code written in AngularJS. Then everything is managed under Roxy nicely.
If you are interested in samplle 3-tier apps with CRUD support, have a look at github and search for samplestack. It's a set of reference frameworks for MarkLogic. It's for MarkLogic 8, but it may give you some ideas..
The MarkLogic REST API is a good place to start. That gives you a lot of control over the documents, including the ability to update them, while working with the language of your choice.
With Marklogic 8 you can use the new Node.js client + e.g. Express (a small web framework). If you like mainstream development, this seems the best way now.
Related
My website is up and running with support from Wix.com, I used the drag and drop builder to set it up and I didn't need to do any Client side/Server side programming for it to work.
What should I do if I want to keep the app updated with the website as soon as I upload any article/post on the website.
Consider taking a different approach and migrate to a platform/architecture that better suits your specific case.
My suggestion would be Microweber - it's a pretty advanced platform for websites with CMS and e-commerce features. It's been around for quite some time (3 years or so) and I'm using it for about 12 live active projects.
It's very neat if you plan to write custom code as it's based on Laravel and everything is easily extendable.
However, I'm using it mainly because of the support. Although it's free and open-source the team is online most of the time and have replied to my every request so far.
This is critical for me as many website solutions come and go and none is
perfect. What makes this one better is the reaction time and adequacy.
This is my personal opinion with regard to the fact that it's very hard to pick one solution among so many given that you didn't state more specific requirements.
It cannot be done without any server side scripting and backend database for the mobile app. you need to develop database for it.and then you will need to develop web service for the passing the data between mobile and backend.
A dirty way to do this would be through an HTTP request that reads HTML. However the best way would be through Wix's REST API.
Edit: I'm regards to keeping the app updated, you're going to need a backend service that is consistently checking for updates.
Instead of using server side MVC like Ruby, Python, PHP to build very complex websites, why should not we split our website into multiple modules, and build each with client side MVC like backboneJS, EmberJS. In this case, we will use PHP / Ruby for creating webservices alone, which will serve data only.
Each module now act as small web app. If we link each other, they will perfectly look like a complex web app.
I visit many websites (like github, groupon, stackoverflow etc...) and they can be built or adopted to this approach. But i am not seeing this kind of approach. Does this approach has any problem on this kind of websites?
Was to long for a comment
I guess the tricky part is indeed the point you mentioned
f we link each other, they will perfectly look like a complex web app.
Because each MVC framework uses a different approach to tackle usual problems you have in modern web-apps, like routing, data binding, application state and rendering DOM elements, so I think you would end up having multiple frameworks doing tasks that overlap substantially, thus forcing you to deactivate or disable some of the built-in functionality of one or the other framework making your frankenstein-app :) very difficult to maintain.
A good example is jQuery-mobile & ember.js, both have a routing system, jQuery uses the DOM to hold state ember.js holds it's state completely in javascript which is much faster. I had a similar problem with a project using jQuery-mobile & ember.js and this forced me to decide for one of the routing systems, I took ember's and deactivated jQuery's wich then let with just a bunch of custom mobile-looking components on the side of jQuery-mobile. Finally I removed jQuery-mobile using ember.js only and CSS for the mobile-looking app.
If not because of a concrete requirement, IMHO your best bet is to have just one very good, flexible and opinionated framework (personally I prefer ember.js) and create the modules you mentioned with your only choice.
Hope it helps.
As of now we can say that most of the applications are forced to put in more effort in its UI/UX and hence the dependancy on server side is becoming very less.
I have personally used backbone for my latest work and this has been great. The speed of the entire application can be noticed from the beginning. Ive been using PHP for the past 3 years and i can definitely vouch that backbone and other MV* frameworks are better.
Combined with CSS frameworks such as bootstrap, backbone can be an extremely organised and elegant applications.
All said, getting your head around models,views,routers,collections can be a headache. This is something which has vast possibilities and its only getting started.
Ive compiled a tutorial based on lots of tutorials present and has published at http://goo.gl/nJumC.
So many video tutorials are also available.
Only per-requisite is that one should have good knowledge of javascript and jquery methods and functions. Beginner knowledge in these will only make your task of learning backbone difficult.
Oh yes. I got my answer.
From google groups:
I think one of the reasons is javascriptless user-agents — i.e. search
engine crawlers and users with NoScript turned on.
I hope, these are real problems why websites still using Server Side MVCs.
When websites don't know target audience, they can't predict how well it will run on client side. So they should rely server to build much of their content.
And think, if stackoverflow was designed using client side MVC's to build much thier content, no one can't reach stackoverflow posts using google search.
From wikipedia under "Search engine optimization" section:
Because of the lack of JavaScript execution on crawlers of all popular
Web search engines, SEO has historically presented a problem for
public facing websites wishing to adopt the SPA model.
I think that is the shift we are heading now; I am not really sure about you but I noticed far more Client Side MVC Web sites. Anyways, you can also take a look at this ....
http://backbonejs.org/#examples
in my view, except the learning curve, it is pretty neat to develop using Client MVC and Web APIs using JSON/REST
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
I'm looking at building a simple login-based iOS application that needs secure access to create, read, updated and delete data from a MySQL database - with certain actions available to specific users based on roles.
I've done some research and it looks like I need to build a RESTful Web service which provides Web Services which the iPhone app calls to access the data.
I have very little experience of web services development, are there any books/tutorials that are worth checking out? Is it worth looking at a web framework, rather than start from sractch?
I've done some basic web development in PHP/Python so would prefer to build in that I think..given that hosting it would be relatively cheap..
Have done some basic C#/Java; would it be worth looking at these instead? I tried creating a simple ASMX webservice but most of the examples cite using a MSSQL server, not sure if that is the way to go though.
Use a framework. No point reinventing the wheel and giving yourself a headache. A good PHP based solution would be to use Drupal to build the backend using the Services module to provide data via webservices. Drupal is so flexible and so popular now, that you can get a lot of what you want done without any code at all.
Roughly:
Install Drupal 7 on a webserver according to the instructions
Install the Services module
Design the entities that will make up your MySQL database
Tell the services module how you want to expose things
Some examples of API calls are here.
A case study of someone else who has used Drupal as the backend for iPhone/Android is here.
You will have a learning curve to get your head round Drupal, but you'll have one anyway to get your head around webservices and the benefits you gain from having everything else Drupal offers are enormous, e.g.
The difficult bits are already done for you, so the amount of code will be massively reduced, if you even need any at all
Using Drupal's hugely flexible entities system, you can design a flexible and extensible mysql database scheme using the web based UI, which will be ready to work with any of Drupal's other modules, so you can expand add features with minimal effort in the future
There's an enormous community of people who can help you and the forums on drupal.org are very active
You would have a great UI for users, in case you ever need to give them access to their data through a normal website interface. Drupal has loads of pre-built themes (I recommend Omega) which look awesome and again, little to no code is needed to get a whole site ready made along with HTML5, standards compliance etc.
Drupal provides you with ready-made modules to provide access control via roles, as well as everything else you can imagine e.g. managing a mailing list for your users, providing you with usage statistics, admin interface for user and role management etc.
Drupal use is exploding globally and there's a serious skills shortage, so you'd be even more employable :)
First, it's not compulsory that you use a REST web service. It's just that WS si more or less standard for web-based applications.
I'm not really familiar with PHP, but in python you have django-piston. On the IOS side you have restkit to pair the server with.
What I could say from my experience is that writing a prototype in django is quite easy and you can definitely use this to develop your app.
I am new to both Django and Rails. I am thinking of developing an Web 2.0 style application and is planning to expose Restful services, which my UI tier would call to make CRUD operations (Something similar to ADO.NET Data services)
I am yet to decide on the platforms and is looking for some advice on which one to side develop on?
I am currently thinking of Ruby on Rails or Django.
The benefit of using DJango / Python is that I can move to google AppEngine in future with some code changes, but on the down side I hear DJango is not RESTful.
I am also new to both Ruby and Python. So, what would be your advice on which platform to use?
Well if you want to couple the view and controller with REST then you are right that django is not RESTful, because with django you would have to (de)serialize django objects and manipulate that by yourself in the front end using your favourite javascript framework. Saying that, if your only concern is to send and receive data RESTfully without caring how to do it, then django should be sufficient for you since you've already got your heart for it.
Django is fine for REST applications. Rails claims to provide some functionality to that makes REST easier, but it is largely inaccurate - things like human-readable URIs don't really matter to REST. Rails auto-generates POST/GET/DELETE/PUT stuff for you, but it's just as easy to do in Django too - and it really doesn't have much to do with REST, either, it's just proper HTTP usage.
REST is a general type of architecture, it has very clear constraints, but there is no one, single way to do a REST application. This is a good discussion by the architect of REST, Roy Fielding, on some common misconceptions: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
I recommend Python and Django, but not for REST-related reasons. (Better documentation, a saner API with Django, less nasty monkey patching and black magic, less coupling, etc)
A RESTful interface is used for building distributed applications. Does your UI tier and services tier really need to be physically separated? Seems overkill to me.