PDA

View Full Version : Best practice?



PCSpectra
12 Jan 2010, 8:35 PM
Not sure if this belong in plugin development forum...but here goes:

I have an application which is composed of various components, each of which relies on a data source in the form of scripts and REST-like URI's.

The scripts will eventually be converted to REST-like URI's, that is:

do_something.php => do/something
do_moreagain.php => do/moreagain

Currently there are about 6 controls implemented and probably 25 when complete. How should I best abstract the URI for each control so that its a trivial matter later on to switch to a more formal PHP framework/archiecture (ie: Zend in this case as opposed to transaction scripts like I have now)

Using globals is one approach but doesnt seem very effective in making the components reusable. Plus name space collision is a big issue after a few variables, nevermind 25+.

What is the best practice? Instantiate the data store outside the context of the component and inject the data store are runtime (dependency injection style) -- This seems a flexible design as it allows me to reuse the component(s) while keeping the data store somewhat decoupled, so whether I use a HttpProxy or ScriptTagProxy does not matter.

Cheers,
Alex

Mike Robinson
13 Jan 2010, 7:32 AM
:-? "What the heck did he just say?" :-?

When I am using AJAX, I don't use "REST-ful things." Frankly, I don't need to. The entire request simply comes in as part of the JSON packet: the method-name, the parameters, and any authentication/state tokens or cookies. It can all come to "just one post-office box."

In any case, the URI structure, if it contains parameters (i.e. "RESTful"), should be regarded as nothing more than ... "parameters." It does not reflect the underlying application structure, and it should not be able to be used to "probe" the nature of that structure in any way.

When the URI is viewed as "just another source of parameters," this is why I regard the idea as an unnecessary complication. (In fact, it can add risk. "Any ol' party that sends me any ol' URI" is not "trustworthy" nor "He Who Must Be Obeyed." Dealing with that at a URI level is a RPITA.) Keep it very, very simple. Everything comes in through one black box, and everything that I need to know is in the JSON object that is sent. Everything the client needs to know comes back in the JSON object that is returned. The (highly modular) nature of the underlying application is both opaque and inaccessible.

PCSpectra
13 Jan 2010, 7:45 AM
When I am using AJAX, I don't use "REST-ful things." Frankly, I don't need to. The entire request simply comes in as part of the JSON packet: the method-name, the parameters, and any authentication/state tokens or cookies. It can all come to "just one post-office box."

Thats why I said RESTful-like URI's :)

Basically they resemble SEF URI's instead of the more traditional individual scripts. All requests are sent through a single index.php and using .htaccess the URI request resemble SEF/RESTful-like URI's -- in no way are the URI's RESTful though.

I am not sure I made my question clear, as you seem to focus on the URI structure, which is not what I was asking, clearly I used a poor choice of words.

Basically, the URI associated with each component, must be easily changable to make the component more reusable. If I wish to bind a component which I keep in a separate JS file to an external data source or a new URI internally within the same Domain I should be able to quickly do this, by *not* touching the implement JS file but instead by injecting that decision into the component.

Dependency injection, ala Inversion of Control, to some degree. I am not sure how common this practice is in JavaScript, as I almost always use PHP. In class based OO languages its a very common technique to give client developers more control over implementations of a reusable component.

How is this best accomplished in extJS.

Do I assign the URI in a global variable:

var grid_products = 'services/products_list.php'

The componet would then be coupled to the data source 'type' (HttpProxy or ScriptTagProxy) which is not ideal but acceptable in this case, but the URI must be easily updated without having to modify the JS source file, ideally anyways.

If you can attach a data store object dynamically, via setter methods, this would achieve some form of inversion of control and prevent my component from having to explicitly instantiate that object itself and thus tighly couple my component to a specific solution.