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

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

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

sure

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.

We modified login_from_session in login_system.rb to check for the session cookie before accessing the session object. This prevents the session from being created.

Please send a patch and specs!

i solved it for now by changing User.find(session['user_id']) rescue nil to User.find(session['user_id']) rescue nil if cookies.size > 0. unfortunately i can't get the specs to run without a few hundred errors currently so can't really offer a spec.

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)

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

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?

Everything but the configuration has been prototyped now.

+1

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.

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).

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.

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).

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)

(commenting mostly so i get emails about this)

here is how ray has handled this for a while now:
http://johnmuhl.github.com/radiant-ray-extension/#extension-dependencies

i tried to keep the barrier to entry low enough that end-users could fork an extension and contribute a simple self-contained patch back to the maintainers. it can cascade nicely so extension A can depend on B which can depend on C and on and on.

if there is any way to make the mechanism the same between ray and script/extension that'd be great; and i'd be willing to change ray if a better way can be found.

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

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

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