[ANN] "Shards" extension

[Sean Cribbs]

It's been a long time coming, but here it is.

** The facets branch functionality is now available as an extension! **

http://dev.radiantcms.org/svn/radiant/trunk/extensions/shards

The latest contract I've been working on is using Radiant, and they
needed this functionality. The extension will work on 0.6.2, but I
highly recommend using edge for the sake of bugfixes.

There have been some significant changes in the API that I should warn
you about if you used the facets branch before:

* 'facets-lite' is still supported. Existing extensions that use this
should not break.
* Some of the region names may have been changed or added.
* There are no more 'plain' partials. Everything exists in a region or
is rendered directly from a template.
* Use content_for :page_scripts and content_for :page_css to insert
inline Javascripts and CSS, respectively. content_for appends to its
result anyway, so it was not necessary to keep 'additional_javascripts'
and 'additional_styles' in the API. If you have external files, you can
still use 'include_javascript' and 'include_stylesheet'.
* Regions are still accessible from the 'admin' object, but are accessed
like so:

# The RegionSet for the page edit screen.
admin.page.edit

# The array of partials in the 'main' region.
admin.page.edit.main
admin.page.edit[:main] # equivalent
admin.page.edit['main'] # equivalent

# Adds the 'foo' partial to the main region, before the 'edit_form'
partial
admin.page.edit.add :main, 'foo', :before => 'edit_form'

# Adds the 'foo' partial to the main region, after the 'edit_header'
partial
admin.page.edit.add :main, 'foo', :after => 'edit_header'

* Regions are blank by default, so you can reference a region without it
being pre-existing.
* Any controller/action may have regions that are rendered. These are
determined by the controller name and template name. See the
implementation of the 'render_region' helper for details.
* If you want to add your own controllers and actions/templates, add an
attr_accessor to Radiant::AdminUI with the controller name, fill that
attribute with an OpenStruct, then assign Shards::RegionSet objects to
the struct by template name. For example, if I have an "events"
controller and I want to add regions to its "index" template, I would do
this in the 'activate' method of my extension:

Radiant::AdminUI.class_eval { attr_accessor :events }
admin.events = OpenStruct.new
admin.events.index = Shards::RegionSet.new

You can pass a block to RegionSet.new, which will yield itself to the block.

* The only pages that can be modified out-of-box at the moment are:
- Page edit/new (as before)
- Page index (limited)

The core of the API is pretty solid and well tested, but I would
entertain any patches that extend the reach into the other areas of the
administration interface.

Cheers,

Sean

[Jomz]

Hi Sean,

Could you elaborate this a bit more please?;

* Use content_for :page_scripts and content_for :page_css to insert
inline Javascripts and CSS, respectively. content_for appends to its
result anyway, so it was not necessary to keep
'additional_javascripts'
and 'additional_styles' in the API. If you have external files, you
can
still use 'include_javascript' and 'include_stylesheet'.

I'm trying to load some extra javascripts into the page edit screen,
but can't figure out how. I used to do it from the .rhtml, but the
point in using shards is not needing to overwrite anymore .rhtml's,
right?.. Is this doable from within an extension's activate method?
how else?

[Sean Cribbs]

The first point is that you can use content_for many times and it will
just append the content you put inside the block. So you don't have to
worry about one content_for block overwriting what another added, even
if they added to the same capture area.

In both cases, either with content_for :page_scripts or
include_javascript, this should be done inside a partial. You can add
the partial to any part of the screen you want to affect by using the
admin object in your extension. For example, if I have copied the
lowpro.js file into public/javascripts and I want to use it in the
page-editing screen, and I have some other scripts that I want to
include too, I would do this:

# In the extension

def activate
admin.page.edit.add :main, "my_partial"
end

# in app/views/admin/page/_my_partial.rhtml

<% include_javascript 'lowpro' %>
<% content_for :page_scripts %>
window.myAlert = function() { alert("Hello, world!"); };
Event.onReady(window.myAlert);
<% end %>

That would the job of both adding the javascript include to the header,
and the inline script to the main <script> block in the header. Hope
that clears things up!

Sean

[Jomz]

Jep, crystal clear, thanks!

[Jomz]

One more thing though; the spinner does not dissappear when it should.
I get following js error on line 1317 of prototype.js

too much recursion
showBranchInternal(tr#page-1.node, img.expander
collapse.png)sitemap.js (line 116)
showBranch(tr#page-1.node, img.expander collapse.png)sitemap.js (line
124)
toggleBranch(tr#page-1.node, img.expander collapse.png)sitemap.js
(line 164)
onMouseClickRow(click clientX=0, clientY=0)sitemap.js (line 22)
bindAsEventListener(click clientX=0, clientY=0)prototype.js (line 112)
[Break on this error] return value.apply(null,
[this].concat($A(arguments)));

and after that it keeps giving recursion too deep errors

Any clue? perhaps it's related to the recent update of prototype.js?

[Sean Cribbs]

Jomz,

I had this problem until I reverted Prototype to 1.5.0.  Please freeze to 0.6.3 or edge and then run rake radiant:update.

Sean

[Mislav Marohnić]

On 10/11/07, Sean Cribbs <seanc...@gmail.com> wrote:

Jomz,

I had this problem until I reverted Prototype to 1.5.0.  Please freeze to 0.6.3 or edge and then run rake radiant:update.

Sean,

This error in Prototype usually indicates that you're using an older version of Scriptaculous with Prototype 1.6.

[Sean Cribbs]

Right.  At the time it was easier to revert to 1.5.0 than to figure out which version of script.aculo.us to use.  I imagine we'll upgrade in the near future.

Sean

[Damien McKenna]

On Oct 11, 2007, at 10:09 PM, Sean Cribbs wrote:
> At the time it was easier to revert to 1.5.0 than to figure out
> which version of script.aculo.us to use. I imagine we'll upgrade
> in the near future.

Should that be decided by the revision of Rails installed? As such,
should Radiant be tied to a specific release of Rails (svn externals)?

--
Damien McKenna - Husband, father, geek.
dam...@mc-kenna.com - http://www.mc-kenna.com/
http://twitter.com/DamienMcKenna
http://www.linkedin.com/in/damienmckenna

[Sean Cribbs]

Damien McKenna wrote:

On Oct 11, 2007, at 10:09 PM, Sean Cribbs wrote:
  

At the time it was easier to revert to 1.5.0 than to figure out  
which version of script.aculo.us to use.  I imagine we'll upgrade  
in the near future.
    

Should that be decided by the revision of Rails installed?  As such,  
should Radiant be tied to a specific release of Rails (svn externals)?

  

Damien,

Radiant (trunk) is currently tied to 1.2.4 using Piston (0.6.3 use Rails 1.2.3).  In fact, all of Radiant's dependencies are managed with Piston, which is a good way to go for projects that want to reduce gem-dependency hell.

Sean

[Jomz]

Sean,

Could you perhaps add 'enctype="multipart/form-data"' to the page edit
form?
Afaik there are no drawbacks to this, and the page attachments
extension needs this to work.
I could just do this myself, but i'd prefer staying with a
svn:external

Regards,

Benny

[Sean Cribbs]

That's not there already? Wow, I'll make sure it gets in.

Sean