Any thoughts on using Flex to build an RIA for administering a complex rails app?
We are starting to find it difficult using ajax to keep our admin section intuitive and easy for users to work with.
You've got RoR guys working on this program and you've managed to develop a complex rails app that has enough subtleties that the admin section is difficult to use.
The answer to this problem is not to use a different programming language to create a whole nother kinda app to do the admin.
It will help more to get assistance in simplifying and organizing your admin section. Work through some paper sketches to get a better idea of how to present this complexity and maybe reveal complexity as you go along.
Complexity is handled often by using wizards or revealing suboptions as you go along. Spend some time with your users and watch them do their tasks.
With more details I could edit this answer with more specifics.
Try investigating this book:
Flex is certainly worth considering in your scenario. Generally, Flex is more mature development platform than AJAX is so if your server-side data are exposed via some reasonable interface (web services, REST-full services etc.), building a Flex front-end would make sense.
It really depends on your needs - Flex vs. AJAX is an interesting topic on its own.
If you want to use XML for communication then there isn't much you need to do on the rails side. But if you want to use an AMF gateway you will want to checkout RubyAMF.
But I agree with MattK if you just want to redesign your admin section it's not worth adding in Flex. I think you just need to do some usability testing, take that feedback and refractor your interface.
I would only consider using Flex in your situation if you already have Flex developers or if you could outsource that part of your project. The Flex modules simply call web services (written in Ruby or whatever) so there is a very nice separation between the two parts of your project. Since the interface between the two parts is an easily-mockable web service, outsourcing works well. There should be plenty of web shops local to you who could handle the work. An admin site should take only two to three weeks to develop in Flex if the developers are knowledgeable.
Related
at the company where I work, we use OTRS to schedule tickets and such. But the web interface is not very intuitive and easy to use, particularly on mobile...
Is it possible to create my own mobile version of OTRS? I mean, I can create a website that is mobile optimised and easy to use, but is there an API to communicate with OTRS?
I've only seen simple scripts to create tickets via soap or rest interface, I need to create a ticket, show a list of the user tickets and close them, postpone them...
Thank you in advance
It is very much possible, since the OTRS is Open Source and you can basically do whatever you want with it. You might however underestimate the scope of the task you're talking about. I once thought about doing something like this too, but when you look at the functionality the OTRS is providing in the background and all the little details you need for a working interface you will probably come to the conclusion that it requires a LOT of work.
You could use the Generic Interface to create a Webservice that enables you to access ticket information etc. and build your own Frontend that utilizes the Webservice. I can tell you from experience that there is lots of functionality you need to add to the webservice to create a decent API for your Frontend, because the Information the Generic Interface offers by default is very limited.
Since OTRS Version 5 the software includes an interface with responsive design in order to make it better suited for mobile use. Depending on the version you are currently using you might consider upgrading to it. If you want to check it out first you can have a look at the online-demo they feature on their website: https://www.otrs.com/otrs-demo-trial/
If you like the concept of the OTRS but the interface makes it difficult to use for you, the founder of the OTRS released a different kind of ticket system called Zammad. You might want to check it out, it's interface is aimed at being more intuitive.
tl;dr
Yes, it's certainly possible - the OTRS is an open system, but very difficult and probably not worth the effort.
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 starting learning Ruby on Rails, and as far as i am understanding, there are two ways about how to aproach programming in RoR and designing the web application:
Designing the back-end in RoR (data model, engine, etc), offering API in JSON (it could be done by team A). By this way, you can build up the front-end in HTML5+CSS3+JavaScript separately, and communicating with the back-end through JSON (done by team B).
Building up the web application entirely on RoR, the back-end and front-end integrated.
As far as i understand with this two ways, the first option is advisable when you are programming not only for web application, but for other plataforms, like mobiles or tablets (iphone, ipads, etc), because you are offering a REST API to communicate with different platforms. But the second option is ideal if you want to get the power of productivity of RoR, because you dont have to design API.
What are my options if I want to design a web app with mobile features capabilities for the future?
I am interested in your experiences with this decision. Please back your answers up with facts.
I feel that Rails companies are now looking for people who are familiar with the full stack(front and back end), --you will always have people who are stronger in one area or another of course--
For personal experience I can say that I've seen better results when front and back end are integrated, people are exposed to both sides and are able to sort out issues while the project is in development and to be honest I can't think of any reason why following this method would affect future mobile development.
Hope this helps.
I've been asked to devise a website for a small organization (with limited funding) - with internal and external facing sides.
Internally it would allow sharing of documents, a blog, goal setting, more?
Externally it would provide a simple but nicely designed public statement about the company's services.
It may evolve over time.
Should this be a custom-built solution or does it make more sense to ride on top of a platform that provides this type of service (such as?)?
If it's a custom built-solution, I'm considering doing this in Rails - would there be something like this already built for Rails?
I've always found it frustrating to build on top of pre-existing platforms, especially when it comes time to extend the functionality. If it's up to you, I'd suggest to build it yourself. Pick a framework and design specifically around the needs of the company.
Rails is a nice choice if you're comfortable programming Ruby. Although, any modern MVC framework would be just as good.
I'm quite a big fan of Hobo. Sits on top of and extends Rails. Provides a lot of standard scaffolding, an admin function and section, and lets you publish static pages. You can stick a "before_filter :login_required" on any and all controllers to prevent random visitors from seeing things, or extend the user model to have role or other based access controls.
I've never used Hobo to fully build out a scaled service for more than a handful of users. But in a small environment, it's awesomely fast to put together resources, with access controls.
Django has an amazing admin function already built into the framework. It could potentially take care of all of the internals, and the external view can be shown to anyone who doesn't navigate to the admin.
It's at least one consideration if you're thinking of making a custom solution (which I might suggest if you believe the site will most likely grow.)
Depending on your resources, I would start off with an "as-is" solution that allows customization. This will give you the quickest "wins" from the company standpoint. Once the organization, and you, start to use and understand the benefits, you can start customizing pieces.
Depending on your budget Windchill does this. I believe it was once called GlobalVault (a much better, and more descriptive, name).
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.