Page 2 of 2

Re: My take at an ORM for PHP

Posted: Tue Jul 01, 2008 10:26 am
by andre_c
Sorry about the delay, I've been busy working on the 0.3 version and the project website.
volomike wrote:* I don't understand why I need a subdirectory called docroot containing css, images, index.php. Are you trying to say that I would have my virtual directory, and then a parent directory to that where the libraries are stored?
I generally like to keep all of my library code, uploaded files, etc outside of the document root. It's not necessary, just a preference.
volomike wrote:* outlet-config.php. If there was a way to have an alternative version of this in INI or XML format, and then it gets parsed and cached in shared memory unless the file's mod date changes, that might be easier on its usage? Right now it has a kind of JSON-like format and it's easy to make a typo, frustrating a newbie user, limiting its acceptance.
I prefer the php format, but since I know a lot of people would prefer XML, INI, or YAML I will definitely work on that for the 0.4 release.
volomike wrote:* If table or column names are odd, like they include a dash inside or a reserved word, then you'll want to ensure these get the backtick operator used in your libraries for this, such as `account-records` instead of account-records. You might already be doing something like that -- but want to double check.
Outlet is not currently taking care of that. I'll be looking into what would be the best solution in the next few days. I wonder if, as a workaround for right now, we can define the table name and field names with the quotes (squared brackets for msssql) if they need them.
volomike wrote:How are dates stored in this ORM? You'll probably want to use the new PHP5 way to work with dates -- using DateTime() object. Also, on everything I do, I store things in GMT time and then I translate to the end user's timezone based on their browser's GMT +/- as it is announced to me when they hit my sites. In some cases I may permit the user to change their GMT setting -- depending on the type of website.
Right now they are handled as strings. I'm thinking about using the DateTime object. Maybe it can be an config option.


I'm working on a lot of improvements to the manual and the project website. I'll keep you posted.

Thanks for all the suggestions. I really I appreciate them.

Alvaro

Re: My take at an ORM for PHP

Posted: Tue Jul 01, 2008 11:13 am
by volomike
I'll have to think about that with the use of strings versus a DateTime object. It pretty much puts the onus on the end user to get the date properly formatted before storing in the database. Most guys don't trust what they get in the data entry, anyway, so they'll probably already be doing this in most cases. Therefore, strings might just work better than introducing the complexity of the DateTime object.

Yeah, I look forward to using a more INI-like or XML-like config file.

A reverse-engineer generator script for generating any necessary files would be nice. One could then tweak the output of those.

Special table and column names. Yeah, escaping this is fairly straight-forward and very necessary. I mean, it's so easy for one to use a column named 'date' or 'datetime', or to use dashes in one's column names instead of underscores, creating havoc with most SQL interpreters.

Re: My take at an ORM for PHP

Posted: Sun Jul 06, 2008 2:16 pm
by andre_c
I'm still working on the features we've been talking about. On the mean time, I redesigned the website to make it faster and easier to navigate.
http://www.outlet-orm.org

I also set up a google group (mailing list + forum) for the project at:
http://groups.google.com/group/outlet-orm
For right now, it will be used for usage questions, bugs, development, feature requests, etc. I might split it into more list later on. Please sign up and let me know what you think.

Thanks,
Alvaro

Re: My take at an ORM for PHP

Posted: Tue Jul 08, 2008 5:35 pm
by volomike
The only thing I was going to suggest on your website is that your main white content area use a min-height CSS property greater than 1024, such as 1100. This will handle most current flat-panel monitors and cause a vertical scrollbar to appear on all pages. That way, since you're using the DIV centering technique, the white content area won't jump around (wiggle) as one clicks each of the navigation links. It currently wiggles because some pages are long enough to have a vertical scrollbar, while others are not.