Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Assume the following situation similar to that of Stack Overflow: I have a system with a front-end that can perform various manipulations on the data (by sending messages to REST back-end):

  • Posting
  • Editing and deleting
  • Adding labels and tags

Now in the first version we created it well modularized but the need as of now for 'evolving' the system similar to Stack Overflow. My question is how best to separate the commonality and how to incorporate the variability with respect to the following:

Commonality:

  • The above 'functionalities' and sending/receiving the data from the server
  • Look and feel (also a variability as explained below)
  • HTTP verbs associated with the above actions

Variability:

  • The RESTful URLs where the requests are sent
  • The text/style of the UI (the commonality is analogous to Stack Overflow - the functionality of upvotes, posting a question remains the same, but the words, the icons, the look and feel is still different across sites)

I think this is entirely a client-side code organization/refactoring issue. I'm heavily using jQuery, javascript and backbone for front-end development.

My question is how best should I isolate the same to be able to create multiple such aspects to the tool we are currently working on?

share|improve this question

migrated from stackoverflow.com Nov 12 '11 at 23:16

This question came from our site for professional and enthusiast programmers.

1  
It would help if you would share more about your current design. –  Aaron Kurtzhals Aug 15 '12 at 15:43
add comment

2 Answers

It sounds like you have created a web application in a similar way to content management systems (CMS) are designed. In CMS systems like DotNetNuke (DNN) You have a service (often called portal or site) configuration that allows you to setup DNS, DB, Styles/skinning against each instance of the application running. The code modules (your commonality) remains the same, but each "instance" includes a setting that inject skins (CSS + images) and base URL's and DB storage locations.

Invariably you need to decide how your/customers will want to configure those features and that will dictate how you store and retrieve the settings (your variability). I suspect you have already identified the variability parts and its just a case of refactoring the solution to allow those parts to be stored/retrieved just like any other part of your application.

share|improve this answer
add comment

The RESTful URLs where the requests are sent

Is this just a simple case of the URLs being something like:

(meaning, the API's base is variable, but the paths within are not)? If that's it, basically your REST-caller should do ${apibase}/api/post and plug in different values for apibase in the right place (application instance configuration).

The text/style of the UI

Being able to define different CSSs and text. CSS should be easy, for short texts you could probably retrofit your platform's i18n features and for long texts you could probably do with parameterizable includes, something akin to:

include("path/to/mylongtextresource-${sitename}.html")

Addressing your comment:

My ENTIRE URI is different - things ARE different in a restful world since it's very resource oriented. In your example the same 'type' of resources exist for the base resource. Yes, I do have them too and that's exactly how they are handled. But I feel the answer misses the point of the question. I need to 'structure' my code so that 'another' restful resource with 'similar structure' (e.g.,: /Site/{resource}/{id}/{sub-resource}/{id}/) can easily be added to the system with minimal changes

I'd use something like the following (pseudo-java):

interface ResourceService {
    public String getContent(String id, String subResource, String subId);
}

Map<String,ResourceService> services = {"resourceA" : new AResourceService(), "resourceB", new BResourceService(), ...};

@URLMap("/Site/{resource}/{id}/{sub-resource}/{id}/")
String getContent(String resource, String id, String subResource, String subId) {
    return services.get(resource).getContent(id, subResource, subId);
}

Meaning you can add programatically new ResourceServices to your Controller. You could also do it two-level if needed.

share|improve this answer
    
I wish it'd been that easy. My ENTIRE URI is different - things ARE different in a restful world since it's very resource oriented. In your example the same 'type' of resources exist for the base resource. Yes, I do have them too and that's exactly how they are handled. But I feel the answer misses the point of the question. I need to 'structure' my code so that 'another' restful resource with 'similar structure' (e.g.,: /Site/{resource}/{id}/{sub-resource}/{id}/) can easily be added to the system with minimal changes. Right now there adding something is non-trivial –  PhD Nov 21 '11 at 17:49
    
updated my answer with a possible answer to that –  alex Nov 21 '11 at 19:06
    
Yes. That is handled on my server side using restlet (the tag is not available on programmers'). The question is not how to handle it on my server, but rather how to handle the variation on the client! Think of multiple stackoverflow sites - they may be having the data be sent to different backend resources but the front end "looks similar" - it may not be as trivial as your first example but each {resource} could be named differently and the UI needs to be able to be designed to handle this variation. It's not just a separate page, but it's the same javascript that's to be used –  PhD Nov 22 '11 at 1:20
    
(cont'd) I'm more interested on knowing how to design the front-end to handle this variation –  PhD Nov 22 '11 at 1:21
    
The classic design pattern this reminds me of is strategy. A quick google of "javascript strategy design pattern" gets many hits, but I have not looked at them to see how suitable they are for your case. –  eric w Sep 25 '13 at 22:57
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.