Jump to content

kicken

Gurus
  • Content count

    3,408
  • Joined

  • Last visited

  • Days Won

    81

kicken last won the day on May 27

kicken had the most liked content!

Community Reputation

467 Excellent

About kicken

  • Rank
    Wiser? Not exactly.
  • Birthday 07/19/1985

Contact Methods

  • Website URL
    http://aoeex.com/

Profile Information

  • Gender
    Male
  • Location
    Bonita, FL
  1. I've become fond of Symfony over the last few years. I find it relatively simple to get started with, yet still highly customizable/usable when you start wanting to do advanced stuff. I haven't given Laravel a shot since a few years ago, but back then I wasn't a huge fan of it then. I've also never personally used Zend, but have had to debug/modify some applications that did use it and it's a nightmare. I'm with requinix, avoid it.
  2. kicken

    Json response not caching

    How exactly are you testing this to determine it's not caching? Development tools for example may ignore caching as usually you don't want something to be cached when your developing on it. Make sure whatever means you're using to test your system actually supports caching. You mention for example pressing refresh/reload in the browser. That sort of action is exactly what you do to tell the browser to ignore it's cache and fetch a new copy of the resource.
  3. kicken

    improve my database class

    Unless you have some specific reason for using MySQLi, you really should switch to PDO. Aside from the fact that PDO is the standard interface that everyone is expected to use these days, mysqli's API is pretty horrible in comparison to PDO.
  4. kicken

    Setting HTML FORM Field - Not Working

    If you disable a form field, then it will not be sent when the form is submitted. Use the readonly attribute to prevent a user modifying it. If you want the disabled look, simulate it with CSS.
  5. kicken

    Should all my apps be built for composer?

    If you have parts of your project that might be useful in other projects as a library, then it may be worth separating them out to their own repository and composer package. Otherwise, just keep them as part of your application project. Any project with a composer.json file could be considered a composer package. Typically packages are libraries but some are projects designed to be used with the composer create-project command. You might do this for example if you had an application that you wanted to be able to easily setup in multiple places. If you don't want your projects public on packagist though, you'll need to setup your own composer repository before you can use the create-project command. I generally will try and separate out what might be good libraries if possible. For top level applications though I usually don't bother with trying to create a proper composer package, create-project isn't that useful really.
  6. Based on this thread so far, no you are not learning, you're trying to get free work. No, I'm not going to write it for you. You've been given enough details to be able to accomplish what you want on your own if you put even a tiny amount of effort into it, which shouldn't be a problem if you're really trying to learn.
  7. Use the 1} token as another separator to split the question from the extra data. Assuming the text is always 1} any never any other number, then it'd pretty much the same code as for the Answer: token.
  8. I typically tackle things like this by just splitting the text into components by the static separators. Repeat multiple times until you get what you want, or narrow the scope down to something easier to work with. For example: <?php $text = file_get_contents('yourfile.txt'); //Split each question/answer by the *NEXT* separator $parts = explode('*NEXT*', $text); $result = []; foreach ($parts as $part){ //Split the question and aswer by the Answer: separator list($q, $a) = explode('Answer:', $part, 2); //Remove the #} from the question $q = preg_replace('/^\s*\d+}/', '', $q); //Trim whitespace $q = trim($q); $a = trim($a); $result[$q] = $a; } var_dump($result); This depends on your separator values being unique. If your separator values occurred somewhere else then it'd fail.
  9. kicken

    Type declarations for an array of objects

    I just document the type in docblock comments and consider that good enough. Having those hints is enough for PHPStorm to do proper auto-completion and issue warnings when it suspects a type mismatch. If PHP supported such type annotations natively then It'd be worth using them, but as it is currently implementing collection classes seems like a waste of effort to me. Apparently this feature was proposed but rejected.
  10. kicken

    Type declarations for an array of objects

    Afaik, in PHP there is no way to specify an array of X, just either X or generic array. If you include docblock comments, you can document a parameter as being an array of X using the notation X[], for example: /** * Set available categories * * @param Category[] $categories */ public function setCategories(array $categories){ //... } A decent IDE will pick up that hint and use it to type check your code, but PHP itself will only enforce that the parameter is an array. If you really want to have some type checking at runtime then you could do as you said and create a collection class, either one specific to the type you want or a generic one that does a type check and throws an exception on failure. For example (untested): class ObjectArray implements ArrayAccess { private $type; private $storage; public function __construct($type){ $this->type = $type; $this->storage = []; } public function offsetExists($offset){ return array_key_exists($offset, $this->storage); } public function offsetGet($offset){ return $this->storage[$offset]; } public function offsetSet($offset, $value){ if (!is_a($value, $this->type)){ throw new \InvalidArgumentException('Value must be instance of ' . $this->type); } $this->storage[$offset] = $value; } public function offsetUnset($offset){ unset($this->storage[$offset]); } }
  11. kicken

    How to "think" OOP?

    rambling ahead I start by thinking about how I want my classes to be used and what's needed to allow that. I'll use my Gearman library as an example here. When I started this project, I created pseudo-code regarding how it would be used before anything else. That pseudo-code (after some tweaks) essentially became the examples in the read me file. Once I was happy with that pseudo-code I knew what sort of public methods and classes I would need so I wrote those up. In this instance I just went straight to a class, but in some cases I might make an interface instead. It depends on if I think I may need to have multiple implementations with the same API or not. After that it was a matter of implementing those public methods so they did what they needed to do. The process can be repeated at the next level if needed. For example I needed to have some objects to manage the socket connection and data communications with the gearman server so I again wrote up some pseudo-code for how I thought that should work then implemented it that way. I find working like this makes the process easier as you can think about the problem on a high level and design how you want the code to work without worrying about how to actually make the code work. Once it comes time to implement your design you may find it needs some changes, but they are generally minor in my experience. I've never bothered with UML. The pseudo-code / interface approach I use works well for designing. If things are then named and categorized well then it's generally not hard to figure out how everything relates by just looking at the code. Indeed, you should only be inheriting if the two classes are largely related. Because you can only inherit from one parent, you don't want to be wasting that on some utilities functions. What happens when one day you are say developing a plugin for something and your plugin has to extend a certain class? Now you can't extend your SuperUsefulUtilities base class and all those fancy utility functions are not usable. If your utilities are worthy of a class, it's best to make them into a class you can make an instance of. If they are are just random useful functions, leave them as simple functions and include them. Traits can kind of be abused to simulate extending multiple classes, but it's a slippery slope I think. I've yet to come up with anything that I'd consider to be a good use of traits, but I have abused them a bit as a way to share some common code between classes before when I don't have time to do some proper refactoring. As for your title question "How to think OOP?", that's mostly just something you'll need to develop over time. As you've already noticed there are several opinions out there as to what's right or wrong and so with each tutorial or code base you study you'll find sometimes conflicting statements about what to do and not to do. The best thing to do is to learn about what is possible, then try and find reasons why people think such things are good or bad and decide if you are with those reasons or not. For example, some people think that things like Singleton classes are the devil and should never be used. Other's find them to be quite useful and think outlawing them is absurd. I come down somewhere in the middle of that debate. There are reasons you'd only want a single instance of something and a singleton class is a great way to accomplish that. On the other hand, just because you only want a single instance right now doesn't necessarily mean you won't need a second in the future. Not sure if the above is helpful in any way, kind of came out like incoherent rambling imo. I spent some time on it though and don't want to just delete it, so there you go.
  12. kicken

    Get Image from CSS

    That URL / CSS fragment must exist somewhere for it to be merged into the page. All you need to do is figure out where and then pull the information from there, which might be easier and more reliable. You mention it's part of a profile. Unless you have people specifying their profiles by typing in HTML/CSS code, I'd think that the URL to their profile image would exist as a field in your database somewhere meaning there would be no reason to parse css at all, just grab the URL directly.
  13. kicken

    How to work with imageftbbox

    ImageTTFBBox had a long-standing bug where it wasn't very reliable for giving pixel perfect measurements. I remember running into it years ago and ended up doing some of my own measurement by drawing some text on an image then checking for filled vs blank pixels. The bug has been fixed apparently (wasn't last time I checked) so make sure you're on a new enough version of PHP. I just tried on my end by downloading the font file from your site and copying your code. After adjusting from px to pt as pointed out, I get a more or less matching number on PHP 5.6.30. Firefox say the div with the text is 434.95px wide, PHP says the string is 434px wide. edit: Arial seems fine too for me. Firefox: 435.767; PHP: 435 Impact is slightly different. Firefox: 405.333; PHP: 409
  14. kicken

    syntax error detection

    Your host probably re-configured things when it upgrade PHP. In the past many shared hosting providers I used would have things configured with display_errors=On but that's not an ideal configuration for a production server as it exposes too much. Your host was probably setup like that previously and when they upgraded finally changed it to the better display_errors=Off with logging setup instead. The old configuration would let you see the parse errors because of the PHP configuration, not your script specific settings. The new configuration doesn't show the errors, and your script can't override that if it can't be parsed. So your options now are Re-configure PHP to show errors again or Start checking the error log file when you get a blank screen or Re-work your application to use a main front-end file that sets your error reporting then require's the rest of your code.
  15. kicken

    syntax error detection

    Setting the error reporting values in your script is less than ideal. If, for example, your script had a parse error then PHP would bail before ever setting your error settings as the script is never executed. If your application works like many frameworks these days and has a small front-end script that sets the error configuration then include's other files you're probably fine though as the setting would be applied prior to the include being executed. For your live server, setup your php.ini file with an error_log value pointing to a file somewhere you can check for errors and display_errors=off. For your development server you can set display_errors=on and error_reporting=E_ALL to hopefully get the errors in the browser directly. If you're using a fast-cgi setup for PHP you might need to configure it to pass through the errors as well.
×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.