What I mean is this. You supply a controller for each model. Each controller can define methods to handle different URLs with paths within that model.

BTW, it seems that there are two naming conventions for controllers, either of which will work: you can either call the file just controller.rb, or else e.g. song_controller.rb if your model name were Song. Either one works - you get just controller.rb for Settings, but then when you generate models, the controllers are generated as, e.g. song_controller.rb.

Is one way or the other of naming preferred or deprecated?

So, anyway, there is index.erb directly under /app. Is there some way I can have a controller for that? Maybe add additional .erb files right under /app?

I have been using Settings as a kind of catch-all for some stuff that I have nowhere else to put. Most of it is just controller code, with no .erb. I do have a special .erb I use called /app/Settings/start.erb.

I use it as a jQuery Mobile "start page", because JQM keeps the first page loaded in the webview DOM. I'd rather that be just a blank page! I never use WebView.navigate or set window.location in Javascript, or use data-ajax="false". And so I just load my global scripts and styles in /app/Settings/start.erb, it has a blank <div data-role="page">, and then it just sits there always. (Or, I can load global popups and headers/footers in the .erb, outside of the blank page, using jQuery Mobile 1.4.x.)

Oh, and I extend WebView to add WebView.changePage(), which uses Javascript to send jQuery Mobile a proper change page. I use this where you would normally use WebView.navigate().

But /app/Settings/start is an awfully inconvenient, unwieldy URL! jQuery Mobile tacks it on to the front of each URL, so you get really long URLS, like:

/app/Settings/start#/app/Song/index

It clutters the log. It is confusing! I'd like to shorten it.

So, can I have a controller for the .erbs right under /app? Can I just drop more .erbs there, and they will just work? (But, really, I'd like a controller, because I might want to pass them some variables!)

Really, it's more of a rhetorical question, since I am just going to experiment and try it. I'll post my findings as I go. But I figured I'd post here first, and maybe somebody else has done it, and can save me some trouble. Or, if you have done something similar, then maybe I will get some ideas and change my implementation.

It seems to me I have some vague recollection of some discussion of custom paths.

Oh, while I am at it, I will ask a stupid question that probably doesn't deserve a separate post, and is somewhat related. What's up with Settings? If I actually populate a Settings model (can I?) then the collection is Settingss? In a previous project, I created a Configuration model, just because the idea of Settingss bothered me so much! Yes, I have Configurations, because I allow the storage of multiple user configurations (or you might to prefer to call them profiles).

In yet a different project (I didn't do it! I got it that way!) we cluttered RhoConfig with user settings. Yuck. We finally added a prefix to all of our custom RhoConfig settings, to avoid any possible conflict.

My browser downloads the Ruby bytecode for that page! I dunno how much I like that!

Make sure you do not leave fixed port 8080 enabled. Somebody could still scan for open ports, find your server port, and download your Ruby bytecode. Not sure how easy it would be to turn it back into Ruby, but...

Well, this does not seem to be a general vulnerability. You can't download the iseq files from real models. It's apparently just that I'm trying to do something strange and unexpected in the /app directory...

Here's where I got confused. Rhodes always starts you off with a simple (actually, empty) list of links in /app/index.erb. You almost always later change your startup page in rhoconfig.txt to some page in some model. In my case, I have been changing it to /app/Settings/start.

But I leave /app/index.html and use it as a kind of secret test page, that I can use e.g. from my desktop web browser when testing with a simulator. So, I can throw some various diagnostic tools in there.

I think that special test page ought to really find a home in /app/Settings. I change my /app/index.html to be the page with all of the scripts and styles in <head> any global popups, headers/footer or panels (jQuery Mobile 1.4.x) and then my Javascript code redirects to the real start page. (As I do now from the ungainly /app/Settings/start).

I still do not get a controller for that page. But that is OK. I already have a bunch of Ruby code in <% %> at the top of /app/Settings/start anyway. I just move that to the top of /app/index.erb.

BTW, I realize that another way of dealing with omitting unnecessary repetition of scripts and styles in <head> with JQM is to check the HTTP headers for Ajax requests. That could be done in layout.erb. But I also want to gain the advantage of having an empty startup page, because jQuery Mobile never lets go of that first page. If you were to ever use WebView.navigate, set window.location, or use data-ajax="false", then checking the HTTP headers would be an alternative.

By default, Rhodes omits using layout.erb for Ajax requests. I had forgotten this! I was trying to omit <head> in layout.erb for jQuery Mobile non-ajax pages, and finding that layout.erb wasn't being used at all!

This means actually, that jQuery Mobile pages are being served without <head> (good) unless they are data-ajax="false", or you used WEbView.navigate().

This is good, but it means that the document served isn't quite right for jQuery Mobile. It will work, but... it's not quite right, because then <html> is missing, <head> and <body> are missing. I don't know if there is some negative consequence to this. If you did intend to set <title> (not sure how you might use this) that is the one part of <head> that jQuery Mobile extracts on Ajax requests, and so you wouldn't be able to set that.

You can force Rhodes to use the layout on Ajax requests - but, as far as I know, not for the application-level index page, because it is special and doesn't have a developer-accessible controller. So, no way to override the default render behavior.