IMPLEMENTING THE ENYO BOOTPLATE
————————————————————
As planned last week I went ahead this week started with the actual implementation procedure. For this purpose, I started with the Enyo 2.2 bootplate which provides the basic app structure needed by any Enyo app. The primary reason behind choosing the bootplate was that the bootplate template already provides all major libraries required including minimizer scripts, the Onyx widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. set, etc.
The bootplate implementation part was fairly simple as expected. Extracted the contents of the bootplate zip into a directory named wordpress-firefoxos and added a manifest.webapp file with the following details:-
{
“version”: “0.01”,
“name”: “WordPress”,
“launch_path”: “index.htmlHTML HTML is an acronym for Hyper Text Markup Language. It is a markup language that is used in the development of web pages and websites.”,
“description”: “WordPress for Firefox OS.”,
“icons”: {
“48”: “images/logo48.png”,
“64”: “assets/icon64.png”,
“128”: “assets/icon128.png”
},
“default_locale”: “en”,
}
Once this was done, a basic app structure was established and I was good go to get started with the actual rewrite process.
DEVELOPING THE COMPOSE MODULE
———————————————————
As already stated in last’s week’s report, I found that it was pretty much a no-go to try to “Port” the existing module to the new app. Rather writing from scratch made way more sense. Hence, I took a from scratch approach, by first having a look at the Compose module in the older app and here’s a list of the primary components within the compose interface:-
1. A Toolbar consisting of four components:-
i. A “New Post” caption.
ii. A “Preview” button.
iii. A “Save Draft” button, and
iv. A “Publish” button.
2. A Text Input box for the Post’s Title.
3. A Text Input Area with the standard WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. toolbar buttons and
4. A footer Toolbar with a “Settings” button.
Almost all of these components with the exception of the “New Post” caption would require explicit function declarations to account for their respective behaviors. However, the two primary parts of the Composer interface that require quite a bit of attention are the Image Upload and Settings buttons, as they trigger added behavior for the interface – while the former opens up a pop-up window to handle Image Uploading , the later opens up a sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. with Post publishing options.
An interesting challenge which needs to be taken care of here is that of how to tackle sidebar in smaller devices in the portrait mode.
CURRENT STATUS AND POSSIBLE DEVIANCE FROM SCHEDULE
——————–—————————–—————————–——————
The UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. rebuilding process for the Compose area is almost done, using the Onyx widget library, however much of the behavioral functionality is yet to be written, most notably the Image Upload function. The heavy usage of persistence methods along with a large number of deprecated functions in the earlier app with a surprisingly low / no amount of code documentation is making things even harder. Also, the humongous amount of structural changes in enyo itself renders the older app’s huge code base virtually useless for reuse. All of these factors combined together, is taking its toll on the time vs. implementation graph, as the learning curve gets steeper and steeper, its taking me a bit longer than initially anticipated to get things implemented.
I expect to run a bit behind schedule in getting the Compose module implemented complete with the Image Image Upload and Settings functionalities. Another big issue that I’m currently facing is implementing Persistence in the app. Enyo’s persistence APIs seem to have been refactored, and I’m also a bit confused about how the Persistence.js module has been implemented. I’m currently trying to figure this issue out. Once, this hurdle is cleared, the rest of the app’s implementation process should be fairly simple.