In my case, videos was not working on youtube.
I installed gstreamer1-libav-1.2.4-1.fc20.x86_64 and everything worked fine !
02 July 2014
JS API Viewer! new approach in Front-end development #javascript
We have REST console where we can test REST API. Similarly, we must create JS-API (DOM-Less Layer) using JS-API viewer/creator!
-- From this blog
This is part 3 of current series of DOM-less applications!
1) Part 1 : http://blog.narendrasisodiya.com/2014/05/what-is-dom-less-javascript-application.html
JS-API layer, can consist of multiple models and collections. In the above example, JS logic was simple, but in many cases, this logic is not simple.
Here are some screen-shots from the project, which I am working on!
My Task is to develop this page !
1) Part 1 : http://blog.narendrasisodiya.com/2014/05/what-is-dom-less-javascript-application.html
In front-end development, we have several MVC frameworks!
Now a day, we have clear cut separation between client and server using the REST API. Rest API abstract server's internal logic into REST API (JSON).
In part1 and part2, we had talked about creating a separation in client side code using UI-Layer Views and JS API.
We have given the name of this separation - DOM-less (JS-API) and UI Layer (Views).
UI Layers consist of HTML files, event bindings, js code which is required for creating Views.
Now a day, we have clear cut separation between client and server using the REST API. Rest API abstract server's internal logic into REST API (JSON).
In part1 and part2, we had talked about creating a separation in client side code using UI-Layer Views and JS API.
We have given the name of this separation - DOM-less (JS-API) and UI Layer (Views).
UI Layers consist of HTML files, event bindings, js code which is required for creating Views.
Dom-Less is basically JS API layer which may consist of multiple models and this layer talk to the server using the REST API.
So here is the architecture which I am following.
"JS API (DOM-less Layer)" talk to server using REST API.
"UI Layer" talk to JS API for all operations. "UI Layer" do not talk to the server or hold any business logic.
I have worked on large SAAS based projects (from single person to team lead), and the major flaw I found in development is - "normally we develop both layer (JS-API, UI-Layer) simultaneously, and because we do so, we produce mixed code, even If we use any MVC framework"
For example, In our View, we want to show list of students and total number of students. We may use 1-way or 2-way binding. Now for showing total number of students, most of developers will use JS code inside template file-
For example, In our View, we want to show list of students and total number of students. We may use 1-way or 2-way binding. Now for showing total number of students, most of developers will use JS code inside template file-
<span> Total students {obj.students.length} </span>
Assuming obj. students is an array,
Now this code is OK, but still the calculation of total number of student is performed inside View-template layer (UI-Layer).
Now this code is OK, but still the calculation of total number of student is performed inside View-template layer (UI-Layer).
That is what I was talking about mixing of code.
Instead of this, we must transfer the length calculation logic to the DOM-less layer (that is JS-API layer).
So we can re-write this as
<span> Total students {obj.getTotalStudents()} </span>
<span> Total students {obj.getTotalStudents()} </span>
Now we have shifted logic to JS-API layer.
JS-API layer, can consist of multiple models and collections. In the above example, JS logic was simple, but in many cases, this logic is not simple.
We have REST console where we can test REST API. Similarly, we must create JS-API (DOM-Less Layer) using JS-API viewer/creator!
If we develop our JS-API using JS-API viewer/creator, then we need not to work on Views and at the same time mixing of code will not happen.
So the normal flow of development will be->>
Server team will create a REST API then
JS team will create JS API using REST API and then
UI-team (html/css/views) can develop the rest of the code!
So the normal flow of development will be->>
Server team will create a REST API then
JS team will create JS API using REST API and then
UI-team (html/css/views) can develop the rest of the code!
What exactly is the JS-API viewer/creator !
My Task is to develop this page !
In my current approach I am not developing html/css for above view. I am not working on any View/HTML/CSS codebase.
I am working with JS-API Layer!
Now Here is my JS-API viewer which I wrote.
JS-API viewer is a generic module. This module creates an object of a given model/factory/class and show all its methods and JSON data.
Take a look at this -
JS-API Viewer/creator show JSON data inside view and generate buttons for all method.
For example in my code, you can see a SCAN function. You can see that Viewer has automatically generated a button to scan. If you click on the scan, then it will invoke scan function on the model.
Now here are some conventions.
If a function name contains "_" (underscore) the viewer will consider it as private function and it will not generate button for that function.
For example, there is no button for "_itemScanned" function!!
Also, If your function start with "get" then it will add this function into "watchers" list.
For example - getPackListItemLength starts with "get", so there is no action button.
Viewer generates a separate table for watchers where you can see their values.
Viewer generates a separate table for watchers where you can see their values.
Everytime, if model-data or internal state of JS-API changes, it will publish a change event and the viewer will load with new data (json). It will also execute all functions from "watcher list" and render table again.
So, we have a panel from where we can operate JS-API and verify my code using displayed JSON.
Because I am not writing any html/css/view/events, I am focusing on core JS logic, core business logic.
Because I am not writing any html/css/view/events, I am focusing on core JS logic, core business logic.
As an architect, I highly recommend this approach which will give you proper separation in client side code.
PS : Sorry for my bad English
Subscribe to:
Posts (Atom)