Masabi Rail Ticket js extensions not working

[Vic Hudson]

After recommending the Masabi Rail ticket extension the other day as a
solution on another thread, I decided to play with it and see if I
could figure out how it worked. The problem is that before I even had
a chance to mess with the scripts, parts of it seem to have stopped
working. I even re-downloaded the dev2 release in case a messed
something up earlier and didn't realize, but still had the same
issues. I wanted to see if anyone else has noticed this or has
suggestions to offer. Here is what goes on....

In the rail ticket app go to Buy a ticket>New Journey

All selects convert to panel and display proper when you click them,
but only the To, From, and Date fields update properly on the form
when returning from picking option. All of the others just continue to
display the original selections and I'm not sure if the hidden form
inputs the script adds are getting updated or not.

I played with the rail system back when I first downloaded dev2
release after it came out. I didn't spend a lot of time with it but I
am pretty sure that all the fields work. Ive tried it in Safari on
phone and windows as well as Firefox and get the same results on all
so I don't think its a browser thing, but I can't think of anything to
just make it stop working like that but browser updates. I know
Firefox was updated, but I don't remember the last desktop safari
update and I know its been a while since Steve blessed us with one on
the phone.

Anyone else seeing this? Ideas?

[Victor Hudson]

Guess I'm on my own on this one. I'll post progress for anyone
interested. I have been playing with the behavior of the app and I
think I've narrowed the problem down to the panel class for selects.
Class az seems to work fine and the date picker seems to work. My next
step will be to dive in the code and see what's different in the panel
class select funtions. With work and school I may not get a chance
till later this week though. And I'm still kind of a newb on this
level of scripting so if anyone wants to jump in on this any help is
appreciated. I would like to know atleast if any can check out the app
and see if they experience the same errors.

Thanks!
Vic

[Vic Hudson]

Sorry typed a reply from phone and didn't put original issue @ bottom
of reply. Pasting it in now.

----------------------------Original Post----------------

[Sean Gilligan]

Vic Hudson wrote:
> In the rail ticket app go to Buy a ticket>New Journey
>
> All selects convert to panel and display proper when you click them,
> but only the To, From, and Date fields update properly on the form
> when returning from picking option. All of the others just continue to
> display the original selections and I'm not sure if the hidden form
> inputs the script adds are getting updated or not.
>

> Anyone else seeing this?

I just reproduced the problem in (desktop) Safari 4.

> Ideas?
>
>

You might want to try downloading the 0.40-dev1 release and/or the
original zip that was submitted to the project and seeing if it works
properly. It's an attachment to Issue 178:
http://code.google.com/p/iui/issues/detail?id=178

I very well might have broken something as I was making changes for
integration.

-- Sean

[Victor Hudson]

Thanks for the idea Sean. I will try the other dev version and
original zip when I get a chance. It may not be till Thursday night
due to work and classes. I will keep every one posted on results though.

Vic

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

[Victor Hudson]

Just a quick update....
Sean, Following your recommendations I downloaded the .40 dev1 version and the original zip.

The bad news first - Something was broken in the merge. The problem exists in the app as packaged in both dev versions.
The good news - It does work in the original zip submitted.

If I get done with the mountain of homework I have for tomorrow night, I plan to try and start comparing the differences to see what might be different and causing the problem.

More good news I have spent considerable time studying the iUI.js and am starting to have a semi comfortable understanding of what's going on in there. Yeah for me!

On a side note, in another previous thread I had mentioned trying to find ways to override the default Back button behavior for special circumstances like forms and things. I posed the idea of adding attributes like backButtonHack = "true", altBackButtonHref = "location to go to", altBackButtonText = "name of page to go back to", and something like noHistoryStack = "true" for forms, to the container tag for pages I wanted special back button control on. You said these were good ideas but would like to see them implemented without non standard html attributes. As I have been studying the js file, and learning more about how it works, I have several ideas for mods to make these options possible, but they all involve checking for these type of attributes when iUI updates the page and during the click event handler for links. I am curious how you could let the script know to activate these type of mods only on certain pages without the use of non standard attributes. Suggestions?

The last question comes from a learning developer's perspective. I noticed iUI already uses a few non standard attributes. If browsers ignore tags and attributes they don't understand, is there a practical reason, besides clean standardized markup, to not use these types of attributes for use in scripts and such?

Thanks in advance for feedback on any or all of this everyone!

Vic Hudson

[Sean Gilligan]

Victor Hudson wrote:
> Sean, Following your recommendations I downloaded the .40 dev1 version
> and the original zip.
>
> The bad news first - Something was broken in the merge. The problem
> exists in the app as packaged in both dev versions.
> The good news - It does work in the original zip submitted.

Thanks for the sleuthing. I must have broken something. You may be
able to find it by looking at diffs in revision control...

>
> If I get done with the mountain of homework I have for tomorrow night,
> I plan to try and start comparing the differences to see what might be
> different and causing the problem.

I hope so, let me know.

>
> More good news I have spent considerable time studying the iUI.js and
> am starting to have a semi comfortable understanding of what's going
> on in there. Yeah for me!

Great!

>
> On a side note, in another previous thread I had mentioned trying to
> find ways to override the default Back button behavior for special
> circumstances like forms and things. I posed the idea of adding
> attributes like backButtonHack = "true", altBackButtonHref = "location
> to go to", altBackButtonText = "name of page to go back to", and
> something like noHistoryStack = "true" for forms, to the container tag
> for pages I wanted special back button control on. You said these were
> good ideas but would like to see them implemented without non standard
> html attributes. As I have been studying the js file, and learning
> more about how it works, I have several ideas for mods to make these
> options possible, but they all involve checking for these type of
> attributes when iUI updates the page and during the click event
> handler for links. I am curious how you could let the script know to
> activate these type of mods only on certain pages without the use of
> non standard attributes. Suggestions?

Well the noHistoryStack and backButtonHack option(s) would be easy to
implement with a CSS class and iui.hasClass() Finding a 'standard'
place to put an href or a string is little tougher. One approach that
could be used is an element within each fragment/page/div/ul that
contains the link and title. That element could then be hidden by
iui.css. Could you explain (remind?) what the use case is and exactly
how the alt location and alt text are used?

> The last question comes from a learning developer's perspective. I
> noticed iUI already uses a few non standard attributes. If browsers
> ignore tags and attributes they don't understand, is there a practical
> reason, besides clean standardized markup, to not use these types of
> attributes for use in scripts and such?

These are good questions. I ask them myself ;-)

The original developer of iUI chose to use the non-standard attributes.
Some folks are very dogmatic about following the standard closely and
not using nonstandard attributes, but, in practice, I have not seen the
non-standard attributes have not caused much trouble. However, I have
tried not to use them as I've added features (although I did do it in
one case.)

The non-standard tags will result in error messages from HTML validators
and could potentially conflict with attributes added as part of the HTML
5 spec, for example. There might be a few other possible bad outcomes.
My preference is to avoid using them if there is an (easy?) alternative.

I'm certainly open to discussing this further.

-- Sean

[Vic Hudson]

Thanks for your reply Sean. Unfortunately no time to look for the
masabi extension trouble yet. I do hope to get to it soon.

Sean Gilligan wrote:
>Well the noHistoryStack and backButtonHack option(s) would be easy to implement with a CSS class and iui.hasClass() Finding a 'standard' place to put an href >or a string is little tougher. One approach that could be used is an element within each fragment/page/div/ul that contains the link and title. That element could >then be hidden by iui.css. Could you explain (remind?) what the use case is and exactly how the alt location and alt text are used?

Here's what I'm working on. Its a checkbook app. The pages I need to
override back button on are as follows.
A = account list
B = transaction list from A
C = form to add new transactions goes back to B on submit

When adding several transactions you end up with a trail like
A->B->C->B->C->B->C->B->C->B
That's a lot of backing out to get back to A
In my case I don't want C to ever show up when you go back(Page C
needs noHistoryStack), and I want the back button on B to always go
back to A no matter how many transactions are entered(Page B Back
button would need to always be labeled "Accounts" and link back to
Page A, Thus the alt location and text).

I had not thought about class based detection, good idea.
Using the idea of css hiding of elements made me think of this...

for pages left out of of back nav altogether like my page C
<form>
<input type = "hidden" id = "noHistoryStack" value = "true" />
</form>

for pages like my page B that need back to always go to one particular
location.
<form>
<input type = "hidden" id = "backButtonHack" value = "true" />
<input type = "hidden" id = "altBackButtonHref" value = "location to
go to" />
<input type = "hidden" id = "altBackButtonText" value = "name of page
to go back to" />
</form>

If a page happens to be a form already, just add these hidden forms to
it, or add the form to pages with no form present. We could detect
this with scripting to make these types of overrides possible and I
wouldn't think it hard to publish these as standards for developing
iUI powered sites with these needs. Let me know what you think.

>The non-standard tags will result in error messages from HTML validators
>and could potentially conflict with attributes added as part of the HTML
>5 spec, for example. There might be a few other possible bad outcomes.
>My preference is to avoid using them if there is an (easy?) alternative.

All good points I had not thought of. The idea with hidden forms would
prevent the negatives mentioned, yes?

Vic Hudson