Re: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[Michael Shadle]

On Wed, Apr 22, 2009 at 2:41 PM, haliphax  wrote:
> On Wed, Apr 22, 2009 at 11:25 AM, Michael Shadle  wrote:
>> On Wed, Apr 22, 2009 at 6:20 AM, haliphax  wrote:
>>
>>> Michael,
>>>
>>> Given the fact that Gears requires a client-side installation, has an
>>> awful penetration percentage, and his original solution is all
>>> server-side (though it does require APC and YUI-JS), I wouldn't say
>>> this is a very good suggestion. Compared to what he has already found,
>>> the Gears solution is not "clean" by any stretch of the imagination.
>>
>> a) the native solution that requires APC is not multi-webserver capable
>> b) i was just sharing a different approach to an idea. who knows. it
>> might be something to explore. gears is pretty lightweight, and for
>> the ease of this and the functionality it brings (not to mention
>> cross-browser+platform) i see a compelling reason to give it a shot.
>> c) the APC method -still- requires webserver tweaks and post max size
>> etc. this is sending small chunks of data, is proxy-safe, and requires
>> nothing on the server; all that is required is gears, which is a
>> library to extend your browser's capabilities and i have not heard any
>> issues with it or security holes thus far. penetration is an issue but
>> when more sites push it and say "hey, you should install it" the
>> penetration will grow. not to mention youtube for example is using
>> roughly the same method and picking up a lot of browser installs off
>> that.
>
>> i completely disagree it is not "clean" - it is literally one browser
>> addon that a lot of people do have, comes from a reputable company,
>> and creates basically limitless upload capabilities - i can do 300 meg
>> files without blinking - it's not one long single POST that can fail
>> anytime, it's lots of small POST requests; it takes basic PHP on the
>> server and then some javascript for the UI (all the pieces to get a
>> basic functional install i sent links to)
>
> Unless you are in a corporate environment where you control what is
> installed on your visitors' machines, then just about any server-side
> hell you have to put yourself through is "cleaner" to the client than
> them needing to install ANYTHING.
>
> I'm sorry if my opinion seems a little too "black and white," but
> those are the breaks. I can definitely say that, coming from a higher
> education institution standpoint, the site I work on would ALWAYS do
> something server-side and exhaust all of those possibilities before
> forcing prospective students, applicants, etc. to download additional
> software for their web browser.
>
> It depends on the clientele, really.

It also depends on the servers.

If you're behind load balanced webservers, the APC solution is out.
If you're on a shared hosting solution, it most likely is out (due to
some config tweaking)
You're limited to the POST size limits and other file upload
limitations inside of php.ini on the server

etc.

If your clientele find it useful enough, they will download it. People
are stupid enough to click on viruses, why would they not click on
something that comes from a reputable source as well, and promises
them large file uploads, looks like it is part of the website (and not
some hokey looking UI from an applet) and is SSL-friendly,
proxy-friendly, etc, etc...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[haliphax]

On Wed, Apr 22, 2009 at 11:25 AM, Michael Shadle  wrote:
> On Wed, Apr 22, 2009 at 6:20 AM, haliphax  wrote:
>
>> Michael,
>>
>> Given the fact that Gears requires a client-side installation, has an
>> awful penetration percentage, and his original solution is all
>> server-side (though it does require APC and YUI-JS), I wouldn't say
>> this is a very good suggestion. Compared to what he has already found,
>> the Gears solution is not "clean" by any stretch of the imagination.
>
> a) the native solution that requires APC is not multi-webserver capable
> b) i was just sharing a different approach to an idea. who knows. it
> might be something to explore. gears is pretty lightweight, and for
> the ease of this and the functionality it brings (not to mention
> cross-browser+platform) i see a compelling reason to give it a shot.
> c) the APC method -still- requires webserver tweaks and post max size
> etc. this is sending small chunks of data, is proxy-safe, and requires
> nothing on the server; all that is required is gears, which is a
> library to extend your browser's capabilities and i have not heard any
> issues with it or security holes thus far. penetration is an issue but
> when more sites push it and say "hey, you should install it" the
> penetration will grow. not to mention youtube for example is using
> roughly the same method and picking up a lot of browser installs off
> that.

> i completely disagree it is not "clean" - it is literally one browser
> addon that a lot of people do have, comes from a reputable company,
> and creates basically limitless upload capabilities - i can do 300 meg
> files without blinking - it's not one long single POST that can fail
> anytime, it's lots of small POST requests; it takes basic PHP on the
> server and then some javascript for the UI (all the pieces to get a
> basic functional install i sent links to)

Unless you are in a corporate environment where you control what is
installed on your visitors' machines, then just about any server-side
hell you have to put yourself through is "cleaner" to the client than
them needing to install ANYTHING.

I'm sorry if my opinion seems a little too "black and white," but
those are the breaks. I can definitely say that, coming from a higher
education institution standpoint, the site I work on would ALWAYS do
something server-side and exhaust all of those possibilities before
forcing prospective students, applicants, etc. to download additional
software for their web browser.

It depends on the clientele, really.


-- 
// Todd

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions of some good, simple file upload 'in

[Bradley Broerman]

 If you'd like a simple Java Applet that can do the file upload, and
is scriptable through JavaScript, I have a fairly nice one that uses
FTP to upload the file. It has real-time feedback to the webapp, and
has a PHP webservice that it communicates with for authentication, and
notification. I also have one that will use SFTP if security is an
issue.  
 They're both on my home page http://www.bbroerman.net  just click on
the "My Code" button on the menu to go to the correct page.   
 I'll also help with any install questions, etc.   
 Cheers,  

 Brad Broerman  

   

Re: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[Michael Shadle]

On Wed, Apr 22, 2009 at 6:20 AM, haliphax  wrote:

> Michael,
>
> Given the fact that Gears requires a client-side installation, has an
> awful penetration percentage, and his original solution is all
> server-side (though it does require APC and YUI-JS), I wouldn't say
> this is a very good suggestion. Compared to what he has already found,
> the Gears solution is not "clean" by any stretch of the imagination.

a) the native solution that requires APC is not multi-webserver capable
b) i was just sharing a different approach to an idea. who knows. it
might be something to explore. gears is pretty lightweight, and for
the ease of this and the functionality it brings (not to mention
cross-browser+platform) i see a compelling reason to give it a shot.
c) the APC method -still- requires webserver tweaks and post max size
etc. this is sending small chunks of data, is proxy-safe, and requires
nothing on the server; all that is required is gears, which is a
library to extend your browser's capabilities and i have not heard any
issues with it or security holes thus far. penetration is an issue but
when more sites push it and say "hey, you should install it" the
penetration will grow. not to mention youtube for example is using
roughly the same method and picking up a lot of browser installs off
that.

flash started out as a baby too. even java did (inside of browsers) ...

i completely disagree it is not "clean" - it is literally one browser
addon that a lot of people do have, comes from a reputable company,
and creates basically limitless upload capabilities - i can do 300 meg
files without blinking - it's not one long single POST that can fail
anytime, it's lots of small POST requests; it takes basic PHP on the
server and then some javascript for the UI (all the pieces to get a
basic functional install i sent links to)

how is that not "cleaner" than requiring the right version of apc,
hoping that one single long POST doesn't fail, etc?

our next version will include re-transmission on any chunk failure and
some other stuff, too. we're talking about literally any file size,
and even multiple file support, with the capability to retry on
failure so you -know- your file will get there, no matter if you're on
fast broadband or third world connectivity. we've dealt with issues
for years with people in geos having to send us links to files and
have us upload them for them... not anymore.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[Andrea Giammarchi]

nobody knows my last creation?
http://code.google.com/p/noswfupload/
full example with PHP back end in the zip.


P.S. ... just in case ... the first upload progress for PHP with Ajax and NO 
APC ( ages ago, still me: http://www.devpro.it/upload_progress/ )
Flash FileReference porting ... still me, before SWFUpload solution or others 
Flash based: http://www.devpro.it/FileReference/
Finally, last attemp before noswfupload, jQuery plus APC for uplaod progress 
meter: 
http://webreflection.blogspot.com/2007/10/upload-progress-bar-with-php5-apc-and.html

I kinda worked with "uploaders" since I used bottle I guess :D

Regards


> Date: Wed, 22 Apr 2009 08:20:28 -0500
> From: halip...@gmail.com
> To: php-general@lists.php.net
> Subject: Re: [PHP] Re: Suggestions of some good, simple file upload 'in   
> progress' code?
> 
> On Tue, Apr 21, 2009 at 11:35 PM, Michael Shadle  wrote:
> > On Tue, Apr 21, 2009 at 9:02 PM, scubak1w1  wrote:
> >>
> >> ""scubak1w1""  wrote in message
> >> news:cf.13.21597.2ee8e...@pb1.pair.com...
> >>> Hello,
> >>>
> >>> Can someone pass on some suggestions of some good, simple file upload 'in
> >>> progress' code?
> >>>
> >>> Maybe as simple as changing the cursor icon for the duration?
> >>
> >> [self snip!]
> >>
> >> http://www.johnboy.com/about-us/news/a-useful-php-file-upload-progress-meter
> >> seems to be the "cleanest" example I can find - would this be fair to say?
> >
> > Google Gears makes it very easy and can make it very simple (no
> > webserver configuration required) to basically slice the file up and
> > send chunks via POST - I need to publish all the code and a howto, and
> > Valery has written some code for nginx that might make it alleviate
> > the need for PHP to be involved at all - I have still not tested that
> > though, but the PHP code required is only like 10 lines or so, the
> > Gears stuff is pretty basic Javascript and since it's Javascript you
> > can make it match your UI perfectly by filling in div tags or whatever
> > else you want (works great with jQuery)
> >
> > Actually I have a demo, not the cleanest code if you view the source
> > but you get the idea. It also works over NFS with multiple webservers
> > writing to the same file (I have 3 webservers behind LVS so
> > technically your request could be going to any of them)
> >
> > http://mikehost.com/~mike/tmp/u/ <- frontend and view source to see gears + 
> > js
> > http://mikehost.com/~mike/tmp/u/temp.php.txt <- server side piece
> >
> > I can't find the latest/cleanest code, but it gives you an idea.
> 
> Michael,
> 
> Given the fact that Gears requires a client-side installation, has an
> awful penetration percentage, and his original solution is all
> server-side (though it does require APC and YUI-JS), I wouldn't say
> this is a very good suggestion. Compared to what he has already found,
> the Gears solution is not "clean" by any stretch of the imagination.
> 
> 
> Greg,
> 
> I believe the link you posted is a very elegant solution that does not
> (at first glance) involve Flash objects or Java applets. I'm a little
> disappointed that a particular JS framework is necessary, but that's
> just the nature of the beast with this sort of thing. If I were you,
> I'd run with the "native" PHP solution you've already found. Maybe you
> can even crack open the JS and find a way to do it with your favorite
> framework as opposed to YUI...
> 
> 
> My 2c,
> 
> 
> -- 
> // Todd
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 

_
More than messages–check out the rest of the Windows Live™.
http://www.microsoft.com/windows/windowslive/

Re: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[haliphax]

On Tue, Apr 21, 2009 at 11:35 PM, Michael Shadle  wrote:
> On Tue, Apr 21, 2009 at 9:02 PM, scubak1w1  wrote:
>>
>> ""scubak1w1""  wrote in message
>> news:cf.13.21597.2ee8e...@pb1.pair.com...
>>> Hello,
>>>
>>> Can someone pass on some suggestions of some good, simple file upload 'in
>>> progress' code?
>>>
>>> Maybe as simple as changing the cursor icon for the duration?
>>
>> [self snip!]
>>
>> http://www.johnboy.com/about-us/news/a-useful-php-file-upload-progress-meter
>> seems to be the "cleanest" example I can find - would this be fair to say?
>
> Google Gears makes it very easy and can make it very simple (no
> webserver configuration required) to basically slice the file up and
> send chunks via POST - I need to publish all the code and a howto, and
> Valery has written some code for nginx that might make it alleviate
> the need for PHP to be involved at all - I have still not tested that
> though, but the PHP code required is only like 10 lines or so, the
> Gears stuff is pretty basic Javascript and since it's Javascript you
> can make it match your UI perfectly by filling in div tags or whatever
> else you want (works great with jQuery)
>
> Actually I have a demo, not the cleanest code if you view the source
> but you get the idea. It also works over NFS with multiple webservers
> writing to the same file (I have 3 webservers behind LVS so
> technically your request could be going to any of them)
>
> http://mikehost.com/~mike/tmp/u/ <- frontend and view source to see gears + js
> http://mikehost.com/~mike/tmp/u/temp.php.txt <- server side piece
>
> I can't find the latest/cleanest code, but it gives you an idea.

Michael,

Given the fact that Gears requires a client-side installation, has an
awful penetration percentage, and his original solution is all
server-side (though it does require APC and YUI-JS), I wouldn't say
this is a very good suggestion. Compared to what he has already found,
the Gears solution is not "clean" by any stretch of the imagination.


Greg,

I believe the link you posted is a very elegant solution that does not
(at first glance) involve Flash objects or Java applets. I'm a little
disappointed that a particular JS framework is necessary, but that's
just the nature of the beast with this sort of thing. If I were you,
I'd run with the "native" PHP solution you've already found. Maybe you
can even crack open the JS and find a way to do it with your favorite
framework as opposed to YUI...


My 2c,


-- 
// Todd

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[Michael Shadle]

On Tue, Apr 21, 2009 at 9:02 PM, scubak1w1  wrote:
>
> ""scubak1w1""  wrote in message
> news:cf.13.21597.2ee8e...@pb1.pair.com...
>> Hello,
>>
>> Can someone pass on some suggestions of some good, simple file upload 'in
>> progress' code?
>>
>> Maybe as simple as changing the cursor icon for the duration?
>
> [self snip!]
>
> http://www.johnboy.com/about-us/news/a-useful-php-file-upload-progress-meter
> seems to be the "cleanest" example I can find - would this be fair to say?

Google Gears makes it very easy and can make it very simple (no
webserver configuration required) to basically slice the file up and
send chunks via POST - I need to publish all the code and a howto, and
Valery has written some code for nginx that might make it alleviate
the need for PHP to be involved at all - I have still not tested that
though, but the PHP code required is only like 10 lines or so, the
Gears stuff is pretty basic Javascript and since it's Javascript you
can make it match your UI perfectly by filling in div tags or whatever
else you want (works great with jQuery)

Actually I have a demo, not the cleanest code if you view the source
but you get the idea. It also works over NFS with multiple webservers
writing to the same file (I have 3 webservers behind LVS so
technically your request could be going to any of them)

http://mikehost.com/~mike/tmp/u/ <- frontend and view source to see gears + js
http://mikehost.com/~mike/tmp/u/temp.php.txt <- server side piece

I can't find the latest/cleanest code, but it gives you an idea.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Suggestions of some good, simple file upload 'in progress' code?

[scubak1w1]

""scubak1w1""  wrote in message 
news:cf.13.21597.2ee8e...@pb1.pair.com...
> Hello,
>
> Can someone pass on some suggestions of some good, simple file upload 'in 
> progress' code?
>
> Maybe as simple as changing the cursor icon for the duration?

[self snip!]

http://www.johnboy.com/about-us/news/a-useful-php-file-upload-progress-meter 
seems to be the "cleanest" example I can find - would this be fair to say?

Cheers... 



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions for Web based FileServer/Mailaccess

[Richard Lynch]

On Thu, April 19, 2007 11:42 am, Michelle Konzack wrote:
> Hello Richard,
>
> It seems no one had understood me right...
>
> Am 2007-04-10 21:48:12, schrieb Richard Lynch:
>> Personally, I would use http://php.net/imap_open and friends to add
>> the mailbox, and let the OS and installed IMAP software choose the
>> correct mbox/Maildir option based on the server configuration,
>> rather
>> than try to out-guess them...
>
> This is WHAT I already do...
>
> But currently I have two Spaces:
> The one for the E-Mails and one for the files
>
> WHich mean, if I ahve a friend called "Richard" and his Messages goes
> into the Mailfolder "Peoples/Richard" and I want to see what I have
> from him, like Files, Pics or whatever... I have to go to a second
> place the "File Section" to look at it.
>
> What I want is a fusion of the "MailSpace" and the "FileSpace".
>
> Currently I have a black hole and do not know HOW to implement this.
>
> In general, EACH "Mailfolder" can have a "FileSpace" and visa versa.

Where do the Files come from in the first place?
Attachments?
External source?
...

If they were attachments, maybe you'd be better off just leaving them
in the Maildir...

I suppose you could build a parallel File System to your Maildirs,
then within each of those, make a directory by Message-id: header,
then put any attachments with the cid: name as the file name.

That should make everything unique...

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Suggestions for Web based FileServer/Mailaccess

[Michelle Konzack]

Hello Richard,

It seems no one had understood me right...

Am 2007-04-10 21:48:12, schrieb Richard Lynch:
> Personally, I would use http://php.net/imap_open and friends to add
> the mailbox, and let the OS and installed IMAP software choose the
> correct mbox/Maildir option based on the server configuration, rather
> than try to out-guess them...

This is WHAT I already do...

But currently I have two Spaces:
The one for the E-Mails and one for the files

WHich mean, if I ahve a friend called "Richard" and his Messages goes
into the Mailfolder "Peoples/Richard" and I want to see what I have
from him, like Files, Pics or whatever... I have to go to a second
place the "File Section" to look at it.

What I want is a fusion of the "MailSpace" and the "FileSpace".

Currently I have a black hole and do not know HOW to implement this.

In general, EACH "Mailfolder" can have a "FileSpace" and visa versa.

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

[PHP] Re: Suggestions of GPL plugin-system?

[Ivo F.A.C. Fokkema]

Thanks everyone for the useful input. I've looked around a bit using the
various links and info that I got. The Gallery2 documentation on the
modules is far from transparent to me, and the idea of having a general
module class that needs to get extended by the module doesn't appeal to
me either. I really like the Drupal system with it's "hooks" and I like
the idea of having my project communicate with various modules through
these hooks. The whole system with the API is kinda big though, and right
now I don't plan to give modules control over my menu or anything.

So I guess, inspired by the Drupal system, I'm going to create a much
smaller system that I will implement myself...

Thanks again!

Ivo

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Suggestions of GPL plugin-system?

[Globalissa Info]

Hello All (cc Ivo),
We have numerous modules in various software titles and these are included by
a simple conditional statement. If they exist, then include them.


Example:





... another example:



   
// your code here
   



This works well for modules because if they don't exist then they aren't used.
You can use a constant for the installation absolute url when testing for
existence of the file. Also if you always put modules in your /modules folder
then you'll know where to look for them in any software title.  There's other
examples and other code in our free unencrypted phpYellow Lite Edition
downloadable at http://www.globalissa.com/downloads.php . You might also
notice that the @ character can be used to suppress issues with the
conditional call - test that first, and use it sparingly.


Sincerely,
Rob.
http://phpyellow.com

___
Ivo wrote:
Hi guys,

I've been developing a GPL PHP/MySQL app for some time now and I would
like to extend it with a module/plugin system. The idea would be that
people could add a directory in a plugin path that would contain a
bunch of PHP files extending the functionality of my application. This
directory would then be read out, some config file parsed and whatnot,
after which the module can be turned on by my application.

Now, I could try and figure this out by myself, but that would be
reinventing the wheel since I'm betting there is some good GPL modular
software around (such as Joomla, PHP-Nuke, PHPbb, etc, etc.) that you have
been working with as a coder. Could any of you suggest a certain GPL
application that has a great module setup that I could take a look at?

Thanks a lot for your time!

Ivo 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Suggestions of GPL plugin-system?

[Michael Weaver]

Hi Ivo,

I have been developing and working with a PHP Application Toolkit/ 
Framework over the last 6 - 7 years and have been actively working on  
developing a system that is extensible through custom modules while  
retaining a stable 'core' codebase.


The source code is available at:

http://dynacore.sourceforge.net
http://www.dynacore.org

as well as through the sourceforge project website:

http://www.sourceforge.net/projects/dynacore

There are three factories that inherit from one another to activate  
modules from each of three subdomains:


application }  project-specific custom modules
dynacore}  system core
dynapro }  proprietary purchased modules

I don't know whether this helps, and I'm sure that there are many  
other ways to do this, but it has worked well on a variety of  
projects on my end to help use a 'standard' codebase while being able  
to customize it on a per project or per application basis.


Best regards,

Mike Weaver

--
Michael Weaver
Founder/Chief Facilitator
Dynamic Insight
Enhancing Professional Awareness &  Communication
Tel: 1.814.574.4871
Email: [EMAIL PROTECTED]

The information in this email and subsequent attachments may contain
confidential information that is intended solely for the attention  
and use of
the named addressee(s). This message or any part thereof must not be  
disclosed,
copied, distributed or retained by any person without authorization  
from the
addressee. If you are not the intended recipient, please contact the  
sender by

reply email and destroy all copies of the original message.

[PHP] Re: Suggestions of GPL plugin-system?

[Colin Guthrie]

Ivo F.A.C. Fokkema wrote:
> Hi guys,
> 
> I've been developing a GPL PHP/MySQL app for some time now and I would
> like to extend it with a module/plugin system. The idea would be that
> people could add a directory in a plugin path that would contain a
> bunch of PHP files extending the functionality of my application. This
> directory would then be read out, some config file parsed and whatnot,
> after which the module can be turned on by my application.
> 
> Now, I could try and figure this out by myself, but that would be
> reinventing the wheel since I'm betting there is some good GPL modular
> software around (such as Joomla, PHP-Nuke, PHPbb, etc, etc.) that you have
> been working with as a coder. Could any of you suggest a certain GPL
> application that has a great module setup that I could take a look at?

By far and away the nicest modular installer system I have ever seen is
that included in Gallery2 (http://gallery.menalto.com/).

It handles nicely fresh installs, upgrades and other such things.

I've never coded with it, so don't know what it's like to rip out and
use in other applications, but I think I recall reading a while back
that they were designing it to be easy to use it in this way.

I've used Joomla a lot and while I really like it as a CMS, the current
(1.0.x) stable series has a shocking system for modules etc. Quite often
there is no easy way to upgrade which is a real PITA. I think the 1.5
beta goes some way to resolve this tho' (I certainly hope so!).

So my advice would be to check out Gallery2 and see where that goes.

Best of luck

Col.

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/20/2005 01:51 PM Murray @ PlanetThoughtful said the following:

I do not understand why this could bother you or anybody else. If you
have a better solution, nothing stops you to make your recommendations.


Hi Manuel,

I did make my recommendation. To you. It went something like (and I'm
paraphrasing), "Your proposed solution doesn't solve the original poster's
conceptual problem with abstracting classes that deal with collections of
objects in conjunction with classes that abstract single objects."

In other words, and I realize I'm stretching out on a limb with this
metaphor, I saw in your post an attempt to treat the symptoms without
offering a cure for the disease.


That is your impression because you really do not know how Metastorage 
generated code works.


It provides several types of functions that retrieve and manipulate 
collection. Retrieval is done by storing all collection objects in an 
array that is returned by those functions. There is no need for a 
separate class to abstract collections.




And your perception of bias may or may not be accurate. I don't recall
delivering wrath-of-god denunciation of your suggestion to use a project you
developed, just acknowledged a desire to promote a project you're probably
(and perhaps justifiably) proud of. You say that wasn't a component of your
recommendation. I'm willing to accept that, not that I expect you to be
losing any sleep over whether or not I believe you.



The problem is that I am not promoting Metastorage because I am proud of 
it. Actually I do not promote any of my projects because of pride or any 
other ego related reasons. I wish some people did not guess that wrong, 
but I admit that sometimes it is hard to make certain intentions clear.


I let others know about my projects because that helps maximizing the 
chance of getting valuable feedback from potential users like bug 
reports and feature suggestions. This is good for me because ultimately 
I also benefit from any improvements done on my projects due to user 
feedback.


Anyway, it would be pointless for me to let other people know about 
projects of mine that do not address their needs, as that would not 
raise their interest.


What I am trying to tell you is that while I may not be clear enough, I 
was trying to tell the original poster how Metastorage solves the 
problem he wants to solve. That does not mean he will be interested to 
use Metastorage, but at least it may raise his interest in studying how 
Metastorage solve his problem. If he will become interested in 
Metastorage later, I am not concerned. If he will, fine, if he doesn't, 
no problem either.





Thank you for the extra explanation. I still don't understand the comment's
relevancy to the actual question being asked by the original poster, but I
will explain, in case it's of interest, why that comment caused me some
confusion:

- The original poster outlined that he had created a class that represented
a customer.

- He told the list he was having difficulties with the concept of
abstracting a collection of customers

- He received some helpful suggestions from the list about how to approach
that task

- None of which would have meant he was 'trying to retrieve objects into
memory before they exist.' I don't know about anyone else, but what that
comment implied to me was that the original poster was attempting to
instantiate a class as an object before including the file that contained
the class definition.


No, that was not my point. My point is that if you want to get a 
collection of customers, you want a list of objects that may contain 
more than one. Therefore what represents better a list of objects of 
some class, is not an object of a class, but rather an array eventually 
created by a factory object.


I do not think it does not make much sense that the factory object be of 
the same class of the list of objects that you want to retrieve. So, 
first you create the factory class object and then it will retrieve the 
customer objects into an array. What he was doing is to make the 
customer class a factory for a collection of its own objects.


I am not sure if my comment is clearer now.

--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/20/2005 10:04 AM Michael Sims said the following:

This is not to trivialize your Metastorage project (or, to be more
accurate, I know nothing about it, so it's not my place to trivialize
it or otherwise), but to point out that 'out-of-the-box' solutions to
fundamental coding development problems probably ultimately makes for
a poorer programmer. I could well be wrong, but it seems this is a
case of "give a man a fish" as opposed to "teach a man to fish".


I see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've
used.  I think we both suggested existing ORM's for the same reason...
namely that properly implementing a full featured ORM is an extremely
difficult thing to get right.  I don't know anything about Chris's skill as
a programmer, but he's bound to reinvent the wheel several times over, and
poorly to boot.  I believe that implementing an ORM is one of those things
that you cannot fully understand and appreciate until you've tried to do it
and failed.  IMHO it's only after you've built one that you realize what you
really need, and by then it needs to be rebuilt.  It's kind of like Fred
Brook's "plan to throw one away; you will, anyhow", or at least it was for
me.


Right, I could not have said it better, especially the part about people 
that prefer to break their heads trying to do something that others have 
done, providing much more mature solutions.


I am including myself in that group of people. 3 years ago I started 
developing Metastorage but only after have looked at several solutions 
and learned they had too many deficiencies to be adopted. That study 
helped me realizing what would be the important design mistakes to avoid.




Another thing I had
done halfway was support for querying objects (without using SQL).
Basically I had created different types of criteria that could be used, but
my support for criteria wasn't general enough.  IOW, if I didn't forsee that
you would want a particular type of criteria, then you couldn't use it.
Propel gets this right by supporting any arbitrary criteria using their
Criteria object approach (and I'm sure Metastorage has similiar
functionality).  If you can represent it using SQL, you can represent it
using Propel's Criteria.


Metastorage provides its own OQL (Object Query Language). This means 
that you can define functions for your ORM to query objects and 
associate a search expression using that OQL. Metastorage compiles that 
expression into SQL at code generation time, that may include parameters 
to be passed to the function at run time.


This way the code generated by Metastorage does not waste time or memory 
building the SQL search clause at runtime, because all query decisions 
are antecipated at run time. This results in fast code that is very compact.




I think it's important to point out, however, that I have learned just as
much from using Propel as I did from creating my own ORMI didn't just
simply drop Propel into place and run with it.  First of all, I modified it
a good bit to work better for my environment.  Secondly, as a general rule I
don't incorporate any third-party code/libraries into my codebase without at
least doing a cursory review through the code.  Since I was particularly
interested in how this problem was solved, I investigated it more thorougly
than I normally would.


Right. I feel that I need to clarify that Metastorage approach seems to 
be very different from Propel. Metastorage generates self-contained code.


This means that it generates code that does not depend on extra 
libraries to perform its function, which is ORM. Of course it uses 
Metabase to access the database but Metabase does not implement the base 
ORM functionality. Other than that, Metastorage generated code does not 
depend on anything else.




Now, with all that said, it's possible that Chris isn't to the point where
he would benefit much from plugging in another ORM...in order to learn from
someone else code you at least have to have a basic understanding of the
problem they are trying to solve, or it will all be greek to you.  And if
that's the case then you're right, it might hurt more than it will help.  So
let me amend my recommendation by saying "check out Propel/Metastorage if
you're willing to actually study the approach it takes as opposed to simply
plugging it in". :)


Right, regardless of what Chris decide, my suggestion was not to use 
Metastorage but rather take a look first to what generates. Metastorage 
generated code even comes with comments so it easier to understand what 
it does and why.



--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer ge

RE: [PHP] Re: Suggestions for class design

[Chris W. Parker]

Murray @ PlanetThoughtful 
on Tuesday, September 20, 2005 8:15 AM said:

> And it's also worth mentioning at this point that it might present
> more of a challenge to the original poster to implement and make use
> of a complex data abstraction package [1] than to learn a solution
> that not only addresses his specific question but also helps in his
> learning as a programmer.

Yep. You got it.

Basic building blocks are much better for me than taking an already
mature system and shoehorning it into my app, or rather, shoehorning my
app into it.


Chris.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Suggestions for class design

[Michael Sims]

Murray @ PlanetThoughtful wrote:
> My post was not aimed at saying 'using packaged approaches to solve
> coding problems is bad', but to say 'the original poster is asking a
> fundamental learning question, so a packaged approach will possibly,
> maybe even probably, hamper his development as a programmer at this
> point.'
[...]

Gotcha.  Makes sense; thanks for explaining...

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

> > This is not to trivialize your Metastorage project (or, to be more
> > accurate, I know nothing about it, so it's not my place to trivialize
> > it or otherwise), but to point out that 'out-of-the-box' solutions to
> > fundamental coding development problems probably ultimately makes for
> > a poorer programmer. I could well be wrong, but it seems this is a
> > case of "give a man a fish" as opposed to "teach a man to fish".
> 
> I see your point, but I'm not so sure I agree fully.  Manuel suggested
> Metastorage (which makes sense, it's his project and he's most
> familiar/comfortable with it), I suggested Propel because that is what
> I've
> used.  I think we both suggested existing ORM's for the same reason...
> namely that properly implementing a full featured ORM is an extremely
> difficult thing to get right.  I don't know anything about Chris's skill
> as
> a programmer, but he's bound to reinvent the wheel several times over, and
> poorly to boot.  I believe that implementing an ORM is one of those things
> that you cannot fully understand and appreciate until you've tried to do
> it
> and failed.  IMHO it's only after you've built one that you realize what
> you
> really need, and by then it needs to be rebuilt.  It's kind of like Fred
> Brook's "plan to throw one away; you will, anyhow", or at least it was for
> me.

Hi Michael,

You've hit on a point that I implied in my original post, but should have
been more explicit about. If I can add some emphasis: * IMHO it's only after
you've built one that you realize what you really need *

I couldn't agree more. As I read and understand the original poster's
question, he is still in the 'building one' phase of his development as an
OO PHP coder. If this wasn't the case, I doubt he'd be asking the question
he asked.

My post was not aimed at saying 'using packaged approaches to solve coding
problems is bad', but to say 'the original poster is asking a fundamental
learning question, so a packaged approach will possibly, maybe even
probably, hamper his development as a programmer at this point.' Put another
way, working out how to implement a class to handle the question he asked
would not be incredibly challenging, particularly with the help and advice
of people on this list, and would add to his understanding of how OO works
generically and in PHP. Both very good things.

I use several package solutions in my own projects. Notably, MDB2 and
HTML_QuickForm. I use MDB2 because it means my projects can be more flexible
to any decisions made to change the backend storage technology. I use
HTML_QuickForm because it provides convenient methods to building forms, and
it minimizes the mixture of HTML and PHP code in my pages, something I
personally prefer. Having said which, before adopting either of these
packages I was satisfied that I understood how to achieve the same results
using nothing more than my own coding skills. 

In other words, as a programmer I am comfortable working directly with a
variety of data storage backends, employing classes to abstract different
collections of data objects. I am comfortable building, validating, and
processing forms. The packages I use are for convenience, rather than
placing me at arm's length to understanding the programming concepts and
needs they address.

Also, I don't disagree that there are some brilliant packages out there,
written by people who've taken time to learn more about a specific problem
or set of problems than the average programmer would have to spend,
particularly across the broad range of coding demands an application may
touch upon. Again I reiterate: using packages to address application needs
is not a bad thing, while avoiding learning the basics of programming by
using such packages almost certainly is, particularly if you're taking your
development as a programmer seriously, and consider yourself to be aiming at
becoming a 'professional' programmer.

[here there be snippage]

> My point is, I had implemented my own home grown ORM about 3-4 times, and
> while each one was much better than the one that preceded it, I still
> wasn't
> quite all the way towards a 100% general implementation.  That's when I
> found Propel.  It got so many things right that I hadn't figured out how
> to
> solve, as well as implementing things that I hadn't even considered yet.
> 
> Now, you could argue that going through all those iterations and
> refactoring
> my own ORM helped me to improve my skills as a programmer, and you would
> be
> right.  That's where I agree with you, somewhat. :)  However, I was many
> many iterations away from improving my ORM to the point where it would be
> as
> useful as Propel (and that's assuming it would ever be that useful).  The
> guys who developed it (and I'm sure the same goes for Manuel and
> Metastorage) concentrated on making the best general purpose ORM they
> could
> make.  IOW their whole goal was to build an ORM, while my goal each time
> was
> to develop one for 

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

[snippage]

> I do not understand why this could bother you or anybody else. If you
> have a better solution, nothing stops you to make your recommendations.

Hi Manuel,

I did make my recommendation. To you. It went something like (and I'm
paraphrasing), "Your proposed solution doesn't solve the original poster's
conceptual problem with abstracting classes that deal with collections of
objects in conjunction with classes that abstract single objects."

In other words, and I realize I'm stretching out on a limb with this
metaphor, I saw in your post an attempt to treat the symptoms without
offering a cure for the disease.

Actually, that really is a terrible metaphor. I'm certain I'll think of a
better one about 3 seconds after I hit 'send'. Isn't that always the way?

And your perception of bias may or may not be accurate. I don't recall
delivering wrath-of-god denunciation of your suggestion to use a project you
developed, just acknowledged a desire to promote a project you're probably
(and perhaps justifiably) proud of. You say that wasn't a component of your
recommendation. I'm willing to accept that, not that I expect you to be
losing any sleep over whether or not I believe you.

This is a reality of expressing opinions on a public list: others are free
to disagree with you. See Michael Sims' response to the same post you're
addressing here. He makes some great points and I for one am glad he had an
opportunity to make them in response and counterpoint to a post I made. His
thoughts enrich the list, as do yours, and as, I hope, do mine.

> > This is not to trivialize your Metastorage project (or, to be more
> accurate,
> > I know nothing about it, so it's not my place to trivialize it or
> > otherwise), but to point out that 'out-of-the-box' solutions to
> fundamental
> > coding development problems probably ultimately makes for a poorer
> > programmer. I could well be wrong, but it seems this is a case of "give
> a
> > man a fish" as opposed to "teach a man to fish".
> 
> I think you should have learned about Metastorage first before
> commenting. It is not really a out-of-the-box solution. It is a code
> generator tool that employs well known design patterns to generate code
> to customized to the developer needs.

At some point I just may do that. It's an interesting concept, if nothing
else. My comments remain relevant, however, regardless of my knowledge of
your project. At least, and this is important, that's my opinion.

> > Also, and separate from above, I don't understand the relevance of your
> > comment, "You are trying to retrieve objects into memory before they
> exist".
> > Unless I'm horribly mistaken [1], the original poster has developed a
> class
> > that abstracts a single customer, and is asking the list for suggestions
> in
> > how to best approach a need to be able to abstract collections of
> customers.
> > This is a normal application development issue, and for the life of me I
> > can't grasp how your comment relates.
> 
> I tried to explain in the part of the message that you did not quote,
> why using a factory class as entry point, which is my suggestion, it
> makes more sense.

Thank you for the extra explanation. I still don't understand the comment's
relevancy to the actual question being asked by the original poster, but I
will explain, in case it's of interest, why that comment caused me some
confusion:

- The original poster outlined that he had created a class that represented
a customer.

- He told the list he was having difficulties with the concept of
abstracting a collection of customers

- He received some helpful suggestions from the list about how to approach
that task

- None of which would have meant he was 'trying to retrieve objects into
memory before they exist.' I don't know about anyone else, but what that
comment implied to me was that the original poster was attempting to
instantiate a class as an object before including the file that contained
the class definition.

I may well have misunderstood what you meant by your comment, but it still
stands out as not being relevant to the problem the original poster was
describing.

Much warmth,

Murray
---
"Lost in thought..."
http://www.planetthoughtful.org

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/20/2005 04:59 AM Murray @ PlanetThoughtful said the following:

Let's take for example a class called 'Customer' that (obviously)
manipulates customers in the database. Here is a very basic Customer
class. (Data validation and the like are left out for brevity.)

This is a basic object persistence problem.



(Unless I've already got some major design flaws I think we should be
good to go.)

 >
 > Where I get tripped up is when I realize I'll need to at some point
 > get more than one customer at a time and thus I want to add a method
 > called 'get_customers()'.


Yes, there is a problem. You are trying to retrieve objects into memory
before they exist. It makes more sense that you retrieve objects using a
factory class.

That is the approach of Metastorage. You may want to take a looka at
Metastorage before you reinvent the wheel.


Hi Manuel,

I very much understand your desire to promote your various projects, but the
original poster is asking a question that is basic to any programmer's
development in object-oriented coding.


I denote a certain bias on your part against the fact that I suggest 
projects that I have developed.


The matter is that I am suggesting projects that I use. The fact that I 
developed them is a mere coincidence. I do not always suggest projects 
that I developed as I am not such a wizard that I have the best 
solutions for everything. However, if I use and recommend certain 
solutions, mine or others is because I believe they are the best at 
least for my purposes.


What the original poster wants to know is what is the best solution 
retrieve a collection of objects. I recommended what I use and explained 
why I think it is the best approach for this purpose. He appreciated the 
reply and sent me a thank you message.


I do not understand why this could bother you or anybody else. If you 
have a better solution, nothing stops you to make your recommendations.





Once he understands how to solve class abstraction problems such as the one
he is asking about, he will be better equipped to deal with a wider range of
application development tasks.


Right, that is why I suggested something that I believe that solves his 
probleme better and even justified.




This is not to trivialize your Metastorage project (or, to be more accurate,
I know nothing about it, so it's not my place to trivialize it or
otherwise), but to point out that 'out-of-the-box' solutions to fundamental
coding development problems probably ultimately makes for a poorer
programmer. I could well be wrong, but it seems this is a case of "give a
man a fish" as opposed to "teach a man to fish".


I think you should have learned about Metastorage first before 
commenting. It is not really a out-of-the-box solution. It is a code 
generator tool that employs well known design patterns to generate code 
to customized to the developer needs.


It is not yet another template pasting tool. It uses the JE WIN 
approach: Just Exactly What I Need. That works by letting the developer 
tell the kind of functions he wants to use, rather than bundling a pile 
of code that you may never user.


It takes in account the design of your persistent object classes to 
generate optimized code for the task, rather than generic code for 
unnecessary generic needs.


Basically it generates the code that you would generate if you were an 
expert in object persistence methodology.


Given that, I am not even saying, "use this", but rather, take a look at 
the kind of code that it generates as a concrete example of what I tried 
to explain. The generated code even comes with comments so you do not 
have to wonder too much.


Whether the original poster will use Metastorage or just pick some 
ideas, that is another story.




Also, and separate from above, I don't understand the relevance of your
comment, "You are trying to retrieve objects into memory before they exist".
Unless I'm horribly mistaken [1], the original poster has developed a class
that abstracts a single customer, and is asking the list for suggestions in
how to best approach a need to be able to abstract collections of customers.
This is a normal application development issue, and for the life of me I
can't grasp how your comment relates.


I tried to explain in the part of the message that you did not quote, 
why using a factory class as entry point, which is my suggestion, it 
makes more sense.


In case this was not very clear, who gives existence to the objects 
should be a parent, not a brother like he was doing. He was using a 
Customer class object to give birth to other unrelated Customer objects.


When using a factory class you can execute a query to retrieve Customer 
objects and create them on demand. This means that you do not have to 
create one Customer object first. The query may return data for 0 or 
more Customer objects. A factory may create just exactly the number of 
Customer objects as needed.


Furthermore, a factory class may solve th

Re: [PHP] Re: Suggestions for class design

[Jochem Maas]

Michael Sims wrote:

Murray @ PlanetThoughtful wrote:


Once he understands how to solve class abstraction problems such as
the one he is asking about, he will be better equipped to deal with a
wider range of application development tasks.



I agree with this.



This is not to trivialize your Metastorage project (or, to be more
accurate, I know nothing about it, so it's not my place to trivialize
it or otherwise), but to point out that 'out-of-the-box' solutions to
fundamental coding development problems probably ultimately makes for
a poorer programmer. I could well be wrong, but it seems this is a
case of "give a man a fish" as opposed to "teach a man to fish".



I see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've


...



Sorry, I didn't mean to ramble on that long... :)


no need, very good piece of writing on the subject matter imho!





--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Re: Suggestions for class design

[Michael Sims]

Murray @ PlanetThoughtful wrote:
> Once he understands how to solve class abstraction problems such as
> the one he is asking about, he will be better equipped to deal with a
> wider range of application development tasks.

I agree with this.

> This is not to trivialize your Metastorage project (or, to be more
> accurate, I know nothing about it, so it's not my place to trivialize
> it or otherwise), but to point out that 'out-of-the-box' solutions to
> fundamental coding development problems probably ultimately makes for
> a poorer programmer. I could well be wrong, but it seems this is a
> case of "give a man a fish" as opposed to "teach a man to fish".

I see your point, but I'm not so sure I agree fully.  Manuel suggested
Metastorage (which makes sense, it's his project and he's most
familiar/comfortable with it), I suggested Propel because that is what I've
used.  I think we both suggested existing ORM's for the same reason...
namely that properly implementing a full featured ORM is an extremely
difficult thing to get right.  I don't know anything about Chris's skill as
a programmer, but he's bound to reinvent the wheel several times over, and
poorly to boot.  I believe that implementing an ORM is one of those things
that you cannot fully understand and appreciate until you've tried to do it
and failed.  IMHO it's only after you've built one that you realize what you
really need, and by then it needs to be rebuilt.  It's kind of like Fred
Brook's "plan to throw one away; you will, anyhow", or at least it was for
me.

I think the whole DAO/ORM approach is something that most programmers who
are fans of OO stumble into as part of their natural development.  I know
that in my earlier projects I had implemented some type of this pattern
without fully realizing that I had done so.  It's just natural to consider
at some point that you should represent entities in your database as objects
(if you're an OO proponent).  In one of my earlier PHP projects, I
implemented a very basic ORM that represented only single entities and
didn't quite handle multiple entities very well, or the relationships
between entities (this seems to be where Chris is currently).  Then for the
next project I added better support for multiple entities and relationships,
but it was a half implementation, because I didn't represent the related
entities as full objects (for example, if a Customer has a list of phone
numbers, I had the Customer object return them as an array of strings rather
than an array of PhoneNumber objects).  I also had no support for recursion
when saving or updated objects (for example, in Propel, you can create a new
Customer object, create 5 new PhoneNumber objects, attach them to the
customer, then call the save() method on the Customer and it will recurse
through all attached objects, saving each of them).  Another thing I had
done halfway was support for querying objects (without using SQL).
Basically I had created different types of criteria that could be used, but
my support for criteria wasn't general enough.  IOW, if I didn't forsee that
you would want a particular type of criteria, then you couldn't use it.
Propel gets this right by supporting any arbitrary criteria using their
Criteria object approach (and I'm sure Metastorage has similiar
functionality).  If you can represent it using SQL, you can represent it
using Propel's Criteria.

My point is, I had implemented my own home grown ORM about 3-4 times, and
while each one was much better than the one that preceded it, I still wasn't
quite all the way towards a 100% general implementation.  That's when I
found Propel.  It got so many things right that I hadn't figured out how to
solve, as well as implementing things that I hadn't even considered yet.

Now, you could argue that going through all those iterations and refactoring
my own ORM helped me to improve my skills as a programmer, and you would be
right.  That's where I agree with you, somewhat. :)  However, I was many
many iterations away from improving my ORM to the point where it would be as
useful as Propel (and that's assuming it would ever be that useful).  The
guys who developed it (and I'm sure the same goes for Manuel and
Metastorage) concentrated on making the best general purpose ORM they could
make.  IOW their whole goal was to build an ORM, while my goal each time was
to develop one for the purposes of finishing whatever real project I
happened to be working on.  That meant they were closer to the problem, had
more experience with it, and were willing to do more to solve it more fully
and generally than I was.

Originally I intended only to look at the code they had created and learn
from it, using their ideas in my project.  I started that way for a few
days, but I realized that there was so much they had accounted for that I
didn't even think of that it would be better to simply use their tool rather
than trying to reinvent it.

I think it's important to point out, however, that I ha

RE: [PHP] Re: Suggestions for class design

[Murray @ PlanetThoughtful]

> on 09/19/2005 02:33 PM Chris W. Parker said the following:
> > Let's take for example a class called 'Customer' that (obviously)
> > manipulates customers in the database. Here is a very basic Customer
> > class. (Data validation and the like are left out for brevity.)
> 
> This is a basic object persistence problem.
> 
> 
> > (Unless I've already got some major design flaws I think we should be
> > good to go.)
>  >
>  > Where I get tripped up is when I realize I'll need to at some point
>  > get more than one customer at a time and thus I want to add a method
>  > called 'get_customers()'.
> 
> 
> Yes, there is a problem. You are trying to retrieve objects into memory
> before they exist. It makes more sense that you retrieve objects using a
> factory class.
> 
> That is the approach of Metastorage. You may want to take a looka at
> Metastorage before you reinvent the wheel.

Hi Manuel,

I very much understand your desire to promote your various projects, but the
original poster is asking a question that is basic to any programmer's
development in object-oriented coding.

Once he understands how to solve class abstraction problems such as the one
he is asking about, he will be better equipped to deal with a wider range of
application development tasks.

This is not to trivialize your Metastorage project (or, to be more accurate,
I know nothing about it, so it's not my place to trivialize it or
otherwise), but to point out that 'out-of-the-box' solutions to fundamental
coding development problems probably ultimately makes for a poorer
programmer. I could well be wrong, but it seems this is a case of "give a
man a fish" as opposed to "teach a man to fish".

Also, and separate from above, I don't understand the relevance of your
comment, "You are trying to retrieve objects into memory before they exist".
Unless I'm horribly mistaken [1], the original poster has developed a class
that abstracts a single customer, and is asking the list for suggestions in
how to best approach a need to be able to abstract collections of customers.
This is a normal application development issue, and for the life of me I
can't grasp how your comment relates.

Much warmth,

Murray
---
"Lost in thought..."
http://www.planetthoughtful.org

[1] And it wouldn't be the first time!

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Suggestions for class design

[Manuel Lemos]

Hello,

on 09/19/2005 02:33 PM Chris W. Parker said the following:

Let's take for example a class called 'Customer' that (obviously)
manipulates customers in the database. Here is a very basic Customer
class. (Data validation and the like are left out for brevity.)


This is a basic object persistence problem.



(Unless I've already got some major design flaws I think we should be
good to go.)

>
> Where I get tripped up is when I realize I'll need to at some point
> get more than one customer at a time and thus I want to add a method
> called 'get_customers()'.


Yes, there is a problem. You are trying to retrieve objects into memory 
before they exist. It makes more sense that you retrieve objects using a 
factory class.


That is the approach of Metastorage. You may want to take a looka at 
Metastorage before you reinvent the wheel.


Metastorage is an persistent object class generator tool that lets you 
design your persistent object classes using a simple XML format that 
describes the classes, variables, validation rules, relationships and 
any functions that you may need to manipulate your objects.


Besides the persistent object classes, it also generates a factory class 
that takes care creating new objects from scratch or retrieve them from 
the database. The factory class makes sure that each object does not 
exist more than once in memory.


When you want to retrieve a collection of objects of the same class. You 
just add a function to the factory class to retrieve such objects, 
instead of calling the actual class of the objects your are retrieving.


You can also retrieve a collection of objects related to an object right 
from its class, for instance retrieving children objects of given parent 
object. In that case you would add a function to the parent object 
class, despite internally Metastorage implements that using calls to the 
factory class, which is itself a singleton.


Anyway, if you want to know more about Metastorage, you may find more 
information here:


http://www.meta-language.net/metastorage.html

There is a tutorial here:

http://www.meta-language.net/metastorage-tutorial.html

Some screenshots of the Web interface:

http://www.meta-language.net/screenshots.html




--

Regards,
Manuel Lemos

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

PHP Reviews - Reviews of PHP books and other products
http://www.phpclasses.org/reviews/

Metastorage - Data object relational mapping layer generator
http://www.meta-language.net/metastorage.html

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: suggestions for a good php+mysql isp?

[Seairth Jacobs]

www.webprosinc.net has several plans, starting as little as $4.95 (1 MySQL
database/1 domain/125 MB space/2GB transfer) to $49.95 (unlimited
databases/100 domains/1GB space/16GB transfer).  They are currently using
PHP 4.1.0 and seem to regularly updated their system (they use Plesk for
maintenance).  As with any host, there are some limitations to what you can
and cannot do.

Oh.  And very, very important:  they have *always* gotten back to me within
a few hours of any support call I have made.  This is a vast difference from
some prior hosts that I was lucky to hear from within 24 hours of a support
call.

Good luck in your search.  :)

---
Seairth Jacobs
[EMAIL PROTECTED]


"Or Not Db Db" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> I have searched the archives and the last time this was seriously
discussed
> was september of last year...unless I have a giant gaping hole in my
> archive!  :)  I was considering northwesthost.com and would like some
> opinions on them or anybody you are happy with  The list of isp's on
php.net
> doesn't mean much to me without some current comments about their
> performance.
> I need php and mysql support for my site - I'm moving the domain name and
> site from myhosting.com (they're ASP and perl2exe'd scripts only).  TIA!
>
> -Kirk
>
>



-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: suggestions

[Bopolissimus Platypus]

On Tue, 28 Aug 2001 19:41:51 -0400, [EMAIL PROTECTED]
(Glyndower) wrote:

>I have a medium sized db... with about 300 feilds and 15k rows.
>
>I need to create a search that will submit user input to seach the db from
>about 30 different feilds with some of those wildcards.
>
>i.e bedrooms, bathrooms, price, pool, city, etc
>
>Would using an array for the results page be the best way to approach this
>in PHP?

depends on how much and what post-processing you might
want to do to the data before printing it out.  

in the most common case, you don't need to do any. 
for example, you already did the sorting in the SQL query,
so the database already did the sorting.  and usually you
just need to display the data as it is received, no need for
special post-processing/massaging.  

then there's no need to use arrays at all, just read the rows 
from the resultset, and display the fields you want to 
display, e.g.,

$res=sql_exec($query);  
 /* $res is the result set, use for stepping over the rows 
  found */

$fldsToDisplay="fullname addr1 addr2 city state zip ";
   /* add other fields to display in the order you want them
   displayed */

$fldstoDisplay=explode(" ",$fldsToDisplay);
   /* i'm lazy.  array(...) works too but i like this more
   because the list is easier to type as a string (fewer
   quotes) and you can load the list of flds to display
   from somewhere else (e.g., a config file or something)
  */

print("\n");

/* for each row in the resultset, get associative array of
the row */
while($row=sql_fetch_array($res)) 
{
 print("\t\n");

  /* for each field to be displayed, get the next
  fieldname, and get the corresponding data
  from the associative array and print it in a
  table cell */
  for($ctr=0;$ctr$data\n");
  }

  print("\t\n");
}

print("\n");

PS.  replace sql_* functions with the relevant
functions for your database or with whatever DB
abstraction package you use.

PPS. sometimes you have to do post-processing.  
but most such data massaging involves only other 
fields in the same row or global data.  the above
common case system will need to be modified if
your data massaging involves data from other,
far-off rows in the same selection.  usually, though,
even that can be solved by sub-selects and
other SQL tricks.


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]