[ANN] Styles 'n Scripts Extension

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:

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

-Chris

hmm, thats nice

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

thank you

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

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

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

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

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 tags it just dumps everything to
the
page.

it must wrap codes if there is no header tag

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 section but in the – 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:

... some stuff ... ... more stuff ... ...

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

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

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?

why dont you git?

On 5/28/08, Chris P. [email protected]

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

On May 28, 2008, at 1:15 PM, Chris P. 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 L.
http://wiseheartdesign.com

nurilized wrote:

why dont you git?

You guys are killing me. John’s pushing me there today too :wink:

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

Chris P. 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

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?

Anton A. 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

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

Steven S. 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 J. wrote:

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

Steven S. 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