Jump to content

Buyocat

Members
  • Posts

    267
  • Joined

  • Last visited

    Never

Contact Methods

  • Website URL
    http://www.anotherearlymorning.com

Profile Information

  • Gender
    Not Telling

Buyocat's Achievements

Member

Member (2/5)

0

Reputation

  1. I'm running Ubuntu 7 and have installed PHP and Apache 2 through apt. I've modified my php.ini file (located in /etc/php5/cgi/php.ini) by uncommenting the line for the Unix include path and having it set to the following: include_path = ".:/var/www:/usr/share/php" (note I added /var/www) I then restarted apache and expected my include path to reflect this, but a script running phpinfo() reveals the include path to be the same. Anyone know what I'm doing wrong? Thanks!
  2. You've asked two questions. 1) Should I use a framework? If you're more comfortable working in your own format/style, and don't mind implementing a lot of common, possibly tricky/difficult routines yourself then don't bother with a framework. 2) Should I try to organize my code along the MVC pattern? Probably yes. At least it's worth having a separation of concerns so that you can more easily make changes to one section without effecting another section of code. A possible third question is how much separation? I think the answer to that needs to be made case-by-case. For most things you do less is probably enough. If you anticipate many people working with the code you're writing then air on the side of more separation.
  3. I'm not going to answer all of your questions here, but I'll try to answer the easier/important ones. 1) Properties which don't make directly to fields. We call public getters and setters so there doesn't need to be an actual single property which corresponds to a table. For instance, you could easily combine several properties in an object and return the result in some mapped getter. 2) Object structures? If you mean collections (such as a collection of emails which are dependent on a user object) that isn't yet implemented. That is the biggest feature which we are starting to look at now. 3) Data object requirements It must have a public constructor which either takes no parameters or has default values. For each property defined in the metadata file a public get and set property method is required. That's it. 4) Please check out the code which has some sample uses included. Also see the hosted code's wiki. 5) No tools exist to generate the metadata or data objects, but I've thought about it as a feature for the future (but it's lower priority). 6) Transactions are another big feature that we need to implement. One thing on the business objects, Junction really is expecting a data object, not a business object. By that I mean that the getting and setting is expected to return the value mostly as-is. For instance, if you had a User object with a setPassword() which hashed the password, that would lead to problems. In order to get a real business object you would need wrap around the data object. I have a sample User business object which I can (and will) publish on the hosted wiki.
  4. Over the summer I started a project which I would like to introduce to you. <a href="http://junctionphp.com/">[/u</a>rl]Junction is a new persistance layer, much like <a href="http://propel.phpdb.org/trac/">Propel</a>, written in PHP 5 and based on the popular Java persistance layer <a href="http://www.hibernate.org/">Hibernate</a>. A persistance layer is a little bit of software between the database and the application. It maps data objects (with getters and setters) to database tables. The goal is to automate basic query construction, decouple the application from the database, and allow for faster development. With Junction you write a simple data object (the only requirement is that it have getters and setters) and a mapping file, following that you can start interacting with the database. Following the open source mantra "release early, release often" I and my partners have chosen to release Junction. It is our hope that you will find yourself immediately productive with it. Over the course of the year we will be continuing development with a focus on several major features. Please see our project <a href="http://junctionphp.com/">web site</a> for more information.
  5. Ya, I'm not sure why it was failing. I only spent a few minutes trying to fix it, but failed. It's odd since my own code is public static function findFirst($haystack, $pattern) { preg_match($pattern, $haystack, $matches, PREG_OFFSET_CAPTURE); if (empty($matches)) return -1; return $matches[0][1]; } So, its very similar. Maybe the lack of the flag was the problem?
  6. I actually get an error running your script for some reason: Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING in /Users/Kanti/Sites/test.php on line 3 At any rate I ran my own test and find that the double quote and single quote do not pass through the current regex. Again, I want to find the first character which is not alphanumeric or a quote (single or double). As for symbols such as hyphons and underscores, I'm willing to have them work or not. Thanks for your response.
  7. I want to find the first character which is NOT alphanumeric (also quotes are allowed), but I'm not sure how to express that in regex. Can anyone lend a hand? The closest I can get is: /\W/ which almost works except it doen't catch the quote (double or single) correctly. Thanks!
  8. Personally I think you should let the size of the result sets, in this case the number of cities a state might "own", guide your decision. If you anticipate that on average a state will have many cities then you should implement a lazy-loading method which performs a second query; frankly a single query isn't that expensive, and this ensures that memory isn't wasted on large record sets that may not be used. On the other hand if you're anticipating a small number of cities to a given state then you don't have to worry about memory issues, and in that case shaving off a single query may be advantageous. Obviously there are other things that should be brought into consideration; for instance, how often does the application access all of the cities? Do states ever share instances of the same city (probably not in this case, but for another example such as customers/merchants it may be relevant)?
  9. dbo, I've actually changed the project slightly. You can see it here: http://code.google.com/p/junction/ It's a persistance layer which would allow you to use a data object instead of dealing with the database. Junction would take care of all the mapping of state between the database and your data object. If you'd like to talk more about it private message me.
  10. I will give an example from a project I'm working on right now. There's a config file which must be opened and then parsed to convert the config information into a hash table. The config information is used at several points in the application. I could read the config information at each point which would require opening the file and parsing it each time, or I could maintain a singleton of the config data object and access the information through the singleton. The result is I only have to read the file in once per a request.
  11. I've written these simple to use OO classes to encapsulate commonly performed tasks. I think they demonstrate when objects can be useful and do work for you. https://sourceforge.net/projects/utils-php/
  12. I second that, go with the PEAR naming convention and you will save yourself a lot of trouble down the road managing dependencies and namespace collisions.
  13. I personally dislike the frameworks I've used for the same reasons you've listed. That said here's a list of frameworks: php cake (I've used this and if you can't fit its style you'll hate it, based off of RoR) solar (I like this one the most, haven't used it but from looking at the code) symfony (haven't used it, but I hear Yahoo! uses it for something or another) There's also a lot of CMSs which aren't the same but might fit your needs or can be hacked to fit your needs: Symphony (it looks quite cool, it's pretty new, uses XSLT to generate the actual output) Drupal Joomla Expression Engine
  14. I think the common complaint against SOAP is that it is too verbose. You could take a look at REST and see if that protocol can fit into what you're doing. In the worst case you could simply not use an established protocol at all and write your own. The benefit would be it fits your needs perfectly, the drawback would be it is unlikely to work with other services, but that may not be a bad trade off depending on your goals. I haven't used code ignitor, though I've heard good things about it. I've also heard good things about the Zend framework. Frankly, I think so long as you're comfortable working within their environments any framework will do. Roopurt if you're just tryig to draw graphs I'm not sure why you're making a remote service. Given the fact that graphs are usually outputed as images or flash it would seems very costly to send them over the wire. There is a good PHP-flash graph drawing package you could use. http://www.maani.us/charts/index.php If you're using the java package because it queries the databases for the right combinations of data, and you're running into problems deploying the java server, then I would just look over the source code to determine what dimensions it's fetching from the DB and then port that over to PHP. All of that said I may be misunderstanding you, so why don't you start a new thread on the issue?
×
×
  • 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.