Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Should Asset::css returning Fuel_Exception?
  • I made a mistake with Asset::css() and it returned a "bad" error that halted rendering. Isn't a better idea to silently error by excluding the missing resource instead of causing an Exception error?
  • The style of most websites would be considered a core competency, not an enhancement by the people who pay me :)
  • It's great that it throws an exception. if you get too scared by knowing that your assets aren't being loaded just put the whole lot in a try / catch
    try {
      Asset::css('style.css');
    }
    catch(\Exception $e) {
       // do nothing
    }
    
  • Ben Corlett wrote on Wednesday 22nd of June 2011:
    It's great that it throws an exception. if you get too scared by knowing that your assets aren't being loaded just put the whole lot in a try / catch
    try {
      Asset::css('style.css');
    }
    catch(\Exception $e) {
       // do nothing
    }
    

    Interesting approach, but I still recommend writing to log instead of writing extra code to catch the exception.
  • I wouldn't exactly call that an "interesting approach", I'd call it basic PHP. Also, I agree with most of the pro-exception arguements above: CSS isn't optional, neither is Javascript. They're critical parts and in most cases a full crash with error will be a lot better than a silent one - especially for your users who won't understand that the weird page or non-functial buttons is because of the lack of a css/js file. And the reason we use exceptions for stuff like this is just because it will allow you to catch it and handle or ignore it. Also if you reaaaaaly don't like it: extend the Asset class and have it catch exceptions from parent methods internally and fail silently.
  • Thank you Jelmer for the feedback... I completely agree that these resources are not "optional" in the sense of development or deliverables. I too appreciate the Exception informing me that something is missing or wrong. However, with that said, let me explain my reasoning. I manage a team of 7 front-end developers and work for one of the worlds largest photography and video company. We have a very large and complicated infrastructure. Our typical migration process involves moving application (logic) files first and then static files (CSS, JS, IMAGES) second. This is largely in part to session and cart handling. In a very rare occasion and within a fraction of a minute, a user might face new application logic without corresponding static files. We take extreme care to avoid this, but, in theory it could happen. In our tests, the user would simply be "missing" the CSS, JS, or IMAGES but continues to work seamlessly. On the next page load or refresh, all the static files would catch up. Our biggest headaches are with extremely important JS that handles critical tasks. Our most important goal is to stay transparent while still handling users that use IE 5. From my research, user's don't care about the website's aesthetics or why something is broken. If it functions for their needs then they just want to finish what they came for and get out. Like you said, considering this scenario and if we were using something like fuelPHP, we would need to extend Asset to prevent the Exception from crashing the user's session or flow. On the other hand, if this is a possible situation for any application, then I thought, offering a silent error log message is better than extending the Asset class. I even thought of adding a "config" setting for this "feature." Either way, I offer this advice out of pure appreciation for the hard work you guys have done. I really like what this framework has accomplished in such a short time!
  • Just a thought: instead of trying to catch issues like this in your application, isn't it time to review your deployment strategy?
  • Andres Vidal wrote on Wednesday 22nd of June 2011:
    Thank you Jelmer for the feedback... I completely agree that these resources are not "optional" in the sense of development or deliverables. I too appreciate the Exception informing me that something is missing or wrong. However, with that said, let me explain my reasoning. I manage a team of 7 front-end developers and work for one of the worlds largest photography and video company. We have a very large and complicated infrastructure. Our typical migration process involves moving application (logic) files first and then static files (CSS, JS, IMAGES) second. This is largely in part to session and cart handling. In a very rare occasion and within a fraction of a minute, a user might face new application logic without corresponding static files. We take extreme care to avoid this, but, in theory it could happen. In our tests, the user would simply be "missing" the CSS, JS, or IMAGES but continues to work seamlessly. On the next page load or refresh, all the static files would catch up. Our biggest headaches are with extremely important JS that handles critical tasks. Our most important goal is to stay transparent while still handling users that use IE 5. From my research, user's don't care about the website's aesthetics or why something is broken. If it functions for their needs then they just want to finish what they came for and get out. Like you said, considering this scenario and if we were using something like fuelPHP, we would need to extend Asset to prevent the Exception from crashing the user's session or flow. On the other hand, if this is a possible situation for any application, then I thought, offering a silent error log message is better than extending the Asset class. I even thought of adding a "config" setting for this "feature." Either way, I offer this advice out of pure appreciation for the hard work you guys have done. I really like what this framework has accomplished in such a short time!

    Fair enough, in that case I would just override the core classes. I'm working on a project for a company right now and I've overridden most of the Core classes that I use regularly, to tailor them especially for me. And plus, with Fuel it's super easy! I even made your class for you :)
    And just be sure to register your class in the bootstrap http://d.pr/P59k. Done :) (I've not tested that class but I can't see why it wouldn't work) EDIT:
    // Replace
    return parent::render($group, $raw = false);
    
    // With
    return parent::render($group, $raw);
    

    EDIT 2:
    That method is assuming that you're only rendering one asset file at a time, not an array. For an array you'll need to copy the entire method and just remove where it throws the exception.
  • Andres Vidal wrote on Tuesday 21st of June 2011:
    I made a mistake with Asset::css() and it returned a "bad" error that halted rendering. Isn't a better idea to silently error by excluding the missing resource instead of causing an Exception error?

    the purpose of the error is that you can fix it, i like the feature :)
  • I agree that leaving code that references missing resources is bad habit. However, in a production environment, CSS should be handled as an optional "Enhancement" that, if missing, still renders the site accessible. However, insisting that all resources are available, programmatically, defeats this theory. Also, the typical browser will not blink if there are missing CSS :)

Howdy, Stranger!

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

In this Discussion