radiant:update:configs now updates instance config/environments. Closed by 7aaa2da

I can't reproduce this failure. Also, the expected and actual do appear equivalent.

Require Cucumber version 0.3.9 or greater from cucumber.rake Closed by b718dd6

This works for me on edge.

right-o must have been fixed since i reported it.

done!

Merged. Thanks!

Properly check for existing page parts when creating a new part. Closed by 6f7676c

This is on my radar. I'll check it out.

Store config_cache file in tmp. Closed by 981c1d6

it seems to break if you upgrade an existing site that doesn't already have a tmp directory, maybe the radiant:update task could make sure the folder exists

I suggest you alter the script to suit your application path. Just make it '/radiant/admin/pages'

thats what i did. i just wanted to raise this here so that people would know. i think radiant should make a statement on whether suburi installations are supported or not. if they are, this is a bug that needs to be fixed. if they aren't thats cool, we could just set up a wiki page which describes this (and maybe other) issues that you have to deal with if you try it anyways...

Considering that this is a static file, I don't think there's much we can do. If there are other issues related to this, please do submit them. Or feel free to create a wiki page.

You may submit issues here: http://github.com/radiant/radiant-mailer-extension/issues

Posted in the wrong place, sorry.

this one is already fixed by seancribbs, I guess (POST and cache as keywords ...)

Verify that the cache directory exists before trying to store a response. Closed by 3682d66

Fixed.

Also added "Removing X..." messages when deleting pages, snippets, layouts, and users

prevent admin from removing own admin role. Closed by 05e8c3b

Awesome. Thanks man.

Fix page-part deletion in JS. Closed by 209c327

Undefine prototype rake tasks in instance mode. Closed by b3a4b69

Well, I agree that "hidden" pages should not show up in queries made by tags (like <r:children>) in dev mode, but also believe that they should still be accessible via URL.

Closed in favor of #34

Properly display errors on user password changes. Closed by d4c6714

Slight change, the syntax for adding and selecting should be the same so we don't have to worry about dependency checking.

Instead of add_tab we'll just use tab

I'd suggest that we make add_tab an alias of tab. That way we can still reveal the intention.

Where are we on this, btw?

Updated with 3f6a102

This is non-trivial and will need to wait until there is better support in Rails for switching out the database layer.

I'm going to close this one for now. Feel free to reopen it if this ever becomes a serious option.

<r:navigation> defines its own <r:link /> tag which is different from the default. This is by design. If you need to use breadcrumbs within this scenario, consider using something other than <r:navigation>.

Or... can you explain why you would want to use the breadcrumbs tag inside of the navigation tag?

I wanted conditional breadcrumbs - essentially, if the page was one of my "heading" pages, do not display breadcrumbs, if it was a child "content" page, display them.

I've managed to work around the problem by displaying breadcrumbs for every page except the home page using <r:if_parent>, so my issue is moot. I suppose it's a case of me using navigation for something other than its intended purpose, so whether or not this should be considered a "bug" is a matter of interpretation! :-)

Yah, we never intended for it to be used that way. Interesting use case though. I am going to close this ticket for now.

do you mean --path=? i just tried the master branch with script/server --path=r and there seem to be a lot more problems than what you describe (and expanding/collapsing children was not one of those problems). or are you using passenger's option to run from a sub-directory?

yes, my bad, --path or -P that is, same applies when running radiant using passenger with RailsBaseURI. I haven't tried to run that from the trunk, but checked sitemap.js it's a bit different than in 0.8.1

at some point i thought it's not very important to run radiant under a prefix/namespace but realized that i have (example):
- domain.com/site (raidant) - domain.com/app1 (rails app1) - domain.com/app2 (rails app2) etc.

i have proxies (entry point) and they decide how to route traffic for different apps, and this way apps can reuse css from domain.com/site

Please test the master branch as of this commit http://github.com/radiant/radiant/commit/047f9d9da01890116e6abb669347f2145a4bb6a5

If you have any further problems, please report them here. Otherwise, let us know if the problem is solved and we'll close this ticket

looks good to me

Closing

Do you have time to troubleshoot this John?

sure. can anyone confirm the broken tabs on their ie8?

fix page part tabs in IE8. closed by f63997b

I've had problems with this too! I don't know or understand Radiant enough to create a patch, but it seems that Radiant will need to somehow use Cucumber profiles and get rid of this feature_pattern.

Otherwise, couldn't the Radiant source somewhere say:
gem 'cucumber', '< LOWEST_NON_WORKING_GEM_VERSION_NUMBER' (i.e. 0.4.0 or something?). Looking at my pickaxe page 230 it shows such an example which uses < 1.0 and so the gem loader will essentially consider only the version < 1.0 that's on the system even if higher version are also available. This would allow us to keep our 0.4.+ version of Cucumber, and simply install an additional earlier cucumber and all would be (at least for now) solved.

Actually I just added this inserted into line 4 of cucumber.rake:
gem 'cucumber', '0.3.104' And it just worked! Of course first I had to do:
sudo gem install cucumber --version '0.3.104'
which appears to be the version just before 0.4.0
My hack is horrible as it uses a specific gem version. I think the less than gem 'cucumber', '< SOME_VERSION' is better for whoever would want to put a 'band aid' on this until Radiant gets properly patched.

I've updated master to the latest cucumber, although the features no longer pass.

commit picked up. Closed

Actually closed then.

Possibly. I think that once we have radiant broken into a couple of gems, with a standard mechanism for creating a distro gem and installing using it, that might be the time to introduce something official like this to the registry. I'm closing this for now.

I re-implemented Radius parsing in Treetop and it was 27% slower. Based on my experience with RedCloth, I thought Ragel's generated parsers were slow and inefficient, but I guess not!

Last time I checked, though, Ragel parsers in Ruby weren't 1.9 compatible.

I did some benchmarking on this to determine if it's even worth doing. I think I could make it fairly elegant and out-of-the-way, but is there lower-hanging fruit? The research:

Given a parent with 50 children, each of which has two page parts...

1. A regular page.children.each {|c| c.part('body') } (repeated ten times after a rehearsal cycle) takes 0.68 seconds total.
   
2. Eager loading, including just the body parts with the children takes 0.34 total.
   
3. Eager loading all parts associated with children is 0.54.
   
4. Of course, with eager loading you also have to find the part in child.parts array. Otherwise, child.part('body') does a separate SQL query and then eager loading is worse (0.91).

Eager loading with only the needed parts of children (#2 above) is better than non-eager-loading (#1) when number of children is > 3. Without conditions specifying which parts to eager load (#3), there must be > 5 children.

So, if I could have children tags look inside and determine which associated page_parts, attachments, or other children to eager load, I'd save 340 ms--no small amount when optimizing the load time of a page! Just identifying that parts need to be eager loaded saves only 140 ms and the threshold for number of children is higher, so it will save the average page load a lot less than I'd hoped.

The code for a children:each tag to look for other children:each tags or content tags within itself wouldn't be so hard, but building the nested conditions to achieve the efficiencies of #2 would be quite difficult. The code looks like this:

@page.children.find(:all, :include => :parts, :conditions => {:page_parts => {:name => 'body'}})

The benchmark I used can be found at http://gist.github.com/216206

I closed this issue because it would be so difficult to do. Wish it weren't, though, because the speed of some of my complex pages is really annoying!

oops, i guess i accidentally pushed this to radiant/radiant. just revert it or tell me to if you want it reverted

@johnmuhl, can you work on this? I was contemplating reworking this to use a single div with the rounded and opacity SASS mixins.

sure

this may be fixed (I haven't checked IE yet) but the old status.js was looking for images in "/images" and not in "/images/adimin". This has been changed to look in the proper location.

I can verify that this works in IE8, but there is a gap between the right corners (top and bottom) and the middle of the box. see http://bayimg.com/PajIcaacB

Jim, there wasn't any reason to update status.js to look for them in a different dir. The file application.js should have been handling this. It is loaded after status.js and applies the correct path.

BTW, if you make changes to the Javascript please make sure that they are copied over to the prototype. It's better to work on Javascript updates there.

Sorry John, you're right. I'm working too late. I'm removing the changes to popup.js and status.js.

I'm trying to solve problems with relative_url_root and I hadn't found a way to handle that in the prototype with serve. But I do have changes to push there.

I think the prototype needs a branch that tracks what may currently go into Radiant's master. I don't want to pull in anything that is half-baked. Is there a place where the status of the prototype is being tracked (as far as what's valid for the latest Radiant)?

the current master is not working any differently for me in ie 7 or 8. looks like i forgot to note that it only gets messed up in ie 8 when you're deleting a page (or snippet or layout or whatever). both "creating..." and "removing..." overlays are broken in ie 7.

John, can you check this again? I believe I fixed it with the recent status.js update, although there appear to be a lot of other issues with IE 7 & 8 (not status message related). For one, I couldn't even login with IE 7.

Just verified that this is indeed fixed. I'm closing it.

That's very strange. Are you using the radiant with any extensions?

I'm guessing that this has something to do with running Radiant in a sub-directory. andreash, do you have more detail on this? I'm inclined to close this bug otherwise. It's a month old with no further comment after jlong asked for more detail.

I'm closing this for now. Feel free to reopen it if you are still having issues.

Closed with 8e39e0e

Could you elaborate? Where would this be beneficial?

for people who tab through the interface instead of pointing and clicking

Would a simple underline or removal of the underline on the link work?

in some cases. but what about the interface tabs? would you add an underline to "Content"? i was thinking that you'd just duplicate the :hover styles throughout.

Duplicating the hover styles sounds good. Can you work this out in the prototype and then copy it over into the app?

sure

having tried implementing this in the prototype it's clear this requires altering more than just :focus styles so is probably best done as an extension.

Apart from the :focus styles, what else is needed?

the main obstacle is stopping textareas from capturing tabs as that prevents a user from ever being able to tab out of the textarea so my thinking is that there is no reason to have any focus styles if the interface is not actually navigable without a mouse.

I'm not sure. I tend to think that focus styles are nice even if the focus gets trapped on a textarea. Someone suggested that we make Ctrl+Tab get you out of a text area.

they're certainly nice but i don't think they're particularly interesting unless you can actually use the interface without the mouse. as it is you can't even save a page without dragging out the mouse. it seems to me users with limited mobility would be quite frustrated by not being able to save their changes regardless of how nice the focus styles look.

i'd certainly be willing to work on this further if there were a way to escape from the textareas using control+tab (or whatever keyboard only method) but without that i just don't see much point in spending the effort as a keyboard only interface seems most beneficial to those who actually can't use the mouse.

try http://github.com/spanner/radiant-paperclipped_uploader-extension

We do have plans for an asset manager. It has yet to be implemented...

If I can comment, doing semicolon or ampersand make something unportable.

There are several ways to do this:

• Using FileUtils.cd witha block, to ensure path get restored after execution
• Build better command lines that output to the target directory instead of requesting cd into it

For the second option, Git and Subversion allow the last parameter be the target directory.

If you ask me (which no-one did) I would say FileUtils fits better than shelling out in a non-portable way.

Cheers.

This should be fixed now.

this seems to be invalid. I can't recreate the problem I saw before.

There is no reason why you have to use the r:title tag to create your HTML title. You could also use the existing "description" or "keywords" fields for those purposes. My point is, this does not seem compelling enough to change.

description should be used for meta description, keywords should be used for meta keywords. Why should I use this fields for meta title? Another solution is to change "breadcrumb" field to the "Meta title" field, and use it for this purpose, but this way it will be necessary to change "<breadcrumbs>" radius tag to use Title for breadcrumbs menu generation.

I was just proposing potential solutions, not best practices. If it's really important to you, I suggest you write an extension that adds an "SEO title" field or something like that. Again, this is not enough of a problem to change the core behavior and confuse the larger user base.

Actually Sean, this is an interesting suggestion. Sometimes I've also been bothered by excessively long titles in the site map. (I think you may have missed his point.)

Agree, and the only thing, that needs to be changed is "radiant/app/helpers/admin/node_helper.rb".

Currently functions is the following:
def node_title

%{<span class="title">#{ h(@current_node.title) }</span>}

end

I understand the problem exactly, John, I just don't think using the breadcrumb is the solution. You'd also be potentially confusing and alienating tons of existing users. -- "Huh? I just changed the title, why didn't it save?"

Another more logical solution is to leave Title as is and replace breadcrumb field with "Meta title" field. But this way it will be necessary to modify "breadcrumbs" tag to use "Title" field instead of "beadcrumb" field. This way "Title" will be considered as breadcrumb/sitemap/navigation title, and "Meta title" will be considered as browser page title (SEO).

On further reflection I sympathise, but tend to agree with Sean on this one.

The addition of the description/keywords fields was a half-baked attempt to help some people with SEO. Perhaps we just need another field, or we need to get "page attributes" rolling.

I'm in favor of the latter.

See also: http://github.com/radiant/radiant/issues#issue/76

Fixed in edge

http://github.com/radiant/radiant/commit/8586974f730eeba81c84b635ebf7a4c2e38dc26e

Good catch. I deleted styles.sass.

show password fields with new user. Closed by 4b3dd86

Drag and drop would be awesome.

I am at a loss here. I'm using radiant 0.8. I might be wrong but AFAIK, but the order of page parts wasn't important. How do people plan to use ordered page parts?

I second this

come on! a cms in version 0.9 without any internationalization its just useless ... no?

Definitely something I would consider a "must have" for 0.9.0.

Internationalization was originally scheduled for after 1.0

I agree with jlong. There is no need to bake in i18n right now. Once radiant is feature complete wrt other CMSs, then i18n can be attempted.

Really? There have already been 3 occasions for me where I have been unable to recommend Radiant due to lack of internationalisation. I also believe questions about it pop up relatively regularly on the mailing-list [citation needed]

Regardless of the original Roadmap I think the sooner internationalisation is in Radiant the better.

My $0.02

Keith Bingman has shown that i18n is achievable in the near term. If you want to see it happen, don't complain, contribute.

@rurounijones: I agree i18n is better than no i18n. But when there are important features waiting to be implemented, one must focus there. Especially so if resources in terms of developers and contributors (translators even) are limited.

I have it basically working with the Blade interface. Please give me a hand and we can get it in for 0.9. Monday I will be tackling extensions with a friend of mine. i18n is not that hard and very much needed as soon as possible.

as a european user, internationalization is indeed an important feature. I also have a project coming that would benefit from this.

I18n is also a very important feature for me as a european user. Without it, it's hard to sell radiant to non english speaking customers ...

But it would not be a good thing if I18n was integrated without proper thinking. You guys have done a great job so far, so keep the good pace, I trust your judgment.

Please check out the i18n Branch. It should be working with the Blade interface now. And we have translations for German, Russian, Japanese and French. I am still looking for especially Spanish and Italian and really anything else. You can fork the Branch and let me know.

Does this allow extensions to provide translations for any UI components that they add?

Unfortunately, no. But I think I know how and that is the next thing to do on my list. I should actually have time this weekend. On Monday, my boss and I want to pair up on it, we need it for a site we are doing, so that should help.

However, this is an area where I need some help.

looking at this link, I think this should be pretty easy. If I remember correctly, Spree has a very similar extension system. You can specify multiple load paths, which is basically all we need. I will look into it tomorrow.

http://spreecommerce.com/documentation/i18n.html

Keith has committed to taking this bull by the horns, so internationalization is now part of the official commitment for 0.9.0.

This is a great news !

nice to hear that! if you need a german translation I am willing to contribute :)

If you'd like to contribute, fork the i18n branch and submit pull requests to kbingman.

jlong:

Does this allow extensions to provide translations for any UI components that they add?

Just done i18n for paperclipped on i18n branch. Everything is translatable.
http://github.com/antono/paperclipped/commit/5b778abe136978b547e078fcfef941b3da6db142

i18n seems to be enough stable but need rebasing on master branch.

I did it in the prototype. Check it out. Still quite rough, but I didn't want to go too far without others' buy-in.

Any feedback? I still need to:

• Rework link and image insertion code from the textile_editor extension. Currently disabled because it had a namespace conflict.
• Add Markdown support
• Fix a few insertion bugs
• Generally refactor the whole thing :-)

Quite a bit to do yet, so that's why I'd like to hear if you like the direction it's headed before I continue.

Backed out some things that jlong and I had talked about:

• Returned popups to their original, non-expandable form
• Turned filter and tag references back to text links.

This should be cool. Will reduce the guess work for new users.

I'd prefer a more general purpose approach to this. I've barely worked on this in a "browser" extension but I think there should be a way to add snippets, or assets, or anything else that an extensions adds.

By all means, pull something together and we can discuss it

Jim, what would you think of taking the toolbar that textile_editor adds and generalizing it so it's just a toolbar and common API that any extension can use? The advantage of that is it already has code for wrapping highlighted text with stuff (in this case, a radius tag). I can work on it too if you want.

This might be an option: http://livepipe.net/control/textarea I like some of the functionality of textile_editor_helper better, though.

This is cool, but it's jQuery: http://markitup.jaysalvat.com/home/ Might jQuery be in Radiant's future?

Check out this UI mockup: http://www.twitpic.com/jtf3z/full

I'm imagining the snippet button would open a popup listing the snippets with a little disclosure triangle to peek inside the snippet in case you forget what it does. Clicking the name inserts/wraps the snippet and closes the popup.

Similarly, the radius tag button opens the tag reference popup except descriptions are hidden with disclosure triangles. Click the name to insert/wrap the tag and close the popup. Roughly, http://www.twitpic.com/jtfsr

The help icon is for filter reference. Not the most intuitive. Needs more work.

That's the basic idea idea Jason, just a few less buttons. :) Do you want to work on this? Could you get it worked out in the prototype first?

I was thinking that the API for filters could be something like this:

class BlahFilter < TextFilter
  ...
  def bold
    '<b>%{text}</b>'
  end
  ...
end

If the "bold" method was defined the button would show up on the toolbar.

Sure. I'll take this on.

Keep in mind that there is actually another ticket for the toolbar (#26).

Check out http://github.com/saturnflyer/radiant-browser-extension in a pre-blade version of Radiant. It just inserts an area to the right where I planned to list assets/snippets (and the whole thing is very rough).

I think something like that would be better than an overlay because the overlay gets in the way of editing text which is one of the problems with the current tag reference: I can't edit my text while I read the reference. By putting it to the side, it would be easier to read and edit as well as do drag and drop into the editor.

Took awhile to get it working, but I was able to see it eventually. Yes, it would be nice to be able to read the reference while you work on a tag. I think most of the time, though, users (at least my myriad nontechnical ones) will want it out of their way.

So maybe what you're suggesting is that the popup appear beside the textarea? If it were normally hidden and came up beside the textarea only when needed, I could get behind that. Presentation of the popup like a separate issue, though.

Wouldn't it be cool if it would read the tag's available options and let you build the tag with a form? Now I'm getting really far off topic! :-)

Popup.js includes support for draggable windows. It would be trivial to enable this.

I added it as part of a toolbar in the prototype. Check it out. Still kind of rough, but I didn't want to go too far without others' buy-in.

Any feedback on this, yet? Tag insertion is unimplemented so far. I'm thinking it could be simple: If you have text highlighted, it wraps the text in that Radius tag. Otherwise it just inserts the tag self-closing.

I've only been able to take a cursory look, but it looks good. The reason I'd prefer an insertion to the side of the textarea is because it keeps the reference out of the way. Even if it is draggable, it still may cover an area that you'd want to be able to read while looking at the help window. I think, however, that this could be something that we try as a draggable window and see how people like it. But I'd personally be quick to hack some configuration to allow it to be docked.

And I think the window ought to have some way to select other options. For example, there is not much difference between a snippet and a radius tag and I can see a situation where a user would want to insert something, click on the radius icon, then remember that it's a snippet, close the window and open the snippet window. If it had some internal navigation for additional options, it'd be easy to add something to include site assets too. So I guess by that measure the image icon could open the window with the assets pre-selected.

I want to add something that references the available options for the radius tags so that we'll be able to include that in the code as in this branch http://github.com/indexzero/radiant/commit/794a5c22a32560a6ed46d4f2984494226a553a9c (although I plan to clean that up a little)

Like "View page after saving" checkbox in Chronicle? Seems like you'd only ever want to preview after saving.

Or do you mean like the View Site button that's been in the upper-right corner forever?

More like the "View Site" button I think

Sounds good.

I'd think we'd want button/link to view on the live site as well. More often I've just wanted to open a window for the page I'm editing.

But I think this could get tricky if labeled "preview" considering the possible meanings of that, such as "view before saving".

Maybe "View Site" could be a flyout menu giving options for viewing the page on dev and live.

I've been using the radiant-concurrent_draft-extension for this feature. It definitely gets the job done but is a bit awkward in a few areas.

http://github.com/avonderluft/radiant-concurrent_draft-extension/

My branch (that I've made work on edge) is at:

http://github.com/dayne/radiant-concurrent_draft-extension/

concurrent_draft's awkwardness comes primarily from specific needs that Con-way had in their customized Radiant. The concepts should transfer well, but I'm also leaning toward chronicle's way of working with this.

Is this up for discussion to be included in core? We / I have found that every client/team has different workflow and revisioning needs. So I'd prefer enhancements to the current implementation be in an extension.

Creating more places for those extensions to hook into Radiant to add these behaviors, could be important - but I don't know if that is a problem with the current set of workflow extensions out there.

whistlerbrk: I perceive that the core team is committed to keeping core down to the barest essentials, so don't worry. This enhancement is really filling a gap that's been there from the beginning. Unless your workflow is, "when we are working on a published page, we give visitors a 404 page for a few hours," then you won't even notice this enhancement if you don't want to. (a little humor there).

All this enhancement will do is let you change the status of a published page to draft without the page disappearing from the live site. The page then shows in its published form on the live site and in its draft form on the dev site. If you don't want to take advantage of that, never switch a published page to draft--which you wouldn't have done without this enhancement, I hope. There'll be no revisioning or other changes to workflow.

Oye, I completely misunderstood the ticket, you're right of course, sorry!

jlong and I talked about putting an API in core so that concurrent_draft, chronicle, page_versions, and any other extension can do its work more easily. Sounds like a great idea to me. I've changed the title of this ticket to reflect that.

multi_site would also fit neatly into this API category. I'm supposed to talk with Will Ross at Spanner about it sometime. Wouldn't it be neat if there were enough underlying hooks in core that extensions like chronicle and multi_site wouldn't conflict with each other and wouldn't require custom versions of about every other extension?

I'm not necessarily sure that it's related, but I have a vision of making extensions more declarative and less imperative -- allowing essentially hooks into the internal API rather than direct modification via #activate. This would allow us to potentially serialize customizations and reduce the number of conflicts.

I want to hear more, Sean! Either write it up somewhere or let's Skype in the near future.

Will and I had a nice chat on Skype. I'm going to make a branch to work on it. We'll have extensions just declare what validation and finder scope they need for pages. Multi_site can declare site scope. Draftable can declare status scope. They can all play together nicely as long as Rails' nested scopes work as advertised.

("Draftable" is my plan to split that simultaneous draft functionality out of Chronicle into its own extension. Then Chronicle can just handle versions)

Everything but the configuration has been prototyped now.

Yah, definitely. Please work on this.

i doubt ray will offer any possibilities really. the version compatibility in it was written to address the specific use case saturnflyer had and nothing else (and that was a quick hack). not to mention the philosophy behind ray and radiant's built-in extension management is pretty drastically different.

personally i'd like the version compatibility to not be tied to the extension registry so that ray could use the same information to handle this better than the current implementation (and not add even more manual labor to maintaining ray's extension list).

This may be solved here http://github.com/jfrench/radiant/tree/extension-gems

Needs specs though.

+1

What about just creating the empty region "bar" and changing add to check if it is empty, and if so, replace it with the one being added (else, error)?

Which is what the patch I sent out essentially does, but it felt dirty.. I can / will clean that up.

But as a whole, updating the region sets would be nice.

This is something else I've run into:

` %table.index - @weights = [] - render_region :extensions_model_columns do |columns|

- columns.name do
  - @weights << 4
- columns.description do
  - @weights << 2
- columns.controls do
  - @weights << 2

• @weights.map{|x| x*(100/@weights.sum)}.each do |width| %col{:width => "#{width}%"}

...

%tbody

- if @my_models.any?
  ... display ...
- else
  %tr{:class => "empty"}
    %td.note{:colspan => admin.my_extension.index.length} No Records!

`

Ideally an internal variable could keep track of the 'weights' so there is a known pattern for extensions to cleanly add a column to a table w/o screwing up table sizes. The implementation above has worked for me, but I know it breaks down (as described above) when a region set is overridden (as it renders regardless and will add weight to @weights)

sigh markdown

http://pastie.org/639671

custom events should probably be fired from the tab control that can be trapped by other javascript

i have focusing on the associated textarea when clicking a tab working but was wondering if there a preference for placing the cursor at the beginning or end of the textarea.

also i don't understand what the focusing has to do with custom events...i just hooked into the select function which captures clicks on the tabs. surely i'm missing something here.

Do we need to worry about where the cursor is? Don't text areas keep track of that information on their own? What happens by default?

About the custom event comment: I was thinking that the TabControl object could fire a custom event like "tab:selected". You could then trap this event in other javascript (specific to page parts) to focus on the textarea.

But perhaps a custom event is not needed in order to make it generic. The code could just set the focus on the first select, input, or textarea within the tab control. I'm guessing that if we used the tab control in other places that we would want it to work in the same way.

By the way, in regards to the TabControl code being as generic as possible, I think some parts specific behavior has snuck in their recently. We should do what we can to remove that if possible.

i don't see any browser that tracks the cursor position between changing tabs; my guess is that the cursor is left in the hidden tab when you change.

the default behavior for textarea.focus() is to place the cursor after the last character (at least in all the mainstream browsers i tried).

We used to use session :off in the SiteController, but that has been deprecated. I believe the answer is to remove SiteController and create a Rack middleware to serve pages.