iUI 0.40-dev2 released

[Sean Gilligan]

iUI 0.40-dev2 has been released and tagged.

The zip is here: http://iui.googlecode.com/files/iui-0.40-dev2.zip

The release notes are here:
http://iui.googlecode.com/hg/releaseNotes.txt?r=REL-0.40-dev2

The tag is here:
http://code.google.com/p/iui/source/browse/?r=REL-0.40-dev2

REL-0.40-dev2 2009-12-18
* Fix Issue #138 (orientation css not updating)
* Fix Issue #184 (hardcoded width of 320 in "orientation event fallback")
* Re-enable call to submitForm in onsubmit in showForm()
(rev d6abb099744e6ae7f1591e3208d3d54bb35c2a51)
* Merge all -moz-* properties back in to iui.css and theme css
* Fix Issue #124 (Panel height too short on webapp-capapble) and add a
test for it
* Create placeholder for gradient version of default theme
* Add iui.goBack() and use it instead of history.back()
* Add iUI favicon.ico and iui-favicon.png
* Added starting point/placeholder for QUnit Tests
* Numerous additions and improvements to Test pages
* Numerous improvements to Google App Engine website

[Charles H]

Great!
Just a quick question about:

* Add iui.goBack() and use it instead of history.back()

Does the behavior is changed? Is that fixing bugs about the history?

Thanks,

Charles

[Maximilian Melcher]

Hello Charles,

what history bugs are you talking about? Is there an open issue for this bug? If not please open one.

Cheers
Max

--

You received this message because you are subscribed to the Google Groups "iui-developers" group.
To post to this group, send email to iui-dev...@googlegroups.com.
To unsubscribe from this group, send email to iui-developer...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/iui-developers?hl=en.

--
Max

[Charles H]

On Dec 27, 5:40 pm, Maximilian Melcher

<melcher.maximil...@googlemail.com> wrote:
> Hello Charles,
>
> what history bugs are you talking about? Is there an open issue for this
> bug? If not please open one.
>
> Cheers
> Max
>

Hello Max,

I was referring to the issue I had (#201) but I managed to solve it,
now I realize that it wasn't really a "bug" of iUI.
Anyway, does it changes the behavior of the history or not at all? :-)

Regards,

Charles

[Maximilian Melcher]

It would surprise me if it would change the behavior. iUI implements
it like Apple describes it in the human interface guide for the iphone
- you have any wishes/suggestions?

I think the only the method got refactored for easier use.

Cheers
Max

[Sean Gilligan]

Charles H wrote:
> Great!
> Just a quick question about:
> * Add iui.goBack() and use it instead of history.back()
>
> Does the behavior is changed? Is that fixing bugs about the history?
>

In short, the behavior is changed somewhat. Previously the back button
used the browser's history.back() function to go back, but now it
directly uses the pageHistory array maintained by iUI. In certain cases
where history and page hierarchy are out of sync undesirable behavior
could occur.

The changeset is here:
http://code.google.com/p/iui/source/detail?r=b8a754231f1806a3dac27f8dbbdc4c724ad6420f

You can also look at Issue #183:
http://code.google.com/p/iui/issues/detail?id=183

-- Sean

[00Vic]

I have some suggestions about the back button. First I'll state that
I'm a JavaScript novice and have been trying to understand the code in
iUi with moderate success. I am not familiar with the object oriented
way most of it is written and most of my experience has been with the
old school way of creating functions to do what I want and calling
them from events on page. A fully commented version of the js file
would really help myself and others who would like to contribute but
aren't quite up to the same level as everyone else yet. On to my back
button suggestion. I have been working on a project to balance my
checkbook by entering transactions via form as I make them. There are
several cases where I would like to override the default back button
behavior and haven't had much success. I don't have online examples
for anyone to see yet but think I can give good description of my
problem and possible solution.

Page A = list of accounts
Page B = list of transactions per account
Page C = form for new transactions

When using app you would go from A>B>C>B (In this case the final move
from C>B is forward after form submission. The problem being that
after you put in several transactions you collect quite a history of
going B>C>B. You can imagine the problems trying to use the back
button to get Back to A. Thus far I have remedied this by leaving the
Back button off of page B and using the blue button as a link to A.
This works okay but doesn't really feel like a native app without the
breadcrumb trail in the upper left. I have tried with no success to
implement the following suggestions, and am asking for help from
people more experienced than my self.

My proposal is a more flexible and easy to customize back button based
on attributes on the page. For example in my scenario above I don't
want page C to ever be in the history or on the back button. An
attribute like <form noHistory = "true"> could keep this from being
added to history and back button stack. In the case of page B the back
button should always link back to Page A, regardless of how many
cycles of B>C>B>C>B>C>B you have done. I propose something like this
attribute set to override the back button <ul altBackHref =
"#acctList" altBackText = "Accounts.">.

I welcome any feedback on this, and I love the iUi framework, and
would love to contribute. A fully commented js file would be very
helpful. Some back ground info, I am not a programming newb, I have
been playing with HTML, css, JavaScript, php, and mysql as a hobby for
some time, but most of my experience has been procedural or function
driven programming. I am a cs student who has only recently begun to
learn object oriented methods of programming in C++, which I am
starting to think is not the most friendly language for OOP. Thanks
for your time and any feedback in advance!

On Dec 28, 2:13 pm, Sean Gilligan <s...@msgilligan.com> wrote:
> Charles H wrote:
> > Great!
> > Just a quick question about:
> > * Add iui.goBack() and use it instead of history.back()
>
> > Does the behavior is changed? Is that fixing bugs about the history?
>
> In short, the behavior is changed somewhat.  Previously the back button
> used the browser's history.back() function to go back, but now it
> directly uses the pageHistory array maintained by iUI.  In certain cases
> where history and page hierarchy are out of sync undesirable behavior
> could occur.
>

> The changeset is here:http://code.google.com/p/iui/source/detail?r=b8a754231f1806a3dac27f8d...

[Sean Gilligan]

00Vic wrote:
> I have some suggestions about the back button.

These suggestions are really about management iUI's navigation stack,
which the back button uses. I'm just stating this to be more clear and
to reinforce the distinction that the iUI back button is now different
from the browser history back button.

> A fully commented version of the js file
> would really help myself and others who would like to contribute but
> aren't quite up to the same level as everyone else yet.

Agreed. It would have helped me. I expect commenting the file should
happen along with using some kind of JSDoc tool for release 0.50.

> My proposal is a more flexible and easy to customize back button based
> on attributes on the page. For example in my scenario above I don't
> want page C to ever be in the history or on the back button. An
> attribute like <form noHistory = "true"> could keep this from being
> added to history and back button stack. In the case of page B the back
> button should always link back to Page A, regardless of how many
> cycles of B>C>B>C>B>C>B you have done. I propose something like this
> attribute set to override the back button <ul altBackHref =
> "#acctList" altBackText = "Accounts.">.
>

You're bumping against the last major issue (that I'm aware of) in iUI
forms handling and your suggestions are very good.

I've implemented something like this for a project that uses iUI and was
trying to get in to 0.40-dev2 but decided it was going to have to wait
for the next release. In fact, I'm tempted to make the "no history"
option the default option for forms, but we probably shouldn't do that
for backward compatibility reasons.

I'd like to try to implement the "no history" option without adding any
new (non-HTML) attributes to the tags, if possible.

> I am a cs student who has only recently begun to
> learn object oriented methods of programming in C++, which I am
> starting to think is not the most friendly language for OOP.

What I've learned is that there are many different flavors of OOP and
that each language has it's own patterns and best practices for OOP.
When using a new language it is very tempting to try to shoehorn in the
OOP concepts from your last language into the new one. When coming to
JavaScript OOP from your academic C++ perspective keep this in mind.

-- Sean

[Remi Grumeau]

This works okay but doesn't really feel like a native app without the
breadcrumb trail in the upper left.

Sounds more like a CSS issue nope ?

Anyway, iUI replace the #_idname in the back button href value when transition is finish. Perhaps you can override this change with a #_pageA href value … ?

In fact, I'm tempted to make the "no history"
option the default option for forms, but we probably shouldn't  do that
for backward compatibility reasons.

Since a tool is not yet in official 1.0, you don't have to care about backward compatibilities.

I am a cs student who has only recently begun to

learn object oriented methods of programming in C++, which I am

starting to think is not the most friendly language for OOP.

Dunno for Javascript, but sometimes in PHP, functions are cleaner and quicker to execute than OO.

OO is not always the only way/solution, even for core functions/methods.

Remi

[Sean Gilligan]

>> In fact, I'm tempted to make the "no history"
>> option the default option for forms, but we probably shouldn't do that
>> for backward compatibility reasons.
>
> Since a tool is not yet in official 1.0, you don't have to care about
> backward compatibilities.

For a variety of reasons I have tried very hard to not break backward
compatibility in iUI. Yes the original version was called 0.12, but it
has been widely adopted and I have heard many users on the list talk
about delaying upgrades to new versions because of the effort involved
(usually this is because of modifications they've made to iui.js and/or
iui.css)

Maybe we should rethink that assumption or maintain two branches (one
that's backward compatible and one that isn't) There would have to be
more active volunteers than we have now before I would seriously
consider maintaining two branches. When we have the "no history" mode
implemented and debugged, I'm open to a discussion about changing the
default (probably on iPhoneWebDev). If the consensus is to break
backward compatibility, I would change the default behavior.

-- Sean