Posts Tagged ‘portal’
Mobile Sites That Act Like Mobile Apps
In a recent blog entry posted by me on my company’s site I discussed IBM Worklight and a necessary distinction between mobile sites and mobile apps. Usually I continue to chew on an idea well after the deadline has passed and the content is out of my hands. Such is the case with this article. One of my projects is to assist in the completion of a new mobility workshop focused on IBM Worklight. In line with this I was looking for a way to make additional refinements in what I believe is a very important distinction.
Thus, I come to today’s title. By no means do I intend to disparage sites that look, feel, and in some ways behave like a ‘true’ mobile app. The capabilities of HTML5 are far to significant to overlook. A look at an OpenNTF project espousing such an approach demonstrates the pervasive impact of how a local cache can richly enhance a mobile site. Another technical blog I am growing to appreciate is a collaborative effort called HTML5 Doctor. One article I wish to draw your attention to was written by one of the collaborators, Mike Robinson. “Go offline with application cache” is an interesting and well written introduction to this HTML5 feature. The article describes a key artifact, the manifest file, whose purpose is to identify the other artifacts that are to be cached on the local device. In addition, and it is to this that I most want to draw your attention, the manifest file specifies a FALLBACK section that describes, “What to do when an offline user attempts to access an uncached file”.
Whew, I just burned my way through a lot of words to make the point that a mobile site can act like a mobile app in this sense: when a network is no longer available there will be some amount of information in the form of files (css, html, javascript) and data that can behave in a potentially useful way. It is more than simply having a UI that is “responsive” to the device’s form factor. (Not that this is a bad thing).
There remains a vital distinction and that is this, an efficient, elegant, and rich offline feature set is ultimately bound to employ some features and probably some binary code that is device specific. This is where, from an enterprise perspective, IBM Worklight is a welcome and powerful ally for developers and solution architects. I can easily imagine a project team consisting of core Worklight developers, Android Java developers, iOS Objective C developers, and others working together to deliver applications with consistent look and feel AND with extraordinary capabilities whether on or off line.
At some point in the near future (I hope) I will have some concrete example to discuss.
Worklight: A Mobile Solution from IBM
Recently I blogged about my first pass at this technology on our Corporate blog, Technically Speaking. I took a brief tour on my Macintosh because of my interest in Apple’s iOS and because I wanted to see how much of a hassle it would be to install. It really wasn’t difficult at all. Yes, it took more work than most end user apps but it was easy.
On a related note, the app touts its ability to create hybrid apps. I am still sorting this out. What, exactly, does this mean. Does it simply mean that there are ‘native’ components and ‘web’ components or is this something more sophisticated. In my view it is the latter. The Worklight server provides the plumbing by which the native app, through the Worklight API, can access enterprise data.
This could mean that an organization can deploy apps that integrate corporate data into their mobile environment with relative ease and with the additional assurance that the data is managed securely.
Need to think about this some more but it looks very interesting.
Adding Dynmaic Content to WebSphere Portal Themes
Not all who follow my blog visit the Davalen blog. It really is a good one and worth your time. I have brought my recent contribution to that blog here in hopes that others will find it helpful. By the way, we are at the Exceptional Web Experience Conference. Drop by if you can,
Here’s the original article: One purpose of theme customization is to enrich a site by delivering some content ubiquitously. Though delivery of most content is accomplished through portlets delivery, in a theme provides delivery of the same content throughout pages in the site that employ the same theme. That is, as a user navigates from page to page, certain content is consistently displayed. Out of the box examples of this approach are illustrated by the search widget, help link, username display, etc.
There are two logical approaches to delivering content in a theme: client-side logic and server-side logic. Client-side logic consists of JavaScript, iWidget, and live text that is stored in a WebDAV file store and is referenced in the file theme.html. A significant benefit of client-side logic is offloading of content aggregation to the browser. Further, the development of these components can be delegated to web designers using conventional web design tools.
Server-side logic consists of Java Server Pages (JSPs). JSPs cannot be stored in WebDAV and directly referenced in the file theme.html, as they rely on a servlet context for lifecycle events.
In many cases an organization may have an existing repository of JSPs they wish to leverage in their new customized 7.0.0.2 WebSphere Portal theme. To do this there are three tasks to perform: develop the content such as a JSP, configure the application server environment, and insert dynamic content spots into the file theme.html.
A web application developer can create the JSPs and related resources for delivery of dynamic content. Additionally, such a developer may be engaged to customize other dynamic providers associated with a custom theme. These artifacts are deployed in a WAR which is a member of an EAR file. The operational management and deployment of theme artifacts is covered in the supplemental documentation for the product here.
A WebSphere administrator will log on to the Integrated Solutions Console of the application server and navigate to: Resources -> Resource Environment -> Resource environment providers -> WP DynamicContentSpotMappings.
A new Custom Property will be defined by entering an arbitrary name to serve as the ID of the mapping. In addition, a URI value used to locate the dynamic content is entered. The format will vary but the syntax is similar to this:
res:/CustomThemeContext/themes/html/MyTheme/dynamicContent.jsp
The third task is to define the dynamic content spot in the theme.html file. This task will require knowledge of the dynamic spot mapping ID defined by the administrator. The following is an example of a dynamic content spot tag:
<link rel=”dynamic-content” href=”dyn-cd:id:<mapping-ID-provided-by-administrator>
If you are developing on a live server, clear the browser cache, and load the page bound to your custom theme to view the result.
Taking Notez - Island Pond Consulting 