Jump to content

adoado

Members
  • Posts

    14
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

adoado's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. I'm not sure how this is possibly bad OOP design. Many language uses similar techniques in very successful symphony with encapsulation, polymorphism, etc. (think function pointers in Delphi/C). It's odd to me the justification here is speed - that's not the concern. The concern is OOP. Saying "X is bad OOP because it's slow" is not a justification for not being object oriented. Magic methods are also successfully used in many other programming paradigms (interfaces in Delphi when writing COM/COM+ servers), which rely extensively on OOP. Again, the speed argument baffles me.
  2. Checking IPs is not a reliable method (see NAT/PAT http://en.wikipedia.org/wiki/Network_address_translation). If they are identifiable because they are logging in, you can persist it in a database of some sort, or use client side cookies.
  3. Unfortunately, went I went to visit the site, there was a PDO exception. The fact that I know this is a bad thing (turn off error reporting when you go live.. your database password was on the screen !!) Hopefully it's up again soon
  4. Nope, this is Adrian Well said, that hits this question on the head I think!
  5. This happens to everyone every now and then, and usually it's because the underlying design pattern is a wrong fit. There are many potential candidates to make a small website, but if it changes a lot or is modular, other patterns look more favorable. If it is "widgetized" then it's different again. If you have a lot of design and you want to separate it then MVC is king. The problem is, when the project is small, it's less obvious because all appear good - this is really a matter of planning and experience, luckily both of which are obtainable I'd spend time reading up on design patterns, and understand concepts like code coupling and dependencies. Why is your code hard to manage - is it too tightly bound, or are the naming conventions wrong? Is the logic spread all over the place, or is it too hard to talk to the database? These are all valid questions, hell, even "I have to change my code too much" is a warning of a design pattern which is not completely suitable. Object oriented programming is a big tool, a God among development paradigms. Make sure you know OOP, beyond just standard "classes". Polymorphism, encapsulation, abstraction, etc.
  6. There are several key points here: Make sure you logically enforce what pages are allowed to be called. Note that you may have product requirements in your head (cannot access page X without requirement Y) but this must be enforced inside this layer. You are exposing page names externally. This may not be an issue - depends on your situation (people can very easily guess that an admin page might exist at ?page=admin)
  7. There is nothing wrong with using a file to store data ("flat file" storage) as long as you know it's pitfalls, one of which is the lack of protection when written to by different threads (that is, PHP processes may read and write to the file at the same time, and this can cause contention issues). If this is not an issue, flat file storage might be a good option, but trq is suggesting a database because they excel at preventing this type of issue (see ACID compliance). Not all databases are ACID compliant, so when you pick one, make sure it supports concurrency control (such as MySQL, PostreSQL, etc). That method of inserting text in HTML is fine, too, as long as you are aware of when that pattern falls. It's actually a better system than directly printing variables in the HTML (because a tight coupling of logic and design means neither can flexibly change) but there are better alternatives still. A templating system such as Mustache or Smarty provide this support, as well as iterative loops, basic post-variable "rendering" options, etc. In this case, I'd suggest reading up on MySQL and PDO.
  8. Never invent your own encryption methodology. You can disregard that message, sure, but it's not me saying it - it's the professionals. Why? Because security is not a topic where things are obvious (by definition) so a flaw that you or I cannot see may be easily visible when it's analyzed by those who understand it. If you want to ensure security - use known encryption algorithms such as AES. RSA, etc. Experimenting is fine, and definitely worth doing. But never deploy your own solution in practice.
  9. You've actually done it! $myArray = array(); foreach(iterator here){ $myArray[iterator] = XX } That's pseudocode though
  10. As in, you want to obtain these HTTP parameters? These are accessible via POST or GET in the $_POST or $_GET superglobals. For example, http://mysite.php?myval=adrian Then access via $_GET['myval']. See http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol and http://php.net/manual/en/reserved.variables.get.php
  11. A bit more information would help.. have you got errors on, or a tail log open?
  12. Hello everyone! Recently I have been reading up a lot on the notion of dependency injection, and it's making good sense. It's a very cool idea! I just wanted to run my current understanding though people here so I can get advice if it's the correct approach. Let's say I have many users that will access the forum. To control logging in, verification, registration, etc. it makes sense to encapsulate all these 'abilities' into a class, say, USER. Hence, USER contains mutator methods for all the required actions. Similarly, to retrieve a list of threads, posts, etc. (non-personal data), is it wise to have another class, FORUM, which manages all this? If so far is so good, then clearly both the above classes have the database engine as a dependency. So, from what I've read, making a container class that contains the database connection variable as a static field and instantiating USER and FORUM through this CONTAINER is the best way, injecting this static database connection along the way. So: A new user is created through CONTAINER, NewUSERClass(); USER gains it's database connection through a static variable in CONTAINER. Hence, it's dependency is injected. If that is correct also, here is where I am confused. Where should this static database connection be made? Or, should I verify the connection exists everytime a USER or FORUM class is instantiated through it? Similarly, let's say I have a class that contains SETTINGS (max password length, post title length, etc.) Should this be a separate class, or merely distributed into USER and FORUM? The latter is easy, but makes two very big classes. If not, there is too much coupling between classes (SETTINGS needs a database engine, USER needs settings AND a database engine, etc.) I have never been formally taught programming, so perhaps I am way off the mark here, but I'd appreciate any advice you might have! Thanks for reading! Adrian
×
×
  • Create New...

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.