occlick-event-handling in nested tags different in cloud-preview than on phone

[internetlabor]

Hello developers,

I found some subtle difference between cloud preview and phone.
It is in the example code of the "blog example"
(if I have not changed it too much in the meantime)

After RSS-Generation, there are nested div's with onClick-Handlers:

<div id="main_screen" class="ui-show" onclick="mwl.switchClass('#nav-back', 'ui-hide', 'ui-show'); >
  <div onclick="mwl.setGroupTarget(....);">...</div>
  <div onclick="mwl.setGroupTarget(....);">...</div>
  <div onclick="mwl.setGroupTarget(....);">...</div>
  ...  
</div>

The idea is that each link switches to it own page, but the back-icon is always switched to visible.
Because of the nesting it is less code, the javascript for the back-icon is only needed once.

This trick works on local preview, it works with cloud preview,
but it does not work on my Asha 311. The back button is no longer switched to visible.

So it looks like we need to write more code here.

Regards

Karsten Meier

[croozeus]

Hi Karsten,

I wouldn't call the provided 'blog example' a very well written template. All the feed data is fetched at once without any pagination, performance-wise it results to around 200Kb data on the S40 browser (very slow if not on WiFi).

To make the UI work properly - you could remove the onclick statement from the main_screen div.

 <!-- removing onclick from main_screen div in main.html-->
<div id="main_screen" class="ui-show">
</div>

You can use this statement in the div in the parseRSS function in blogging.js file.

// Adding onclick="mwl.switchClass('#nav-back', 'ui-hide', 'ui-show');" to the post-main div // line 36 blogging.js
main += '<div class="post-main ' + className + '" onclick="mwl.switchClass(\'#nav-back\', \'ui-hide\', \'ui-show\');mwl.setGroupTarget(\'#screens\', \'#blog_posts\', \'ui-show\', \'ui-hide\');mwl.setGroupTarget(\'#blog_posts\', \'#post' + (i+1) + '\', \'ui-show\', \'ui-hide\');">';

I would also remove the onclick from the header td with class header_table_td_height. This should just be on the back td and not on the header td.

<!-- removing onclick from header td in main.html-->
<td class="header_table_td_height"><div class='ui-title' ><h2>BlogExample</h2></div></td>

Hope that helps.

[internetlabor]

Thank you,

yes, It works when I attach an additional mwl-call to each click-handler.
Only problem is that the onClick-handler mutates into an monster line, and you must take care to get all the quotes right.
Writing javascript that writes html that includes javascript is not much fun.

About the blogging-example:
I liked that the screens are build in advance, and the article is displayed immediately with the mwl()-methods.
But in my use case the articles a quite short, and I have limited the number of feed items.
The reported data usage is 35kb on the phone, so I hope this is usable in the real world outside my office.
Some further reduction would be that an image of the article is loaded on demand, but this seems more difficult.

Reagrds

Karsten Meier

[croozeus]

Thank you,

yes, It works when I attach an additional mwl-call to each click-handler.
Only problem is that the onClick-handler mutates into an monster line, and you must take care to get all the quotes right.
Writing javascript that writes html that includes javascript is not much fun.

I know what you mean. When the dynamic HTML gets bigger, I find it efficient to use the single quotes in the HTML code and double quotes for javascript.

For example, the following looks prettier,

main += "<div class='post-main " + className + "' onclick='mwl.switchClass('#nav-back', 'ui-hide', 'ui-show');mwl.setGroupTarget('#screens', '#blog_posts', 'ui-show', 'ui-hide');mwl.setGroupTarget('#blog_posts', '#post'" + (i+1) + "', 'ui-show', 'ui-hide');'>";

I liked that the screens are build in advance, and the article is displayed immediately with the mwl()-methods.

Yes, mwl methods are executed locally, setGroupTarget and switchClass are the best methods to do view switching.

But in my use case the articles a quite short, and I have limited the number of feed items.
The reported data usage is 35kb on the phone, so I hope this is usable in the real world outside my office.

35 Kb should be pretty much usable.