TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Working with CSS and JS
  • For now body.jpg and html.jpg lays in the docroot.

    While we want to serve templating, layout based css/images should go under /templates/[name]/images and /templates/[name]/styles.

    I have a certain /scripts folder for my javascripts.

    But i have seen many people use /assets or the media module...


    PS
    I'm not a friend of calling images/HTML-IDs/HTML-classes as where they shown or somethink like that. flower.jpg and background.jpg sounds more reasonable and you know, what the images are showing. Maybe this can be an convention-
  • You are right. the names are not good nor are their placement...I think we need to find a convention for image placement and why not image naming.

  • im confusd how are you setting up all the media.
    I tend to just do (on the doc root)

    media
    - css
    - js
    - img
    - flash


    And so on. Although anyways fine, but i do think its good to group all media together.
  • What we could do is a have a Media Locator helper that locates media.

    For example it could use certain paths by default plus user defined ones. Then it searches for that file (and errors if it isn't found).

    The Img part of that could also fairly easily use kdynamicimage as well (as an option) to allow imgs to be located out of the document root.

    something like

    // adds a custom path
    hmedia::add_path(DOCROOT."my_media/path")
    // adds a custom path for images only
    hmedia::add_path(MODPATH."mymodule/media/img","image")
    // gets images (using kdynamicimage if it is available)
    // searches in all the paths in a certain order till it finds one (errors if not found)
    hmedia::get("myimage.jpg","img")
    hmedia::img("myimage.jpg")
    // adding a path to the front would be supported as well (with / at the start it could maybe look relative to the docroot too..)
    hmedia::img("some/path/to/myimage.jpg")
    

    and so on (just demoed images there).

    And advantage of this would be, also, that if we implement a theme library/module and it was being used it could automatically add the theme name into the mix (eg: it searches DOCROOT/media//img/ before DOCROOT/media/img).

    Or something :)

  • @Errant. You dont think that will be a little slow, remember we gonna have a few modules etc loading in some kind of automagically way, and add a auto searcher... i dont know, its pretty cool, but i think its gonna be slow. If you have a realty site, and have 400 images... Its gonna be a pain :D
  • Yeh true true..

    hmmm

    ideas / thoughts

    • We could implement some simple caching (certainly for the images), plus compression too
    • If your loading 400 images it's going to take a loooong time anyway :P
    • We could certainly index the search paths (over time) so as to locate the image faster (I.e check paths we KNOW worked before first)

    Hmm

  • That maybe slow, but atleast using a helper you arent restricted on where you are going to store ALL your media. I actually find it rather clean.

    hmedia::add_path('/media/');
    html::img(hmedia::img('thisimg.jpg'));


    Im guessing all add_path does is add the path to set_include_path();
  • the CSS and JS should actually be stored in the CMS database i.e.

    A template can have CSS & JS
    A page can belong to a template but can also havs JS & CSS

    The CMS can have a setting to to compress the CSS & JS and also make it one file template CSS first then page CSS second

    just my thoughts :)

    Have a CMS if you want to see how its done :P

    This is a better approach because when you come to do languages you can have a different CSS layout to suit text alignments etc
  • +1 to having a locater helper. It makes things a lot cleaner for the developers, you can nicely pack everything into 1 module, without worrying about moving files around. This should only be used for JS/CSS, I don't think this should be used for other assets like images, because you wouldn't be calling images directly, but through the stylesheets.

    CSS/JS can also be compiled, packed and cached, to reduce the overhead.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion