Developing web applications with widgets (or re-usable components) in ROR

Question

I have experience in writing code... but new to developing web applications.

I am in process of choosing a framework for my project. Based on my initial research almost everything is very VIEW centric where after all business logic has been executed a model is populated with data and passed on to the VIEW.

So the lowest level of granularity is the VIEW.

But I wonder what is the right technology to use if I wanted to develop re-usable widgets or controls. and then reuse them across multiple VIEWS.

i would prefer if the controls are in JavaScript and then they can easily be reused across pages.

So if I were to select Ruby on Rails ... does it have anything to help me write code in reusable widgets... or will it simply ask me to write the VIEWS which work with the data provided by the model?

Sorry if this is newbie question.

What do you use to write reusable Widgets in ROR?

to eloborate on what I mean by a widget.

Suppose I am writing a discussion forum web application. I want to write a widget called post which has 3 views. View 1 is edit mode. View 2 is summary mode. view 3 is Detail mode.

I throw in this widget in a page called QuestionStream and in this page the widget appears in summary view. I perform data binding so that i get a list of questions.

I throw in this widget in a page called ThreadView and in this page the widget appear in detailed view. I perform data binding and I get all the details of the question.

I throw in this widget in a page called NewQuestion and in this page the widget appears in edit view.

So its a self contained control... but is reused in multiple places in different modes (so to speak).

Answer 1

OK, well I hope I understood your question correctly.

Firstly I want to start by saying that web apps tend to be very "view-centric" since that's kind of (in a very abstract way) the basis of the REST architecture (i.e. the Internet). It's about stateless resources. You can imagine a resource being a form printed on a document. I've generated all the fields I require and I've printed it out and handed you the piece of paper. At this point I really don't know or care how you will fill out the form or with what data. I will only care about the data's validity once you hand me back the form and I can begin checking (for simplicity I've ignored AJAX concepts, that give you real-time validations/interactions). I think it's this 'statelessness' that makes it appear very 'view-centric', but don't be fooled, there's a lot going on under the hood.

With that said, there are three common ways of sharing code across your application.

PARTIALS - reusable view code - These are reusable snippets that can be used in your views - example: each item listed on Amazon has the same format (thumbnail, title, author/manufacturer, rating & price). It would make sense to write this View snippet once and just pass an array of objects where each object's attributes are then passed individually into the same partial and placed side by side

HELPERS - reusable methods - Helpers are again used in the views. Essentially it is common functionality that has been consolidated into a method so it can be reused multiple times, and by passing in different parameters you could make your method respond differently based on the situation (i.e. the current logged in user, or the current controller that has triggered this view). Example: I could create a helper method that could toggle my product listings from a detailed view, to a list view (not the best example, but I hope it gets the message across).

CONCERNS - reusable code across models - Concers are meant to "extract common and/or context specific chunks of code in order to clean up the models and avoid them getting too fat and messy". Please see this link for an example.

Your question was a bit tricky but I hope my answer helped clear a few things up for you.

As for your example, the 3 different views could be 3 different partials. You could then write a helper method that looks at the current controller, and determine which partial should be loaded. Digging a little deeper, you could then use concerns to keep your models' code DRY (Don't Repeat Yourself) - assuming you have multiple models with similar functionality.