Jump to content

Attilitus

Members
  • Posts

    39
  • Joined

  • Last visited

    Never

Profile Information

  • Gender
    Not Telling

Attilitus's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Ahhh, I see your perspective now, that is a significant limitation. In my eyes the objects would be a complement, not a replacement for relational database fields. So there would be a normal database, simply with the occassional stored object (with an object reference to its primary key). I am just thinking that for some information (such as the aforementioned hypothetical calculator session), the complexity would make storing it as an object almost necessary.
  2. Also be aware of PHP timeouts which are normally set around 30 seconds.
  3. Although certainly you could do that (provided you had a cron script change the DAYID such tasks as that example are the conceptual reasoning that I am considering when thinking about storing objects. You could also just use IF statements throughout the script if you like. Anything that you can do with objects in the database, you can do with regular relationally stored information, but sometimes you have to make significant workarounds in order to achieve it. For example in your case you would need a cron script to change the DAYID of the user field. A better way to relationally handle it would be to simply make the username field an array and select the date based on the # of the day. (Or just use lots of IF statements in your script ) There is nothing "simple" that would benefit from something like this... but imagine something more complex like saving an instanced event like a graphing calculator session. You could feasibly input a database field for the formula, the x,y positions, any settings that were activated, ect. However, then you need to start re-operating on it again under the same framework as before. You need to query all the settings for that one unique session, and then do (new classname) and somehow reassociate all that information (probably by making an array and making your class accept array values on initialization) back with the class. It can be done, probably without "too" much pain. But why not, in that kind of situation, just serialize the object and call it back when it is wanted using: $storedobj=db->select_object($id); $obj=unserialize($storedobj); This is only relavent with someone already using OOP coding practices, but it is a kindof cool way to "think" about coding itself. You make a "new session" and then store the entire session as a single entity.
  4. Well what if you want to store in a user's username field that their name is Jim except on sundays when it is Suzy. class username{ function outputusername($day){ if($day==sunday){ return $this->sundayname;}else{ return $this->otherdayname;} function setname($day,$name){ if($day==sunday){ $this->sundayname=$name;} } //to output name $date=fetchdate(); $username=$db->fetch_username($user['userid']); echo $username->outputusername($date); //setname $_request['day']=$day; $_request['name']=$name; $usernamesettings=&new setname($day,$name); $serializedusernamesettings=serialize($usernamesettings); $db->set_username($user['userid'],$serializedusernamesettings); Now this is a poorly coded pretty useless example. But what it does it changes the way you can store information in the database. No longer does the dynamic information need to be contained in the script, rather the storage of information itself can be dynamic. You can store "ideas" rather than the rote data. I don't know... as I said I am not actively using this (yet), but it certainly seems pretty cool to me.
  5. Hm... so would a serialized object driven database (A relational database that inputs serialized objects) be a feasible and practical way of managing data storage? It would really open the door for some incredible power if it could be fully embraced.
  6. Hm, I thought about it for awhile, and I cannot see how there could be compatability issues when storing objects in the database. The serialized object is simply text, I would imagine that any database framework that has compatability issues with accepted serialized text would have greater troubles than mere object storage. Am I totally off base on this one?
  7. Is there really any reason not to use an object driven database system? It is of course unfortunate that PHP does not permit full serialization of class methods (but a simple class in itself could easily remedy this problem). What are your thoughts on object driven databases? I am curious as to whether or not anyone uses them.
  8. There is a kind of mystique in being able to take a unique "case" dynamically manipulate parameters, and then "SET" it. You can throw everything you want into a properly coded class, check the information while it is still magically suspended in the object, and then finally send off the data to the nearest database. It is a cool concept... but it is also something that is basically useless abstraction. There is a significant performance difference when using objects... it is just a fact of life especially with PHP4. (Lets face it, in a language like PHP that is relatively robust and fast, objects just don't stand as tall as the language's array components). However, I still find myself using OOP practices in just about all my coding. I find that it takes about the same amount of time to get everything "written" and I can better debug the technical aspects of my code by having a self contained class who's separate components can be individually "checked" and "ran" separately. Ultimately, however, alot of this stuff is never going to be used again, and it is hardly "too complicated" to code procedurally. Are any others out there like me, and enjoy using OOP simply because of the way it allows you to "think through your code" and even more imporantly, easily debug the individual components of your script? I hear extensibility, maintainability... but really I just use OOP because I like it better and it is easier for me to write. Any thoughts?
  9. Here is the solution: if(count(get_included_files())>1){ die("More than one included file"); } get_included_files() will return all included files in the form of an array including the current script.
  10. Right, but the user could discover what constant is necessary to include by running the above mentioned function and then set that constant in their own file before including the file that is not allowed to be included. For example, and pardon my shorthand: <?php define constant corbin=44 include file.php ?> <?php (file.php) if corbin=44 run script include non-encoded file.php ?> <?php (non-encoded file.php) //user adds below code get_defined_constants(); ?> The user now knows that in order to include file.php from another script all they need to do is first define the constant corbin to equal 44. With variables you could simply unset them after the check to prevent them from ever being outputted. In a properly secured script without any user-editable files that are part of the code, the constant idea works fine. But if the user were to ever have the opportunity to edit the code after the constant was defined, it would not be secure at all.
  11. Oh, perhaps that was part of the misunderstanding. This is for a php licensing system. (Just to keep this request in the last post of the thread: Still looking for a way to unconditionally prevent files from being included into other files.)
  12. They would be able to use the get_defined_constants() function to print all defined constants and their values. Constants cannot be undefined, unlike variables. Perhaps in a flawless script whereby it is impossible to include ANY code anywhere it would be fine to use constants, but I would prefer to easily be able to unset my variables after passing&verifying them to prevent any possibility of their values being discovered. PS. (Still trying to figure out a way to prevent inclusion unconditionally...) (Not trying to be a pain, just making sure that the last post in the thread includes this request.)
  13. Yes, but with a constant they could merely use the print constants function and discover the exact name and value of the constant being used. Variables can simply have random names (and even more securely random values) and in an encoded script would be completely unfindable provided that you use some due diligence in coding the system to prevent the variables from ever having the opportunity to be printed. With constants it is impossible to undefine them or prevent them from easily being discovered. I am still looking for a method of preventing inclusion without any exceptions, by the way. I have found a small security flaw in my system that requires it, otherwise I may have to get tricky (and my trickiness is inherantly less secure than purely preventing inclusion unconditionally would be) Thanks! ~Attilitus
  14. What about a method of preventing file inclusion entirely without any exceptions? Is that possible?
×
×
  • 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.