A Great Idea, but how do I use it?

A Great Idea, but how do I use it?

Hi, My first reaction to finding out that all you need to know to make an Opera Unite application is HTML, CSS, and Javascript was "YES!" So, I was looking at how to develop an Opera Unite application because I liked the idea, but I'm finding that the information is kind of vague. I'm not sure what exactly is built into the libraries and what is not. I'm not even sure where I'm supposed to start in developing. Keep in mind though I am fairly new to Javascript, so I just might not have my feet wet enough yet.

What I'm asking is if there is a simpler explanation of how to go about developing an OU application?
From what I have read it sounds like there is a lot of things already done should make it easy, but the problem is I think you might lose me in some of the specifics like: how do I determine what my application looks like (GUI) and where do I edit this, are the examples supposed to work (because they don't for me), and how do I connect what I want to do with Opera and what is already been coded?

Here are some of the links I have already looked at:
http://dev.opera.com/articles/view/yusef-the-unite-server-framework/
http://dev.opera.com/articles/view/markuper-unite-template-library/
http://dev.opera.com/libraries/fileio/
http://dev.opera.com/libraries/unite/
http://dev.opera.com/articles/view/opera-unite-developer-primer-revisited/

Thank you!

Certainly your post could have been written by myself too

I've found the documentation kind of sparse, and even though a "Hello World" works great as a starter, the rest of posts I've followed are in another level. That's said from somebody who is not new to JavaScript.

Anyway, what I've been doing is to download some of the existent applications and read the code inside them. I'd say that's the best way to learn at the moment. Apart from that, having a look at each library or plugin source code is mandatory to know all the possibilities offered.

Going step by step is another advise I would give you, by doing simple things, don't go for starting your application from scratch because it could be frustrating.
In that sense what I did was to create a script where I have my own path to learn Opera Unite. A first step could be create a hello world, the second step would be using the PSO library to debug code, and so forth.

And last but not least, have a look to this awesome site:
http://unitehowto.com/

It has not been updated since a while but it is a good source where to get ideas from.

Regards.

Thanks for the reply,

I guess then that makes us the guinea pigs then as well as the people who may end up writing more tutorials.

This must also mean that I'm going to have to learn this in much the same way as I learned how to code a template in my cms a.k.a. trial and error.

There is one problem though: I'd rather invest my time in something that I know that I could get working instead learning it and finding out what I want to do is impossible. This may be too complicated for me then. Anyway I'll try it and if I can't get it to work then oh well.

Thanks for the awesome browser Opera!

Yup there's a bit of "trial and error" involved. Debugging a Opera Unite application relies on output sent to the error console, something I hadn't done in years to be honest

Good luck!

I found Opera Unite extremely simple to lears, both because simplistic design, fast setup, and simple/liberal request/response model.

I followed mainly primer (blog up) tutorial.

Downloaded blog.zip, unpacked, loaded into opera, started changing it (starting with config.xml, then looking into scripts.js).

First what i learned from tutorial, is that I can for example put static files in public_html directory, tested, works.

Then added some new handlers, simple, worked.

Checked how to access HTTP headers, simple, worked. BTW. still do not know if accessing them is case-insensitive.

All with plain JS, without Markuper, Yusef or any FileIO. So, have no need to setup it (I see, Markuper is easy, but I do not need it, even now, as my app is complete, maybe in 2 places Markuper will greatly improve cleanliness of my code, and simplify thinks like white-spaces, newlines and escaping of special character in HTML.

After few hours of hacking, and fully functional application, i wanted to have a way to save configuration to persist after Opera restart. This was slightly harder, I was thinking about using localStorage, but just used JSON.stringify with FileIO. It was slightly harder than previous additions, because I forgot about adding fileio feature in config.xml. After that (about hour of digging in the widget, FileIO tutorials), everything worked.


Good documentation was this: http://dev.opera.com/libraries/fileio/docs/overview-summary-file-io.js.dml
and this http://dev.opera.com/libraries/unite/docs/overview-summary-unite.js.dml

Especially list and info of ALL functions.

(I leater found on dev.opera.com a tutorial how to use FileIO in Unite to save blog entries in blog unite app from primer!)

Now, i have slight problem with icons, but it essentially works now. I just added two icon resolutions, and this was not enough. About 5-6 resolutions are needed 16, 24, 32, 64, 128, 256

I think, it well designed. It is quite interesting that server is actually single-threaded (It looks so to me), and make everything so simple. Like using global variables to store something. Nice. After unpacking primer (blog.zip), and initial hints, user can discover more easily, and incrementally.


It is as simple as PHP, but much better, safer, and cleaner.

Debugging was slightly harder. but error console, dragonfly, and try { ... } catch (e) { response.write(); } was quite good solution I STRONGLY SUGGEST to add optional (disabled by default) debug flag to widget config.xml which will mean that any exception or parsing error, will be reported back (with the backtrace) to the webbrowser as response, so i can easily debug application even without adding any special try/catch, or running error console.

It will be also nice to have, combo button for restarting Unite Application. Now we must stop it and then start it again, and then reload page. Three clicks. Should be one. It would be also usefull to external triggers (using 'http://localhost:8840/_admin/restart?myapp' or something) this stop/start from the outside (of course only in debug mode), so one can easly work for example in Firefox and Firebug, and can have shourtcut for this somewhere. No need to switch beetwen windows. Actually , monitoring files for changes could be even better (monitor all already loaded script files and config.xml for changes, if there was change, and script parses correctly, restart automatically application). With external triggers this could be easly emulated in linux using inotify script in bash, and calling trigger on change.

It's much simplier to debug if you connect with dragonfly and use Reload function from DF (in detached mode only) to reload "server" part of the application. No need to stop and start it then. And you'll be notified about parsing errors this way because debugger won't disconnect.