Ruby Forum Radiant CMS > [ANN] Styles 'n Scripts Extension

Hello all.  John had asked me to create this some time ago as a
proof-of-concept for an enhancement to the core of Radiant.  Well, it's
finally here and I would appreciate any and all feedback (directly or on
the mailing list) to improve this.

Note: this is a Rails 2.x/Radiant 0.6.6 extension and it won't work with
previous versions.


What it Does
============
Adds Stylesheet and Javascript objects to Radiant.  It should be very
self explanatory to use but it has some real benefits (like its own
caching mechanism to speed up server responses).  Check out the README
file for a list of features/benefits and usage.


Where to Get It
===============
I'm not running on git so you get to use good 'ol svn:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/v0.2


Thanks and enjoy!

Chris Parrish
Swank Innovations, LLC

This looks very nice Chris.

Instead of calling the tabs "CSS" and "JS" why not "Styles" and
"Scripts"? (Seems appropriate considering the name of the plugin.)

I'm getting an ActionController::InvalidAuthenticityToken exception on
the O.6.7 when I try and submit a form.

I'm also getting a undefined method `updated_by' for #<Javascript:
0x236d6c8> on 0.6.6 when I try to edit a javascript that I just created.

Have you taken a look at the prototype directory in trunk? We have a
working HAMl prototype there that you can play around with using serve.

--
John Long
http://wiseheartdesign.com

John W. Long wrote:
> This looks very nice Chris.
>
> Instead of calling the tabs "CSS" and "JS" why not "Styles" and 
> "Scripts"? (Seems appropriate considering the name of the plugin.)

Thought about that.  Just trying to be considerate of other extension
developers by conserving tab space

Also we had entertained the idea of putting the two items inside one tab
at one time (and even putting them all together with images onto an
"assets" tab).  Anyway, I wasn't too focused on any one name for now.

>
> I'm getting an ActionController::InvalidAuthenticityToken exception on 
> the O.6.7 when I try and submit a form.

Dude, I released this *before* 0.6.7.  Man, tough crowd ;-)

I haven't loaded 0.6.7 yet -- I'll look into it.

>
> I'm also getting a undefined method `updated_by' for 
> #<Javascript:0x236d6c8> on 0.6.6 when I try to edit a javascript that 
> I just created.

Thanks.  Looks like a last minute change + no spec coverage on view
(yet) = sloppy programmer.

I'll look into that too.

> Have you taken a look at the prototype directory in trunk? We have a 
> working HAMl prototype there that you can play around with using serve.

Not yet.  I remember you mentioning something about that idea several
months back -- glad to see it launched.  Sounds slick.

-Chris

I fixed the issue mentioned below.  The updated version can be found at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/v0.2.1

This fix solves the error but still does not properly register the
created_by_id and updated_by_id fields in Stylesheets and Javascripts
(which was tied to the source of the original error).

Does anyone know how to append classes to UserActionObserver?  I'd like
to fix this issue but if I have my extension's activate method call:
  UserActionObserver.observe Stylesheet, Javascript

it seems to wipe out the existing observation of Page, Snippet, etc.

The 0.6.7 issue will have to wait another day...

-Chris

On 5/17/08, Chris Parrish <chris.parrish-forummail@swankinnovations.com> 
wrote:
>
>  it seems to wipe out the existing observation of Page, Snippet, etc.

I had this same issue some time ago and you can take a look at how I
fixed it here:

http://mgr.devjavu.com/browser/audioguide/vendor/extensions/forum/forum_extension.rb#L34

>
> Does anyone know how to append classes to UserActionObserver?  I'd 
> like to fix this issue but if I have my extension's activate method call:
>  UserActionObserver.observe Stylesheet, Javascript
>
Yes, for some unknown reason, observe redefines the "observed_classes"
method instead of changing a class variable.  Go figure.

I would do something like this:

new_classes = UserActionObserver.instance.send(:observed_classes) +
[Stylesheet, Javascript]
class << UserActionObserver.instance
  define_method :observed_classes { new_classes }
end

Not sure about the scoping on that, etc, but that's the general outline.

Sean

I like your solution better, Martins.

Sean

Thanks for the quick responses you two.  I'll be able to look at things
this evening and hopefully be able to add a few new specs and the code
you so wonderfully provided.

I'll also take a look at the 0.6.7 error that John mentioned.

BTW, if any of you know (or think you know) what's up with that one,
feel free to send some guidance.  (I haven't even downloaded 0.6.7 yet
so I haven't seen the issue myself).

-Chris

Could someone work up a patch for this issue.

--
John Long
http://wiseheartdesign.com

Chris,

See attached patch.  Extension developers -- if you aren't using the
built-in form helpers in your views, please switch to them.  They will
automatically add the proper authenticity token to the form for you.

Sean

Sean, I got an attachment but it looks to only contain the mailing list
email footer.  Is the mailing list server whacking attachments possibly?

Could you send it to me directly or perhaps paste it into the body if
you want to share it with all...

Thanks,
Chris

All of the aformentioned bugs have been squished (with thanks going out
to Mārtiņš and Sean for the exceptional help). The latest tag of the
Styles 'n Scripts extension can now be found at:
https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/v0.2.2

It runs on Radiant 0.6.6 and 0.6.7 so far.

-Chris

I could get it run on a clean install  (0.6.7) tho, with sqlite3 and no
other extension installed

it gives Could not find table 'config' error

On 5/18/08, Chris Parrish <chris.parrish-forummail@swankinnovations.com>

I think this is a fault of Radiant. Could be wrong.

nurullah wrote:
> I could get it run on a clean install  (0.6.7) tho, with sqlite3 and no
> other extension installed
> 
> it gives Could not find table 'config' error
> 
> On 5/18/08, Chris Parrish <chris.parrish-forummail@swankinnovations.com>

The Styles 'n Scripts extension makes use of Radiant's built-in
Radiant::Config settings (which get stored in the config table).  So
this sound like a Radiant setup issue. (The only table my extension adds
is text_assets).

Remove my extension (all extensions, really) and make sure that your
plain-vanilla Radiant extension has this table created (should have been
created when you ran:
  rake db:bootstrap (or rake production db:bootstrap if running in
production mode).

-Chris

although all installation steps fail it adds tabs on panels and some 
columns
on config table


5|stylesheet_mime_type|text/css
6|response_cache_directory|text_asset_cache
7|javascript_mime_type|text/javascript
8|javascript_directory|js
9|stylesheet_directory|css

but you are right production.log says it cannot find text_assets table 
and
right there is no such table on db file




On 5/19/08, Chris Parrish <chris.parrish-forummail@swankinnovations.com>

Ok, so now that you have a running Radiant app, you now should do the
following to install the extension:

   1. Copy the Styles 'n Scripts Extension to the following path:
          radiant_app/vendor/extensions/styles_n_scripts

      You can find the latest version of the extension here:

      https://secure.svnrepository.com/s_swanki/open/radiant/extensions/styles_n_scripts/tags/v0.2.2

   2.  From your radiant_app directory, migrate the extension's db
      changes (adding the text_assets table).  Run:
          rake radiant:extensions:styles_n_scripts:migrate

      If you have any problems, run the rake task with the '--trace'
      option to show the details (and post them here).

   3. Finally, copy the images used by the extension.  Again, from your
      radiant_app directory, run:
          rake radiant:extensions:styles_n_scripts:update

      This doesn't sound like where your problem lies but, if you should
      have any problems here, run rake with the --trace option again.

Good luck and let us know how it goes and post any specific error
messages here.

-Chris

1)
nope that gave the same config error...

but this way it worked charmly.. thank you
rake RAILS_ENV="production" radiant:extensions:styles_n_scripts:migrate
rake RAILS_ENV="production" radiant:extensions:styles_n_scripts:update


p.s.: uncommenting ENV['RAILS_ENV'] ||= 'production' on 
config/enviroment.rb
dont help

2)

is there any way to call js/css files from anywhere of the page/layout?
suppose, i use one template and many subpages?
 but i use different/extra css/js files on subpages (and also common), 
for
example i will use accordion script on a subpage and putting this on
template or on header snippet is nonsense
so i am looking for a way to call these files from inside page/layout

> is there any way to call js/css files from anywhere of the page/layout?
> suppose, i use one template and many subpages?
>  but i use different/extra css/js files on subpages (and also common), for
> example i will use accordion script on a subpage and putting this on
> template or on header snippet is nonsense
> so i am looking for a way to call these files from inside page/layout

The way I usually do this is to put a content part in my layout's
header called "head-meta" that appears in the header, e.g.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
...other header stuff ...
<r:content part="head-meta" />
</head>

Then you can just add a part to the page called (what else) head-meta
and add whatever page-specific Javascript, CSS, meta tags, etc. you
might want.

Hope this helps!

Rufo

hmm, thats nice

but it can be good to inject css/js files from body part inside head

thank you

I played around with the idea of creating an <r:stylesheet> and
<r:javascript> tag or even enhancing the <r:content> tag to let you add
stylesheet/javascript content in addition to page part content.

The problem is that in either case you have to specify which file you
want (either explicitly or by first setting up a context to that item)
so why not just manually type it and save the noise of yet another
radius tag.

This case, however, has me thinking the other way.  (Plus the other
benefit that your users only need to know the name of the script or
stylesheet and not their full path -- my tag would build that).

I'm going to be putting out a new rev shortly -- it would be simple to
add a <r:stylesheet> and <r:javascript> tag.

I'd certainly welcome other ideas as well.


-Chris

nurilized wrote:
> is there any way to call js/css files from anywhere of the page/layout?
> suppose, i use one template and many subpages?
>  but i use different/extra css/js files on subpages (and also common), for
> example i will use accordion script on a subpage and putting this on
> template or on header snippet is nonsense
> so i am looking for a way to call these files from inside page/layout
>   
I just released version 0.3 of this extension and you will now find tags
to do just this. For instance:

  <r:stylesheet name="my_stylesheet" />

produces:

  your stylesheet content

Or, if you want to be more fancy, try:

  <r:stylesheet name="my_stylesheet" as="inline" />

and get:

  <style type="text/css">
  <!--
  your stylesheet content
  -->
  </style>

The same works with the <r:javascript> tag.

-Chris

I just tried out your extension.  Nice idea.  I've always liked how
the css file was exposed under pages but I really hadn't thought of it
having it's own section either.  Also, I've always wondered where to
put my js files.  I usually just tucked them in the javascript folder
and referenced them. This gives them a proper place.   I mostly only
use one stylesheet per website so it seems a bit overkill.  Not to be
stingy with my tabs, but I think I'd like it better if the css and js
pages were both under one tab.   I'm looking forward to seeing what
becomes of this extension.

Thanks,

Steven

Thanks for the feedback Steven.  I'm really interested in making this a
usable extension for all.

I always used pages for my js and css files too and, like you, never had
more than a handful of each -- it wasn't much of a bother to do.  So,
when John first mentioned the idea to me I really only saw one or two
valid reasons for such an extension (for instance, I found it difficult
to explain to users why they had to create a blank layout for a
stylesheet just to set the content-type).

Now that I've been working on it, I see *many* good reasons to go this
route (my current favorite is the server and browser caching benefits --
I *love* the idea of not having to expire and reserve all stylesheets
and javascripts every 5 minutes).

As to the multiple tabs, yeah, I'm with you.  Originally I think John
envisioned something like an "Assets" tab where CSS, JS and image files
could all reside but Radiant hasn't settled on an image asset approach
just yet.  And without images, what do you call the tab -- Text Assets?
CSS & JS?  Assets-That-Don't-Happen-To-Include-Images?  Actually, my
original mock-up for this extension had one tab (called "Files") but I
still kind of choked on that vague name.

Anyway, for now, John just suggested keeping two tabs and waiting to see
how things progressed.  In the interest of minimizing tab space, I did
choose to name them CSS and JS instead of Stylesheets and Javascripts.
Plus, your standard-level users never see the tabs anyway so it looks
clean to them.

I certainly welcome any ideas/suggestions here. Its a fairly
straightforward design but nothing's set in stone.

-Chris

I must admit that "assets that don't happen to include images"  is a
bit long.  I kind of like "text assets".  That kind of opens it up to
include other types of files that people may want to put there
like .xml or maybe even a .as file.  One thing that would be nice
about putting them together is that you could then make use of a "file
type" combo box.  That would fill out the page a bit and give a person
a little more to do.  Also those lovely icons would have a chance to
help you sort out your file types.

-Steven

good work, i appreciate your effort.

i dont know pitfalls.. but it would be better if we could throw csses 
and
javascripts between head tags no matter where they are called from..

secondly, looks like there is almost no difference between inline and 
other
way.. in inline mode it adds html comment tags other way just include 
the
way i write it if i dont add <script /> tags it just dumps everything to 
the
page.

it must wrap codes if there is no header tag

nurilized wrote:
> good work, i appreciate your effort.
>
> i dont know pitfalls.. but it would be better if we could throw csses and
> javascripts between head tags no matter where they are called from..
>   

Not sure I follow you.  What do you mean by "no matter where they are
called from?"

> secondly, looks like there is almost no difference between inline and other
> way.. in inline mode it adds html comment tags other way just include the
> way i write it if i dont add <script /> tags it just dumps everything to the
> page.
>
> it must wrap codes if there is no header tag
>   

Yeah, the as="inline" is a bit weak and I've already got a change to
remove the commenting and, instead put:
<script ... >
// <[CDATA[
  your code here
//]>
</script>

to ensure XHTML compliance (probably overkill for stylesheets but no
harm either).

The thought behind offering the inline version was that Pages are
accessible to your everyday users -- not just admins or developers.  So
they might not know how to safely wrap their scripts in CDATA (I goofed
it even) or they may not be sure of the desired content-type so the tag
automagically does it for them.


-Chris

> Not sure I follow you. What do you mean by "no matter where they are
called from?"

i called <r:javascript name=xyz.js" /> from the content form
and it dumped everything in the place where i called it (inside body 
tag)
but i say it would be better if it is placed  between head tags (but 
there
could be some pitfalls to do this tho)


 also why not add a feature that will give just the src link for js/css
files
am i missing something?

nurilized wrote:
>> Not sure I follow you. What do you mean by "no matter where they are
>>     
> called from?"
>
> i called <r:javascript name=xyz.js" /> from the content form
> and it dumped everything in the place where i called it (inside body tag)
> but i say it would be better if it is placed  between head tags (but there
> could be some pitfalls to do this tho)
>   

Now I've got you.  First of all, this wouldn't be desirable all the
time.  There are plenty of times when you don't want your scripts to be
in the <head> section but in the <body> -- particularly in a certain
place within the body.

Now, to solve your need (I have the same one), here's what I've done:

In my layout:

<html>
  <head>
    ... some stuff ...
    <r:content part="head_scripts" />
    ... more stuff ...
  </head>
  <body>
    ...

and in your page you simply add a page part named "head_scripts" and 
insert:
  <r:javascript name="xyz.js" as="inline" />

and the layout will render the script for you and even wrap it in the
<script> tag.  You can also add other html attributes like <r:javascript
as="inline" id="myId" /> and it'll pass those into the <script> tag.

Of course if you needed more control you could put the following in the
layout:

<html>
  <head>
    ... some stuff ...
    <r:if_content part="head_scripts">
    <scripts>
    <r:content part="head_scripts" />
    ... some other scripts ...
    </scripts>
    ... more stuff ...
  </head>
  <body>
    ...

and in your page your "head_scripts" page part would contain:
  <r:javascript name="xyz.js" />

>  also why not add a feature that will give just the src link for js/css
> files
> am i missing something?
>   

You can do:
  <r:javascript name="xyz.js" as="url" /> and get the path to the asset
including the javascripts directory.

Or were you hoping for something like:
  <r:javascript name="xyz.js" as="link" />

that would yield:
  <script src="/path/to/xyz.js" type="text/javascript"></script>

Now that I think about it, the second solution would be ideal so that
you could use the same layout solution to insert a bunch of links into
the <head> section from a page part.  Hmmm.  I've got an updated version
that wraps everything in CDATA and also moves my templates to Haml.
I'll see if I can roll this into a release tomorrow.

-Chris

thank you

that was helpful.

I've just checked in a version (trunk -- not tagged) that adds
<r:javascript name="xyz.js" as="link" /> (same for stylesheet) which
renders a link to the external javascript or stylesheet.  Stick a bunch
of those in your page parts and reference the part from your layout.

I'll roll the whole thing into a 0.3.1 release some time tomorrow.

-Chris

why dont you git?

On 5/28/08, Chris Parrish <chris.parrish-forummail@swankinnovations.com>

nurilized wrote:
> why dont you git?

You guys are killing me.  John's pushing me there today too ;-)

For the record, I use Windows and Eclipse (Aptana's RadRails) to do my
development.  I'm used to, and like both very much.  Right now, I can do
all my source code control right in my IDE wonderfully -- visually see
which files have changed, apply properties, commit, update, etc.

Unfortunately git support is weak for Windows and weaker still for
Eclipse.  So I'm going to have to figure out a new workflow to use my
IDE and git as an external tool in order to make the switch.

It'll probably happen eventually but I've got enough irons in the fire
already for now.

-Chris

On May 28, 2008, at 1:15 PM, Chris Parrish wrote:
>
> Unfortunately git support is weak for Windows and weaker still for  
> Eclipse.  So I'm going to have to figure out a new workflow to use  
> my IDE and git as an external tool in order to make the switch.
>
> It'll probably happen eventually but I've got enough irons in the  
> fire already for now.

The killer thing about git in my mind is Github. It makes it super
easy to push changes back and forth on projects. I'd highly recommend
sitting through the Peep Code screencast if you haven't already.

--
John Long
http://wiseheartdesign.com

Chris Parrish said the following on 27/05/08 09:50 PM:
> Thanks for the feedback Steven.  I'm really interested in making this a 
> usable extension for all.

Let me add my thanks too.

 > Now that I've been working on it, I see *many* good reasons to go 
this
> route (my current favorite is the server and browser caching benefits -- 
> I *love* the idea of not having to expire and reserve all stylesheets 
> and javascripts every 5 minutes).

Let me add one.
While having the CSS and JS in the database rather than the file system
is a convenience, especially for those of us who don't have shell
access, it comes at a price.  Database hits can cost more than file
system hits.  I found out long ago that caching can have hidden costs as
well.

This approach gives flexibility.  There's nothing to stop you using the
file system or pages.  Why?

Unlike some other commentators I prefer not to have my template drag in
every CSS and JS that __MIGHT__ be needed by some page somewhere on the
site.  I __LIKE__ the idea of associating specific pieces of CSS/JS with
specific pages.  But the overall look and feel of the site stays fixed.
 That can even warrant putting the CSS in the file system and making it
inaccessible even to developers.

But I DO want to be able to put custom CSS/JS on specific pages.

Thank you for this.



> As to the multiple tabs, yeah, I'm with you.  [...]
> 
> Anyway, for now, John just suggested keeping two tabs and waiting to see 
> how things progressed.  In the interest of minimizing tab space, I did 
> choose to name them CSS and JS instead of Stylesheets and Javascripts.  
> Plus, your standard-level users never see the tabs anyway so it looks 
> clean to them.

I think this is a diversion and just a reason to find fault with a great
product.

My gripe is about the packaging.
I unpacked v0.3 into /vendor/extensions/styles_n_scripts/

and got:

Could not load extension from file: v0.3_extension.
#<NameError: "V0.3Extension" is not a valid constant name!>


As far as I could make out, v0.3 wanted to be installed in
/vendor/extensions/v0.3


> I certainly welcome any ideas/suggestions here. Its a fairly 
> straightforward design but nothing's set in stone.

Are you going to subsume "attachments" ?



--
No one who has been a programmer can escape the conclusion that
computers highlight our inability to communicate.
   -- Mike Walsh, _Infosystems_, Nov 87

> /vendor/extensions/v0.3
>
>
>   
Anton, make sure to specify a directory when you export or checkout:

svn co http://url/to/the/extension vendor/extensions/styles_n_scripts

Sean

Anton Aylward wrote:
> /vendor/extensions/v0.3
>
>   

Hmm, that sounds like something didn't unpack to the right location (I'd
guess an SVN thing, actually).  Once you checkout the project, make sure
that inside your /radiant_project/vendor/extensions folder you have the
following:

  /styles_n_scripts
    /app
    /config
    /db
    /lib
    /public
    /spec
     CHANGELOG
     custom_settings.rb
     LICENSE
     Rakefile
     README
     styles_n_scripts_extension

Also, if you're using Radiant 0.6.7, I've released a v0.3.1 yesterday
with some minor tweaks.

Let me know if you're still having issues with this.
>> I certainly welcome any ideas/suggestions here. Its a fairly 
>> straightforward design but nothing's set in stone.
>>     
>
> Are you going to subsume "attachments" ?
>
>   
I think, long term, John would like an application that has a built-in
solution for images, css, and js.

In the meantime, I don't think I have that kind of authority to
overthrow other extensions...  Wrings hands...  "And after this one
falls, boys, we're going to conquer and assimilate the CopyMove
extension, mwaa haa haaaaa!"

-Chris

Ummm... the action column on the page list is getting huge! What about 
tool-tip option popups? I mean, we can keep adding extensions to our 
installations, but its starting to dilute the page tree causing it's use 
to be a little daunting for end-clients.

I think a nice little Javascript drop-down or something?

Has anyone else noticed their styles being kicked over to the right
every time they save.  This is crappin' my style of stylin'.  A few
saves and man it's off the page.

- Steven

OMG! Yes! It's soooo annoying. I was just about to post that.

Steven Southard wrote:
> Has anyone else noticed their styles being kicked over to the right
> every time they save.  This is crappin' my style of stylin'.  A few
> saves and man it's off the page.
> 
> - Steven

3.1 fixed this! Just installed it.

Arik Jones wrote:
> OMG! Yes! It's soooo annoying. I was just about to post that.
> 
> Steven Southard wrote:
>> Has anyone else noticed their styles being kicked over to the right
>> every time they save.  This is crappin' my style of stylin'.  A few
>> saves and man it's off the page.
>> 
>> - Steven

Technically, its a Radiant issue but it shows up in Extensions that
still use ERB (or at least if your ERB templates have a <pre> or
<textarea> tag).  That's one of the reasons I went to Haml so quickly.
If you want to know more, read my ticket here:
http://dev.radiantcms.org/ticket/642

Anyway, by moving Styles 'n Scripts templates to Haml, the issue was
bypassed.  Go get 0.3.1 (or keep your Radiant at 0.6.6 to stay pre 
Haml).

-Chris

Just installed .3.1  Nice job.  Thanks

- Steven

For anyone (now or in the future) following this thread, I've identified
the issue nurullah mentioned here.  It is indeed a bug with the SnS
extension and will be resolved in the upcoming 0.5 release.

For those interested, it's caused by the interplay between the way SnS
extension stores its settings, and the way Radiant rake tasks are 
performed.

SnS creates its default settings and then overwrites those with any
custom settings during initialize.

Well, it turns out that extensions are initialized during any Rake task
-- including 'rake db:bootstrap'  So, if you're including SnS in a
*brand new* installation of Radiant (not already bootstrapped), when you
try to create the database, the SnS extension gets initialized and tries
to store some settings in the not-yet-created config table.  Doh!

Those adding SnS to an existing Radiant install will never see this 
issue.

-Chris

What was the fix for SnS?
I saw the same problem with RBAC Base on a clean install (which I must
not have tried when we created it) and haven't had time to look into it.

-Jim

Chris,

We might be able to make a rake task that loads the environment with no
extensions installed.  In fact, it should be as easy as something like 
this:

task :minimal_environment do
    Radiant::Initializer.run do |config|
       config.extensions = []
    end
end

Then we could make db:bootstrap and anything else that needs to prevent
extensions from loading depend on that instead of the default
:environment task.

Sean

I'm not opposed to your solution in anyway.  I think it'd be helpful. I
just think that the "right" solution for my extension would be to:

    *  have my extension's default settings installed via the initial
      migrate task
    * offer a rake task to allow administrators (server admins) to
      change the css/js settings on the fly.  This need only be run once
      manually (after bootstrap) and not at every init.  I'd probably
      throw in a "restore_defaults" task too.

I designed the StylesNScripts::Config bit with the future UI designs of
Radiant in mind -- for the day when we'll have a settings/configuration
admin panel where extensions can add into the Radiant UI (instead of
sticking settings in some tab or hard coded and loaded at init).

My problem is that I broke this rule and made the settings load during
init "just for now" and shot myself in the foot.  If I do what I've
outlined above, it'll be trivial to hook into Radiant's shiny new
settings UI when it arrives

-Chris

I just outlined the fix in a reply to Sean's post.  It's a little more
elaborate (though I think more elegant) than I'd post here.

If you're trying to get it to "just work for now" you can simply comment
out the following line from the styles_n_scripts_extension.rb file:
  include CustomSettings

Run your "rake db:bootstrap" to create the database, then un-comment
that line back in.

-Chris

Sean Cribbs wrote:
> end
>
> Then we could make db:bootstrap and anything else that needs to 
> prevent extensions from loading depend on that instead of the default 
> :environment task.
>
> Sean

I tried the idea above (added it to my extension -- not Radiant) and set
up my extension's tasks like:
  task :migrate => :minimal_environment do
    ...

I got an error that the constant StylesNScripts wasn't defined (at least
that's what I remembered).

I probably just did something wrong here but I wanted to post the result
as an FYI.

-Chris

I'm having a prob installing the rbac_base extension. I've searched the
list and found that the devs of this and another extension for radiant
seem to have the same problem.

Following the docs:
rake db:migrate:extensions

rake aborted!
SQLite3::SQLException: no such table: roles: SELECT * FROM roles

I look in ..rbac_base/db/migrate and find the appropriate migrations to
create the needed tables. Aren't *these* the migrations that are trying
to be run by db:migrate:extensions? When I browse the list archives I
find extension devs talking amongst themselves 2 months ago about this
problem. Since I'm new to ruby, rails, radiant and extensions this is
*way* over my head. Does anyone have a suggested solution? (other than
read the code for all the above) ;)

--
Whatever you can do, or dream you can, begin it! Boldness has genius, 
magic, and power in it. ~Goethe
Faith makes things possible, not easy. ~Author Unknown

Burt Adsit

Burt Adsit wrote:
> to create the needed tables. Aren't *these* the migrations that are 
> trying to be run by db:migrate:extensions? When I browse the list 
> archives I find extension devs talking amongst themselves 2 months ago 
> about this problem. Since I'm new to ruby, rails, radiant and 
> extensions this is *way* over my head. Does anyone have a suggested 
> solution? (other than read the code for all the above) ;)
>
Hi Burt,

I may be way off here, but two questions for you:
1. Did you bootstrap the database for Radiant?
2. Any chance that your environment is different?  I mean did you
bootstrap the production database and are now doing Rake without
specifying the environment, and therefore ending up with development
being migrated?

Cheers
Mohit.

On Aug 23, 2008, at 1:31 AM, Mohit Sindhwani wrote:

>> look in ..rbac_base/db/migrate and find the appropriate migrations  
> 1. Did you bootstrap the database for Radiant?
> 2. Any chance that your environment is different?  I mean did you  
> bootstrap the production database and are now doing Rake without  
> specifying the environment, and therefore ending up with development  
> being migrated?
>
> Cheers
> Mohit.

Burt,

I don't know how, but I never saw your original message, so I'm glad I
caught Mohit's response.

I don't recall the exact problem, but I know that Radiant will try to
load extensions if it hasn't been bootstrapped. So Mohit's first
question is a good one. Have you bootstrapped already?

If not, move the extension up into vendor (and out of the extensions
directory), rake db:bootstrap, then move it back and rake
db:migrate:extensions.

We'll be adding some other features to rbac_base in the future, so
please send any suggestions that you have.

RBAC was built to allow extension developers to check user roles for
*extensions*. It does not alter roles for the normal functions of
Radiant (pages, layouts, snippets).
It may do that in the future. I'm personally on the fence about
whether or not Radiant should go down the road with a complicated role
structure in the core.

Jim Gay
http://www.saturnflyer.com

Thanks guys, I'll try your suggestions. I've been sidetracked the past
few days installing linux/vista dual boot on my laptop. I'm finding that
alot of developmental probs originate in the windows environment. Gotta
do it. I'll be running on *nix anyway. My problems couldn't possibly
originate in my own ignorance. (sigh).

--
Whatever you can do, or dream you can, begin it! Boldness has genius, 
magic, and power in it. ~Goethe
Faith makes things possible, not easy. ~Author Unknown

Burt Adsit