Digital Workshop

Yes, in theory.

I'm looking at it from the perspective of building a HTML5 web page with an iframe element and then having another HTML5 web page that is inserted into that element.

If the parent page was created in Opus and contained a text box, when published to HTML5, it might output as



In theory, in Opus you'd insert a browser object pointing to your other HTML5 page and this would publish as the iframe element. Your iframe page is then able to locate the element (id="A00001") in the parent and manipulate it like any other element - change the text value; modify the CSS; insert additional mark-up.

The two things you'd need to know are: the id of the element from the Opus output - my guess would be the objects unique identifier as found with GetUniqueObjectID() and also how this ckeditor works.


It's why I think that the old rather pointless browser object might come into it's own as an HTML5 iframe. If one of my clients builds a fantastic corporate presentation in Opus that would take months hand-coding but the project requires some bespoke aspect that is impossible or impractical in Opus, it could be built manually and insert into an iframe. Because, the iframe and parent can communicate - data can be passed between the two almost as if the bespoke aspect was an integral part of the Opus publication.

BTW: Read this yesterday - off topic but seems like something you'd enjoy:

http://andreasgal.com/2013/01/08/why-th ... in-mobile/

Mack

Thanks Mack for that article link. I'm not sure what to make of it though, other than its generally optimistic outlook for mobile browsers being robust and performance-capable. (Hey Mozilla... if you are listening. How about giving users a parallel sqlite file (like your bookmarks file) for user's persistant storage... write directly from the webpage form to the DB.)

I sort-of see what you are saying about 'cross access' of data. I am not sure how wonderful that is. I mean, what I could do with that? Will have to give it some thought. What I am more interested in is essentially form input and persistent data. Given that web pages are not supposed to write to the client machine (other than recent developments with local-storage), I am looking for ways to do two things. One, conditional content (easily achieveable of course, and maybe your embedded iframe assists that.). Two, take user input and persist it locally -- hence my thinking about ckeditor. If a CMS framework can use ckeditor for live edit of a web page, then maybe it can be done locally/client as well (I suspect I am missing the dependence on WAMP or some server functions here however). If an expanded local data store is not possible (in web apps), I suppose I will search out the tools that produce apps for writing to the cloud as long as I can avoid paying the cost of the cloud itself.

Hey, how about that meteor in Russia? Looked like either Flash or Flex.

Web SQL Database is now defunct. Like most other JS APIs though, there are libraries that will innovate the way that the IndexedDB persistent store will work and you may see an SQL style library that sits on top of IndexedDB. Ultimately though - they are still different techniques and it'll probably depend on what data you're trying to store.

The iframe theory is just a little lateral thinking. As for the article, the notion that a web-based OS could replace something like Android or iOS seems rather interesting and would suggest that everything you would expect to do client side may eventually be possible with just web technology.

Mack

I want to store a couple kinds of user input: choices / interactions; and user text input. Certain data should be private, maybe encrypted. The idea is a series of publications that branch and filter content based on accumulated user input. If I understand correctly, IndexedDB is name:value pairs. So I'd have to discover if that represents a limitation vs SQL for query and how I write the app's logic. Another concern is a user might make a mistake erase the wrong part of the local store with web browser tools. Looking at it, I may find a better approach with nosql/couchbase or even neo4j and just let the user's data hang out in the cloud. I'd prefer to have the Pubs be offline capable, but maybe that's just oldschool. If the mobile device, or the web app package, could house some libraries (you mentioned) for stores/JSON or other -- I'd be willing to learn a little Java or maybe not.

re: "web technology", that would certainly shake up the landscape. I've read that the browser update cycles are something like every 6 weeks. Talk about a stable but moving target.

Cheers.