How to get URLs in JS, CSS, Controllers, Single Pages, Views, etc.

Permalink 1 user found helpful
OMG, will somebody (Andrew, Franz, anyone) please, Please, PLEASE build a cheat sheet for how to link images, how to link to other pages, when to use actions, how to link in JS and CSS, and anything you could possibly think of that requires linking. I would love to see how to do it from the controller, JS pages, CSS pages, views, single pages, dialog windows, blocks... EVERYTHING!!! 99.9% of the time I try to develop in Concrete5, THIS is what I struggle with and spend way too much time on.

jbsmith969
 
dancer replied on at Permalink Reply
dancer
jbsmith969 replied on at Permalink Reply
jbsmith969
Thanks dancer, but that kinda proves my point. Look at all the places you have to go to find information on linking something. Linking is like a 3 second task in PHP, HTML, CSS and JS when you're outside of this framework... don't get me wrong, I love the framework. It's the first CMS framework I actually get worth a darn. I just struggle a great deal with linking, and how I should be doing it.

In the next couple of days, I'm going to start a cheat sheet and post it so we all can collaboratively get this done. This is such a necessity for anyone that does package development. I hope others in "the know" will participate and make corrections where needed. :)
jordanlev replied on at Permalink Reply
jordanlev
I appreciate that you want to do this, and I think you should. But I would caution that if you're trying to solve the problem of "too many different places to look for answers", adding yet another place to look for answers is only going to make it worse.

Not an insurmountable issue, but just keep it in mind. For example, perhaps contact the authors of the other cheat sheets and ask them if it's okay to copy all of that content to yours, and maybe ask them to link to yours instead from now on, etc...
(In other words, what's needed to fix this problem is someone to go through the trouble of organizing the community, NOT just another cheat sheet).

I hope it works, though -- I do think it would be helpful if done the right way.

-Jordan
jbsmith969 replied on at Permalink Reply
jbsmith969
Great point jordanlev and I completely agree that there needs to be more organization of the content that everyone has everywhere, but at the moment, that would be too much for me to handle right now. I'm not trying to cover every single base either. I just want linking how-to only. Right now, it's all mixed in a bunch of other content of how to do other things whether it be in cheat sheets, how-tos, already built packages, etc. Whether you're linking from a controller, a view, javascript, or css... most of the linking is going to be very similar when developing blocks, single pages, themes or packages. Just think of this as a beginning of organizing this stuff. Perhaps I'll take it to the next level once "we" (I hope) get this built. Ultimately, what I would want to do is get it added to the documentation or how to section on this site. I certainly don't think it should live on yet another domain with another cheat sheet.

Oh, and to add to that, there is stuff I want in here that I can't seem to find at all in the other places. Nobody ever seems to talk about how to link stuff... especially for packages. They get you almost there, but I just can't seem to find the answer that seems right so I feel like I'm always doing a work around.
jordanlev replied on at Permalink Reply
jordanlev
When you say "linking", I kind of know what you're talking about, but am not sure I am thinking the same thing as you here -- if you wanted to post (or just PM me) a list of the various scenarios and goals you're referring to (like a bulletpoint list), I'd be happy to provide answers for any that you don't already know.

I think posting it as a how-to on the docs here would be a good idea.

-Jordan
jbsmith969 replied on at Permalink Reply
jbsmith969
Well, one example would be if I'm building a package, and in that package I have a .js file that I want to run $.ajax() on a single page. So, let's just say I built a method in my controller called ajax_thingy. I could hit that method by going to http://mysite/c5folder/index.php/single_page_name/ajax_thingy... right? So how do I create that url dynamically in the js file so I can do
$.ajax({
    url: 'http://mysite/c5folder/index.php/single_page_name/ajax_thingy'
});

I could hard code it or throw it in the single page as a hidden input or div (which is what I'm currently doing)...
$form = Loader::helper('form');
$ajax_thingy = $this->action('ajax_thingy');
echo $form->hidden('ajax_thingyURL', $ajax_thingy);

then in the js file, setting the url to...
var ajax_thingyURL = $("#ajax_thingyURL").val()

Although it works, that just doesn't seem right.

CSS files are a whole other nightmare. How do you link to images in css files and js files for that matter that are in your package? It's not like you can load a helper or use a constant.
jbsmith969 replied on at Permalink Reply
jbsmith969
Now that I think about it, I should have probably called this discussion "How to get URLs...".
jordanlev replied on at Permalink Reply
jordanlev
Here's another good one -- how to get a block URL in a controller:
http://www.concrete5.org/community/forums/customizing_c5/get-relati...

And here's a specific use case for that -- when you need to include js/css in your block's add/edit dialog:
http://www.concrete5.org/community/forums/chat/dynamic-jquery-based...
jordanlev replied on at Permalink Reply
jordanlev
Oh, yeah -- that one's rich (as my grandpappy used to say).

Here's how I do it:
http://www.concrete5.org/community/forums/customizing_c5/ajax-from-...
jbsmith969 replied on at Permalink Reply
jbsmith969
What?!?!? You're echoing php in your js? It thought that was against the laws of physics. :) Are you telling me I can echo php in my js files, or just in the auto.js file. If that's the case, where do I put the auto.js file in my package for a single page because I tried that once and it didn't work so I didn't bother spending another hour trying to find how to make an auto.js file work.
I tried...
/mypackage/js/auto.js
/mypackage/auto.js
the single page was at...
/mypackage/single_pages/mysingle_page.php

I thought it was suppose to load automagically. Am I suppose to load it in the cotroller too?
$this->addHeaderItem($html->javascript('auto.js'));


I remember reading stuff about auto.js, but I've forgotten a lot because I never applied that info when I learned it. Now I can't remember where I read it.
jordanlev replied on at Permalink Best Answer Reply
jordanlev
No, you can't echo php in a javascript file (well, you can, but it's probably not worth the trouble because you have to configure apache to serve the file in the right way and you'll definitely forget what you did when you need to make changes to the site 6 months down the road -- I've done this for custom applications, but for a CMS site it doesn't seem worth the trouble).

Anywho, no you cannot easily parse php in a javascript file. BUT you can output a javascript variable in your view.php file which is then picked up by a javascript file (since all javascript that's run by a page shares the global namespace, any script you include has access to variables declared in any other script -- or in the html/php file itself in this case [assuming the variable isn't defined inside a function of course]).

And here are the rules for what's included in a block:

* add.php/edit.php automatically include the auto.js file (if it exists). That's it -- for any other css/js you want in your add.php/edit.php, you need to use the technique I linked to above

* view.php automatically includes view.css, view.js, AND any .js files inside the block's "js/" directory AND any .css files inside the block's "css/" directory. I think the directories are only looked at one level deep (so files inside subfolders of js/ or css/ I don't think would be included -- but I could be wrong about this).
jordanlev replied on at Permalink Reply
jordanlev
Oh, and just to clarify -- the things I listed above only work inside a BLOCK (not a package). If you want to load a package asset, try this:

http://www.concrete5.org/community/forums/customizing_c5/where-to-p...
jbsmith969 replied on at Permalink Reply
jbsmith969
Oh!!! Gotcha! I didn't think about setting JS vars in my view or single page. That makes sense.
One day when some of my packages grow up that seem usable to others, I want to make them available to the community... so obviously everything needs to be self contained within that package folder and no odd ball apache configs. :)

So how do you link images in a CSS file? For example...
background-image: url(someimage.jpg);


BTW, thank you so so much for clearing that up. You rock for being so helpful and make me want to pay it forward.
jordanlev replied on at Permalink Reply
jordanlev
As far as I know, in the css file you just need to make sure the images are "nearby" so you can refer to them with a relative path (so in your example above, the "someimage.jpg" file would need to be in the same directory as the css file). I usually have my css in the theme or block directory and images in an "images" subdirectory, so in my theme/block CSS I have url(images/someimage.jpg); -- or sometimes if there are a lot of stylesheets I'll have a separate folder for css, and then I need to refer to images like this: url(../images/someimage.jpg);

The reason you don't need to mess with all of the code to get URL's like you do with PHP / block views / etc. etc. is because CSS files are loaded as separate assets by the browser FROM THE DIRECTORY THEY LIVE IN -- so relative paths work because your browser is actually loading the css file from YOURSITE/themes/YOURTHEME/style.css (or YOURSITE/blocks/YOURBLOCK/view.css). Whereas with the page type templates or the block view.php file, that is not actually being loaded by the browser from its location on the server -- rather index.php is always the file being served, and it is responsible for going out and stitching together the hundreds of files (including your theme/block views) it takes to serve a C5 page.

And you're very welcome for the clarification. I've been helped along the way by other generous people who have inspired me to pay it forward, so there ya go.
jbsmith969 replied on at Permalink Reply
jbsmith969
Thanks again Jordan. I haven't put that under thorough testing, but it makes sense. Sometimes when you get in these MVC systems, there's a lot of things that going on that make all normal paths irrelevant. So much so, it gets to a point of thinking nothing is standard from where it lives. This is very very helpful!!!

I wish I could mark multiple replies as helpful on this. There's certainly more than one in this case.
jordanlev replied on at Permalink Reply
jordanlev
Fortunately or unfortunately (depending on how you look at it), Concrete5 doesn't adhere too strictly to the MVC paradigm. I don't think this is too serious of a problem because sometimes pragmatism is more important than intellectual purity. For example, there are a few Ruby On Rails CMS's, and they definitely stick much more strictly to the MVC pattern (as do all Rails apps) -- some might even say that the code is more "beautiful" and consistent and better-engineered than C5, but they don't hold a candle to C5 in terms of end-user experience and full-featured-ness (in-context editing, great file manager, sitemap integrated into TinyMCE, etc.). Not to mention the relative ease of deployment across every cheap web host out there.

That being said, the price to pay for this pragmatism is that things are not as consistent and easy to understand as they could be for developers. Hopefully over time this will improve though.

-Jordan