phpesp-devel

[phpesp-dev] updated version

[Franky V. L. <lie...@te...>]

Hi all,

in order to fix some bugs with 2.1.0, 2.1.1 has been released. No DB
changes have been made. From the changelog:

- Fixed some issues with save/resume surveys (I have to admit: I never
tested this before, so how old these bugs were, I have no idea)

- Fresh installations didn't have initial data due to an xml schema
mismatch, easy to fix but inconvenient. For those curious on how I
fixed this: just changed "0.2" to "0.3" in scripts/db/data.xml. That'll 
teach me to update the adodb-schema class and not updating all
versions ...

- Changing a user or designer caused his password to become empty, not
very wise (who knows how long this has been in ...). This was due to
using _addslashes on all entered data and only checking emptyness
afterwards, but when a variable contains just quotes, it is no longer
empty ... this was probably already in 2.0.2 as well.

To update: just replace the current phpESP dir with the new one and log
in to the admin section.

Enjoy the update!

Franky

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Hi Franky,

Quoting Franky Van Liedekerke <lie...@te...>:

> - Fixed some issues with save/resume surveys (I have to admit: I never
> tested this before, so how old these bugs were, I have no idea)

Can you debrief on the issue(s) here?

> - Changing a user or designer caused his password to become empty, not
> very wise (who knows how long this has been in ...). This was due to
> using _addslashes on all entered data and only checking emptyness
> afterwards, but when a variable contains just quotes, it is no longer
> empty ... this was probably already in 2.0.2 as well.

I have not noticed this in 2.0.2 -- can you elaborate?

regards,
bishop


-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Franky V. L. <lie...@te...>]

On Sat, 19 Apr 2008 11:59:28 -0400
Bishop Bettini <ph...@id...> wrote:

> Hi Franky,
> 
> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > - Fixed some issues with save/resume surveys (I have to admit: I
> > never tested this before, so how old these bugs were, I have no
> > idea)
> 
> Can you debrief on the issue(s) here?

well, it's like I said: I never tested save/resume before, so it might
be that the bugs were new due to session variables for the response-id
or not ... (the bug was that resuming didn't work, you always had a
new response session). Anyway, I got it fixed :)
Come to think of it, it might even be that there's still an issue there
with the url presented in the page when you save the survey. iirc the
survey id wasn't always passed to the url ... I still need to double
check that as well. Not too serious there, but still ... that slipped
my mind ...
 
> > - Changing a user or designer caused his password to become empty,
> > not very wise (who knows how long this has been in ...). This was
> > due to using _addslashes on all entered data and only checking
> > emptyness afterwards, but when a variable contains just quotes, it
> > is no longer empty ... this was probably already in 2.0.2 as well.
> 
> I have not noticed this in 2.0.2 -- can you elaborate?

I thought this to be self-explanatory: due to the _addslashes on eg.
the password, the password variable was never empty, even if you didn't
fill it in (because you were changing an existing user). And so, eg. in
admrespondent.inc, upon submit (old code):

$u_password = _addslashes($_POST['password']);

==> this would cause $u_password to be "''" (meaning a string with two
single quotes) when you left the field empty in the html form.

Further down the test is made whether or not the password was empty:
      if (!empty($u_password))
                $u_password = "password=".db_crypt($u_password).",";
and this would then cause a change of the password to "''" in the db
when the UPDATE statement just below that line was executed (it happened
to me)

Franky

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Hi Franky,

Quoting Franky Van Liedekerke <lie...@te...>:

>> Can you debrief on the issue(s) here?
>
> well, it's like I said: I never tested save/resume before, so it might
> be that the bugs were new due to session variables for the response-id
> or not ... (the bug was that resuming didn't work, you always had a
> new response session). Anyway, I got it fixed :)

I believe the bug's there (:>), but it doesn't sound like it was in  
2.0.2. I say that because I'm very actively using 2.0.2, and no user  
has reported a problem with resume, nor did our extensive testing  
reveal an issue.  I'll do a diff in the trees to see what changed, and  
if 2.0.2 is impacted.


> I thought this to be self-explanatory: due to the _addslashes on eg.
> the password, the password variable was never empty, even if you didn't
> fill it in (because you were changing an existing user). And so, eg. in
> admrespondent.inc, upon submit (old code):
>
> $u_password = _addslashes($_POST['password']);
>
> ==> this would cause $u_password to be "''" (meaning a string with two
> single quotes) when you left the field empty in the html form.
>
> Further down the test is made whether or not the password was empty:
>       if (!empty($u_password))
>                 $u_password = "password=".db_crypt($u_password).",";
> and this would then cause a change of the password to "''" in the db
> when the UPDATE statement just below that line was executed (it happened
> to me)

It was explanatory, but I hadn't heard a problem report from our admin  
users -- undoubtedly because they only change the password when they  
visit those affected screens -- they have no business case to change  
any other data, as that's bulk loaded from a registrar database.

I'll merge the change in -- thanks for noticing this.

Now, a bigger question: any votes on adding a unit test framework to  
phpESP so that this bug can be installed as a test case?  (We use  
phpunit extensively on our other products, and I recommend it.)  One  
problem is that the phpESP code is a bit resilient to unit testing:  
the UI, business logic, and DB code are all wrapped into one.  I  
suppose it could be done by munging POST, including the file, and  
checking the results both in the DB and a regex/DOM parse of the  
output buffer.  Thoughts?

bishop

-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

Unit testing sounds like a great thing to add.  My concern is the work
to add and maintain would be significant given phpESP legacy code base.
Perhaps more work than starting over using an off the shelf framework
that supports proper unit testing.

Thoughts?

On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote:
...snip...
> Now, a bigger question: any votes on adding a unit test framework to  
> phpESP so that this bug can be installed as a test case?  (We use  
> phpunit extensively on our other products, and I recommend it.)  One  
> problem is that the phpESP code is a bit resilient to unit testing:  
> the UI, business logic, and DB code are all wrapped into one.  I  
> suppose it could be done by munging POST, including the file, and  
> checking the results both in the DB and a regex/DOM parse of the  
> output buffer.  Thoughts?
> 
> bishop
> 
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Matthew raises a very good point.  In one of our products, we had a  
similar hurdle: lots of very old code (early PHP 4 based) that was  
rapidly produced in a not-so-modular fashion.  Wholesale rewriting,  
while desired, was not feasible given the clients using the code and  
the sheer number of lines to change.

To incorporate standardized testing, we first defined exactly what we  
wanted tested (ie, specific areas that were prone to changes or known  
to be problematic) and how we wanted to test (ie, unit, stress,  
penetration, and coverage testing).

Then, we settled on a robust framework -- phpunit2 -- that would grow  
with us in that, and other, products.

Finally, we made two rules:
1. All new code SHOULD conform to our testing policy
2. All bugs MUST get a test case to expose them and to prove they have  
been fixed

(Interpret MUST and SHOULD according to RFC2119)

That process allowed us to slowly migrate a consistent testing  
strategy into the old code.  It has been more cost effective than a  
whole sale restart.

Here's how we usually set up tests structure:

test/
   smoke/
   regression/
    stress/
    security/

Smoke tests are those that absolutely must pass each build.  phpESP  
doesn't really have a "build" process (IMO, it should), but the type  
of tests in this category are "config file exists, is readable, and  
parseable by PHP", "database can be accessed and has good schema",  
"web directory exists and is readable by the web server", etc.

Regression tests are every thing else: bug fix tests, new code tests, etc.

Stress tests are a particular breed of regression tests, in that  
they're designed to wallop the web UI or DB with a large number of  
requests to exercise the code under significant duress and make sure  
it meets its performance/responsiveness requirements.

Security tests, also a breed of regression, specifically try to pry  
open the application: SQL injection attacks, man in the middle  
attacks, brute-force or dictionary attacks, etc.

Then as new scenarios come up, we drop unit tests into the appropriate  
spot.  We exercise the software with our build tool phing, such as:  
"phing build", "phing regression", "phing stress", and "phing penetrate"

We definitely didn't get there overnight.  It's been a steady task of  
adding in tests.  Over time, it becomes a natural reaction of the  
developer and a significant suite is developed.  We just had to draw a  
line in the sand and exclaim "Today, we incorporate tests."


So, leaders of phpESP: what is the testing policy?  Do we incorporate  
slowly as legacy evolves, or start fresh?  I'm in the incorporate  
slowly camp, but maybe that's because I never worked for Netscape:
http://www.joelonsoftware.com/articles/fog0000000069.html


bishop


Quoting Matthew Gregg <mat...@gm...>:

> Unit testing sounds like a great thing to add.  My concern is the work
> to add and maintain would be significant given phpESP legacy code base.
> Perhaps more work than starting over using an off the shelf framework
> that supports proper unit testing.
>
> Thoughts?
>
> On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote:
> ...snip...
>> Now, a bigger question: any votes on adding a unit test framework to
>> phpESP so that this bug can be installed as a test case?  (We use
>> phpunit extensively on our other products, and I recommend it.)  One
>> problem is that the phpESP code is a bit resilient to unit testing:
>> the UI, business logic, and DB code are all wrapped into one.  I
>> suppose it could be done by munging POST, including the file, and
>> checking the results both in the DB and a regex/DOM parse of the
>> output buffer.  Thoughts?


-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

So many things need to be redone in the current code base:
* Permission system
* User management
* The admin UI <-biggie
* Survey results export
* Survey question storage export/interchange
* etc...
and it's already in a pretty ugly state, that I have had "flip the
switch and start over" in my head for a long time.  I have worked
privately on a few proof of concepts for this, but never pushed to have
something usable.  Current code could be put into maintenance mode and
new dev only on this "branch".

On Sat, 2008-04-19 at 18:02 -0400, Bishop Bettini wrote:
> Matthew raises a very good point.  In one of our products, we had a  
> similar hurdle: lots of very old code (early PHP 4 based) that was  
> rapidly produced in a not-so-modular fashion.  Wholesale rewriting,  
> while desired, was not feasible given the clients using the code and  
> the sheer number of lines to change.
> 
> To incorporate standardized testing, we first defined exactly what we  
> wanted tested (ie, specific areas that were prone to changes or known  
> to be problematic) and how we wanted to test (ie, unit, stress,  
> penetration, and coverage testing).
> 
> Then, we settled on a robust framework -- phpunit2 -- that would grow  
> with us in that, and other, products.
> 
> Finally, we made two rules:
> 1. All new code SHOULD conform to our testing policy
> 2. All bugs MUST get a test case to expose them and to prove they have  
> been fixed
> 
> (Interpret MUST and SHOULD according to RFC2119)
> 
> That process allowed us to slowly migrate a consistent testing  
> strategy into the old code.  It has been more cost effective than a  
> whole sale restart.
> 
> Here's how we usually set up tests structure:
> 
> test/
>    smoke/
>    regression/
>     stress/
>     security/
> 
> Smoke tests are those that absolutely must pass each build.  phpESP  
> doesn't really have a "build" process (IMO, it should), but the type  
> of tests in this category are "config file exists, is readable, and  
> parseable by PHP", "database can be accessed and has good schema",  
> "web directory exists and is readable by the web server", etc.
> 
> Regression tests are every thing else: bug fix tests, new code tests, etc.
> 
> Stress tests are a particular breed of regression tests, in that  
> they're designed to wallop the web UI or DB with a large number of  
> requests to exercise the code under significant duress and make sure  
> it meets its performance/responsiveness requirements.
> 
> Security tests, also a breed of regression, specifically try to pry  
> open the application: SQL injection attacks, man in the middle  
> attacks, brute-force or dictionary attacks, etc.
> 
> Then as new scenarios come up, we drop unit tests into the appropriate  
> spot.  We exercise the software with our build tool phing, such as:  
> "phing build", "phing regression", "phing stress", and "phing penetrate"
> 
> We definitely didn't get there overnight.  It's been a steady task of  
> adding in tests.  Over time, it becomes a natural reaction of the  
> developer and a significant suite is developed.  We just had to draw a  
> line in the sand and exclaim "Today, we incorporate tests."
> 
> 
> So, leaders of phpESP: what is the testing policy?  Do we incorporate  
> slowly as legacy evolves, or start fresh?  I'm in the incorporate  
> slowly camp, but maybe that's because I never worked for Netscape:
> http://www.joelonsoftware.com/articles/fog0000000069.html
> 
> 
> bishop
> 
> 
> Quoting Matthew Gregg <mat...@gm...>:
> 
> > Unit testing sounds like a great thing to add.  My concern is the work
> > to add and maintain would be significant given phpESP legacy code base.
> > Perhaps more work than starting over using an off the shelf framework
> > that supports proper unit testing.
> >
> > Thoughts?
> >
> > On Sat, 2008-04-19 at 12:52 -0400, Bishop Bettini wrote:
> > ...snip...
> >> Now, a bigger question: any votes on adding a unit test framework to
> >> phpESP so that this bug can be installed as a test case?  (We use
> >> phpunit extensively on our other products, and I recommend it.)  One
> >> problem is that the phpESP code is a bit resilient to unit testing:
> >> the UI, business logic, and DB code are all wrapped into one.  I
> >> suppose it could be done by munging POST, including the file, and
> >> checking the results both in the DB and a regex/DOM parse of the
> >> output buffer.  Thoughts?
> 
> 
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] updated version

[Franky V. L. <lie...@te...>]

On Sat, 19 Apr 2008 20:21:28 -0400
Matthew Gregg <mat...@gm...> wrote:

> So many things need to be redone in the current code base:
> * Permission system
> * User management
> * The admin UI <-biggie
> * Survey results export
> * Survey question storage export/interchange
> * etc...
> and it's already in a pretty ugly state, that I have had "flip the
> switch and start over" in my head for a long time.  I have worked
> privately on a few proof of concepts for this, but never pushed to
> have something usable.  Current code could be put into maintenance
> mode and new dev only on this "branch".

well, I agree here: the current code is ugly and I sometimes thought
about beginning from scratch again also. So I'm in favour of starting
over also.

Franky

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

I have added CodeIgnitor and Zend Framework to the v3OpenQuestions page.

How should we go about evaluating these frameworks?  Is there an  
objective method, maybe develop a very small application and  
compare/contrast how long it takes/number of lines used/speed/etc?

Maybe the application could be a hello world: create a table, dump the  
string into the table (install relevant), write unit test cases (test  
design), write code to read the table (user facing relevant), write a  
form to change the string, commit the changes (admin relevant),  
exercise test cases (regression).

Lot of work, especially if we each do all....

bishop

Quoting Matthew Gregg <mat...@gm...>:

> I also agree that Horde wouldn't be a very good fit, but I would like to
> evaluate at least CakePHP, Symfony, CodeIgniter and perhaps Zend
> Framework.
>
> On Tue, 2008-04-22 at 09:54 +0200, Franky Van Liedekerke wrote:
>>
>> On 4/21/08, Bishop Bettini <ph...@id...> wrote:
>>         Yes, Horde (www.horde.org) comes to mind (except the unit test
>>         part...).  They already have a "Polls" application (scry), so
>>         Horde
>>         might not be a good framework to use.  Did you have any
>>         particular
>>         frameworks in mind?
>>
>>         bishop
>>
>>
>> I've already seen horde, and it might be personal, but I don't like it
>> very much ...
>> Let's stick, like mentioned, to known technology: adodb (or pear, but
>> then we lose the xml db updating again ...), some templating engine
>> (smarty maybe?), etc ...
>>
>> Franky
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________ phpESP-devel   
>> mailing list php...@li...   
>> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> --
> Matthew Gregg <mat...@gm...>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Franky V. L. <lie...@te...>]

I heard good things about the zend framework, but is that open source?
Anyway, I will play around a bit with cakephp and symfony, I like the names
:-)



Franky

On 4/22/08, Bishop Bettini <ph...@id...> wrote:
>
> I have added CodeIgnitor and Zend Framework to the v3OpenQuestions page.
>
> How should we go about evaluating these frameworks?  Is there an
> objective method, maybe develop a very small application and
> compare/contrast how long it takes/number of lines used/speed/etc?
>
> Maybe the application could be a hello world: create a table, dump the
> string into the table (install relevant), write unit test cases (test
> design), write code to read the table (user facing relevant), write a
> form to change the string, commit the changes (admin relevant),
> exercise test cases (regression).
>
> Lot of work, especially if we each do all....
>
> bishop
>
> Quoting Matthew Gregg <mat...@gm...>:
>
> > I also agree that Horde wouldn't be a very good fit, but I would like to
> > evaluate at least CakePHP, Symfony, CodeIgniter and perhaps Zend
> > Framework.
> >
> > On Tue, 2008-04-22 at 09:54 +0200, Franky Van Liedekerke wrote:
> >>
> >> On 4/21/08, Bishop Bettini <ph...@id...> wrote:
> >>         Yes, Horde (www.horde.org) comes to mind (except the unit test
> >>         part...).  They already have a "Polls" application (scry), so
> >>         Horde
> >>         might not be a good framework to use.  Did you have any
> >>         particular
> >>         frameworks in mind?
> >>
> >>         bishop
> >>
> >>
> >> I've already seen horde, and it might be personal, but I don't like it
> >> very much ...
> >> Let's stick, like mentioned, to known technology: adodb (or pear, but
> >> then we lose the xml db updating again ...), some templating engine
> >> (smarty maybe?), etc ...
> >>
> >> Franky
> >>
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> Don't miss this year's exciting event. There's still time to save $100.
> >> Use priority code J8TL2D2.
> >>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> _______________________________________________ phpESP-devel
> >> mailing list php...@li...
> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> > --
> > Matthew Gregg <mat...@gm...>
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> >
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
>
>
>
> --
> Bishop Bettini
> ideacode, Inc.
> (main) +1 919 341 5170 / (fax) +1 919 521 4100
>
> Visit us on the web at:
> ideacode.com          Professional software research and development
> reviewmysoftware.com  Improve sales! Review your software before you
> release
> bytejar.com           Solutions to those annoying development problems
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
>
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>
>

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Yes, ZF is BSD license.
http://framework.zend.com/license

Gut reaction: I would feel more comfortable using a framework that's  
closely aligned with the company who writes the language.  Seems like  
there would be a lot of synergy there.

Of course, I have no objective evaluation... which is what is really  
needed.  And of course, I'd feel more comfortable with a documented  
list of goals with the rewrite so I could see if the framework moved  
us toward those goals.

bishop

Quoting Franky Van Liedekerke <lie...@te...>:

> I heard good things about the zend framework, but is that open source?
> Anyway, I will play around a bit with cakephp and symfony, I like the names
> :-)
>
>
>
> Franky
>
> On 4/22/08, Bishop Bettini <ph...@id...> wrote:
>>
>> I have added CodeIgnitor and Zend Framework to the v3OpenQuestions page.
>>
>> How should we go about evaluating these frameworks?  Is there an
>> objective method, maybe develop a very small application and
>> compare/contrast how long it takes/number of lines used/speed/etc?
>>
>> Maybe the application could be a hello world: create a table, dump the
>> string into the table (install relevant), write unit test cases (test
>> design), write code to read the table (user facing relevant), write a
>> form to change the string, commit the changes (admin relevant),
>> exercise test cases (regression).
>>
>> Lot of work, especially if we each do all....
>>
>> bishop
>>
>> Quoting Matthew Gregg <mat...@gm...>:
>>
>> > I also agree that Horde wouldn't be a very good fit, but I would like to
>> > evaluate at least CakePHP, Symfony, CodeIgniter and perhaps Zend
>> > Framework.
>> >
>> > On Tue, 2008-04-22 at 09:54 +0200, Franky Van Liedekerke wrote:
>> >>
>> >> On 4/21/08, Bishop Bettini <ph...@id...> wrote:
>> >>         Yes, Horde (www.horde.org) comes to mind (except the unit test
>> >>         part...).  They already have a "Polls" application (scry), so
>> >>         Horde
>> >>         might not be a good framework to use.  Did you have any
>> >>         particular
>> >>         frameworks in mind?
>> >>
>> >>         bishop
>> >>
>> >>
>> >> I've already seen horde, and it might be personal, but I don't like it
>> >> very much ...
>> >> Let's stick, like mentioned, to known technology: adodb (or pear, but
>> >> then we lose the xml db updating again ...), some templating engine
>> >> (smarty maybe?), etc ...
>> >>
>> >> Franky
>> >>
>> >>
>> >>
>> -------------------------------------------------------------------------
>> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> >> Don't miss this year's exciting event. There's still time to save $100.
>> >> Use priority code J8TL2D2.
>> >>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> >> _______________________________________________ phpESP-devel
>> >> mailing list php...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>> > --
>> > Matthew Gregg <mat...@gm...>
>> >
>> >
>> > -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save $100.
>> > Use priority code J8TL2D2.
>> >
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> > _______________________________________________
>> > phpESP-devel mailing list
>> > php...@li...
>> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>> >
>>
>>
>>
>> --
>> Bishop Bettini
>> ideacode, Inc.
>> (main) +1 919 341 5170 / (fax) +1 919 521 4100
>>
>> Visit us on the web at:
>> ideacode.com          Professional software research and development
>> reviewmysoftware.com  Improve sales! Review your software before you
>> release
>> bytejar.com           Solutions to those annoying development problems
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> Don't miss this year's exciting event. There's still time to save $100.
>> Use priority code J8TL2D2.
>>
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> _______________________________________________
>> phpESP-devel mailing list
>> php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>>
>>
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

It also depends on how much traction the particular framework has in the
community.  If no one uses Zend then support/community will be small.
Not that Zend isn't the way to go.  Just need to eval them.

On Tue, 2008-04-22 at 10:50 -0400, Bishop Bettini wrote:
> Yes, ZF is BSD license.
> http://framework.zend.com/license
> 
> Gut reaction: I would feel more comfortable using a framework that's  
> closely aligned with the company who writes the language.  Seems like  
> there would be a lot of synergy there.

> Of course, I have no objective evaluation... which is what is really  
> needed.  And of course, I'd feel more comfortable with a documented  
> list of goals with the rewrite so I could see if the framework moved  
> us toward those goals.
> 
> bishop
> 
> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > I heard good things about the zend framework, but is that open source?
> > Anyway, I will play around a bit with cakephp and symfony, I like the names
> > :-)
> >
> >
> >
> > Franky
> >
> > On 4/22/08, Bishop Bettini <ph...@id...> wrote:
> >>
> >> I have added CodeIgnitor and Zend Framework to the v3OpenQuestions page.
> >>
> >> How should we go about evaluating these frameworks?  Is there an
> >> objective method, maybe develop a very small application and
> >> compare/contrast how long it takes/number of lines used/speed/etc?
> >>
> >> Maybe the application could be a hello world: create a table, dump the
> >> string into the table (install relevant), write unit test cases (test
> >> design), write code to read the table (user facing relevant), write a
> >> form to change the string, commit the changes (admin relevant),
> >> exercise test cases (regression).
> >>
> >> Lot of work, especially if we each do all....
> >>
> >> bishop
> >>
> >> Quoting Matthew Gregg <mat...@gm...>:
> >>
> >> > I also agree that Horde wouldn't be a very good fit, but I would like to
> >> > evaluate at least CakePHP, Symfony, CodeIgniter and perhaps Zend
> >> > Framework.
> >> >
> >> > On Tue, 2008-04-22 at 09:54 +0200, Franky Van Liedekerke wrote:
> >> >>
> >> >> On 4/21/08, Bishop Bettini <ph...@id...> wrote:
> >> >>         Yes, Horde (www.horde.org) comes to mind (except the unit test
> >> >>         part...).  They already have a "Polls" application (scry), so
> >> >>         Horde
> >> >>         might not be a good framework to use.  Did you have any
> >> >>         particular
> >> >>         frameworks in mind?
> >> >>
> >> >>         bishop
> >> >>
> >> >>
> >> >> I've already seen horde, and it might be personal, but I don't like it
> >> >> very much ...
> >> >> Let's stick, like mentioned, to known technology: adodb (or pear, but
> >> >> then we lose the xml db updating again ...), some templating engine
> >> >> (smarty maybe?), etc ...
> >> >>
> >> >> Franky
> >> >>
> >> >>
> >> >>
> >> -------------------------------------------------------------------------
> >> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> >> Don't miss this year's exciting event. There's still time to save $100.
> >> >> Use priority code J8TL2D2.
> >> >>
> >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> >> _______________________________________________ phpESP-devel
> >> >> mailing list php...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >> > --
> >> > Matthew Gregg <mat...@gm...>
> >> >
> >> >
> >> > -------------------------------------------------------------------------
> >> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> > Don't miss this year's exciting event. There's still time to save $100.
> >> > Use priority code J8TL2D2.
> >> >
> >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> > _______________________________________________
> >> > phpESP-devel mailing list
> >> > php...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >> >
> >>
> >>
> >>
> >> --
> >> Bishop Bettini
> >> ideacode, Inc.
> >> (main) +1 919 341 5170 / (fax) +1 919 521 4100
> >>
> >> Visit us on the web at:
> >> ideacode.com          Professional software research and development
> >> reviewmysoftware.com  Improve sales! Review your software before you
> >> release
> >> bytejar.com           Solutions to those annoying development problems
> >>
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> Don't miss this year's exciting event. There's still time to save $100.
> >> Use priority code J8TL2D2.
> >>
> >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> _______________________________________________
> >> phpESP-devel mailing list
> >> php...@li...
> >> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >>
> >>
> >
> 
> 
> 
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

While I agree the code is horrendous in many places, I caution against  
a wholesale rewrite, for the reasons Joel gives here:
http://www.joelonsoftware.com/articles/fog0000000069.html

But, if that is the tack taken for v3, we should define the  
requirements, write the functional specification, identify re-use and  
re-factor candidates, decide on the platform tools, draw the road map,  
and declare milestones.  In other words, do it right and try not to  
make the same mistakes.

On that note, is there a wiki or some other collaboration space where  
this information (requirements, specifications, etc) can be maintained?

bishop

Quoting Franky Van Liedekerke <lie...@te...>:

> On Sat, 19 Apr 2008 20:21:28 -0400
> Matthew Gregg <mat...@gm...> wrote:
>
>> So many things need to be redone in the current code base:
>> * Permission system
>> * User management
>> * The admin UI <-biggie
>> * Survey results export
>> * Survey question storage export/interchange
>> * etc...
>> and it's already in a pretty ugly state, that I have had "flip the
>> switch and start over" in my head for a long time.  I have worked
>> privately on a few proof of concepts for this, but never pushed to
>> have something usable.  Current code could be put into maintenance
>> mode and new dev only on this "branch".
>
> well, I agree here: the current code is ugly and I sometimes thought
> about beginning from scratch again also. So I'm in favour of starting
> over also.
>
> Franky
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

Joel may be correct with projects the size of mozilla, but I'm not so
sure with something as small as ESP.  Especially since I would hope a
great deal of what is currently custom in the code-base would be
provided out of the box in most modern frameworks.


As for as a space for collaboration.  I can enable the wiki on the
Sourceforge site or drop an instance of Trac on our hosting service.

IRC is available here: irc://irc.freenode.net/phpesp/
Or if you would rather have a Jabber/XMPP conference room I can have
that available in a few seconds.


On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote:
> While I agree the code is horrendous in many places, I caution against  
> a wholesale rewrite, for the reasons Joel gives here:
> http://www.joelonsoftware.com/articles/fog0000000069.html
> 
> But, if that is the tack taken for v3, we should define the  
> requirements, write the functional specification, identify re-use and  
> re-factor candidates, decide on the platform tools, draw the road map,  
> and declare milestones.  In other words, do it right and try not to  
> make the same mistakes.
> 
> On that note, is there a wiki or some other collaboration space where  
> this information (requirements, specifications, etc) can be maintained?
> 
> bishop
> 
> Quoting Franky Van Liedekerke <lie...@te...>:
> 
> > On Sat, 19 Apr 2008 20:21:28 -0400
> > Matthew Gregg <mat...@gm...> wrote:
> >
> >> So many things need to be redone in the current code base:
> >> * Permission system
> >> * User management
> >> * The admin UI <-biggie
> >> * Survey results export
> >> * Survey question storage export/interchange
> >> * etc...
> >> and it's already in a pretty ugly state, that I have had "flip the
> >> switch and start over" in my head for a long time.  I have worked
> >> privately on a few proof of concepts for this, but never pushed to
> >> have something usable.  Current code could be put into maintenance
> >> mode and new dev only on this "branch".
> >
> > well, I agree here: the current code is ugly and I sometimes thought
> > about beginning from scratch again also. So I'm in favour of starting
> > over also.
> >
> > Franky
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 
-- 
Matthew Gregg <mat...@gm...>

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Quoting Matthew Gregg <mat...@gm...>:

> Joel may be correct with projects the size of mozilla, but I'm not so
> sure with something as small as ESP.  Especially since I would hope a
> great deal of what is currently custom in the code-base would be
> provided out of the box in most modern frameworks.

To an outsider (me), phpESP looks pretty big, though that is probably  
a mirage: I have had no problem digging into it, nor have I  
encountered any feelings of "how deep does this rabbit hole go?"  I  
also don't know how many people/organizations use phpESP, so I'm not  
sure what kind of upgrade resistance the community would offer.

When you say "framework," what do you mean?  When I hear "a great deal  
of what is currently custom ... would be provided .. in [a] modern  
framework", that makes me think that phpESP wouldn't add much value  
over the framework.


> As for as a space for collaboration.  I can enable the wiki on the
> Sourceforge site or drop an instance of Trac on our hosting service.
>
> IRC is available here: irc://irc.freenode.net/phpesp/
> Or if you would rather have a Jabber/XMPP conference room I can have
> that available in a few seconds.

I would think we'd want a wiki (or static repository of some kind), to  
keep the documentation around for a longer period than afforded by  
communication groups.

bishop


> On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote:
>> While I agree the code is horrendous in many places, I caution against
>> a wholesale rewrite, for the reasons Joel gives here:
>> http://www.joelonsoftware.com/articles/fog0000000069.html
>>
>> But, if that is the tack taken for v3, we should define the
>> requirements, write the functional specification, identify re-use and
>> re-factor candidates, decide on the platform tools, draw the road map,
>> and declare milestones.  In other words, do it right and try not to
>> make the same mistakes.
>>
>> On that note, is there a wiki or some other collaboration space where
>> this information (requirements, specifications, etc) can be maintained?
>>
>> bishop
>>
>> Quoting Franky Van Liedekerke <lie...@te...>:
>>
>> > On Sat, 19 Apr 2008 20:21:28 -0400
>> > Matthew Gregg <mat...@gm...> wrote:
>> >
>> >> So many things need to be redone in the current code base:
>> >> * Permission system
>> >> * User management
>> >> * The admin UI <-biggie
>> >> * Survey results export
>> >> * Survey question storage export/interchange
>> >> * etc...
>> >> and it's already in a pretty ugly state, that I have had "flip the
>> >> switch and start over" in my head for a long time.  I have worked
>> >> privately on a few proof of concepts for this, but never pushed to
>> >> have something usable.  Current code could be put into maintenance
>> >> mode and new dev only on this "branch".
>> >
>> > well, I agree here: the current code is ugly and I sometimes thought
>> > about beginning from scratch again also. So I'm in favour of starting
>> > over also.
>> >
>> > Franky
>> >
>> > -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save $100.
>> > Use priority code J8TL2D2.
>> >   
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> > _______________________________________________
>> > phpESP-devel mailing list
>> > php...@li...
>> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>> >
>>
>>
>>
> --
> Matthew Gregg <mat...@gm...>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

Most frameworks provide some sort of:
Database abstraction
Data validation
UI abstraction(proper templating, etc..)
Authentication(or at least support the idea of a single entry point)
Unit Tests

On Mon, 2008-04-21 at 11:01 -0400, Bishop Bettini wrote:
> Quoting Matthew Gregg <mat...@gm...>:
> 
> > Joel may be correct with projects the size of mozilla, but I'm not so
> > sure with something as small as ESP.  Especially since I would hope a
> > great deal of what is currently custom in the code-base would be
> > provided out of the box in most modern frameworks.
> 
> To an outsider (me), phpESP looks pretty big, though that is probably  
> a mirage: I have had no problem digging into it, nor have I  
> encountered any feelings of "how deep does this rabbit hole go?"  I  
> also don't know how many people/organizations use phpESP, so I'm not  
> sure what kind of upgrade resistance the community would offer.
> 
> When you say "framework," what do you mean?  When I hear "a great deal  
> of what is currently custom ... would be provided .. in [a] modern  
> framework", that makes me think that phpESP wouldn't add much value  
> over the framework.
> 
> 
> > As for as a space for collaboration.  I can enable the wiki on the
> > Sourceforge site or drop an instance of Trac on our hosting service.
> >
> > IRC is available here: irc://irc.freenode.net/phpesp/
> > Or if you would rather have a Jabber/XMPP conference room I can have
> > that available in a few seconds.
> 
> I would think we'd want a wiki (or static repository of some kind), to  
> keep the documentation around for a longer period than afforded by  
> communication groups.
> 
> bishop
> 
> 
> > On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote:
> >> While I agree the code is horrendous in many places, I caution against
> >> a wholesale rewrite, for the reasons Joel gives here:
> >> http://www.joelonsoftware.com/articles/fog0000000069.html
> >>
> >> But, if that is the tack taken for v3, we should define the
> >> requirements, write the functional specification, identify re-use and
> >> re-factor candidates, decide on the platform tools, draw the road map,
> >> and declare milestones.  In other words, do it right and try not to
> >> make the same mistakes.
> >>
> >> On that note, is there a wiki or some other collaboration space where
> >> this information (requirements, specifications, etc) can be maintained?
> >>
> >> bishop
> >>
> >> Quoting Franky Van Liedekerke <lie...@te...>:
> >>
> >> > On Sat, 19 Apr 2008 20:21:28 -0400
> >> > Matthew Gregg <mat...@gm...> wrote:
> >> >
> >> >> So many things need to be redone in the current code base:
> >> >> * Permission system
> >> >> * User management
> >> >> * The admin UI <-biggie
> >> >> * Survey results export
> >> >> * Survey question storage export/interchange
> >> >> * etc...
> >> >> and it's already in a pretty ugly state, that I have had "flip the
> >> >> switch and start over" in my head for a long time.  I have worked
> >> >> privately on a few proof of concepts for this, but never pushed to
> >> >> have something usable.  Current code could be put into maintenance
> >> >> mode and new dev only on this "branch".
> >> >
> >> > well, I agree here: the current code is ugly and I sometimes thought
> >> > about beginning from scratch again also. So I'm in favour of starting
> >> > over also.
> >> >
> >> > Franky
> >> >
> >> > -------------------------------------------------------------------------
> >> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> >> > Don't miss this year's exciting event. There's still time to save $100.
> >> > Use priority code J8TL2D2.
> >> >   
> >> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> >> > _______________________________________________
> >> > phpESP-devel mailing list
> >> > php...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >> >
> >>
> >>
> >>
> > --
> > Matthew Gregg <mat...@gm...>
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> > Don't miss this year's exciting event. There's still time to save $100.
> > Use priority code J8TL2D2.
> > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> > _______________________________________________
> > phpESP-devel mailing list
> > php...@li...
> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
> >
> 
> 
> 

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Yes, Horde (www.horde.org) comes to mind (except the unit test  
part...).  They already have a "Polls" application (scry), so Horde  
might not be a good framework to use.  Did you have any particular  
frameworks in mind?

bishop

Quoting Matthew Gregg <mat...@gm...>:

> Most frameworks provide some sort of:
> Database abstraction
> Data validation
> UI abstraction(proper templating, etc..)
> Authentication(or at least support the idea of a single entry point)
> Unit Tests
>
> On Mon, 2008-04-21 at 11:01 -0400, Bishop Bettini wrote:
>> Quoting Matthew Gregg <mat...@gm...>:
>>
>> > Joel may be correct with projects the size of mozilla, but I'm not so
>> > sure with something as small as ESP.  Especially since I would hope a
>> > great deal of what is currently custom in the code-base would be
>> > provided out of the box in most modern frameworks.
>>
>> To an outsider (me), phpESP looks pretty big, though that is probably
>> a mirage: I have had no problem digging into it, nor have I
>> encountered any feelings of "how deep does this rabbit hole go?"  I
>> also don't know how many people/organizations use phpESP, so I'm not
>> sure what kind of upgrade resistance the community would offer.
>>
>> When you say "framework," what do you mean?  When I hear "a great deal
>> of what is currently custom ... would be provided .. in [a] modern
>> framework", that makes me think that phpESP wouldn't add much value
>> over the framework.
>>
>>
>> > As for as a space for collaboration.  I can enable the wiki on the
>> > Sourceforge site or drop an instance of Trac on our hosting service.
>> >
>> > IRC is available here: irc://irc.freenode.net/phpesp/
>> > Or if you would rather have a Jabber/XMPP conference room I can have
>> > that available in a few seconds.
>>
>> I would think we'd want a wiki (or static repository of some kind), to
>> keep the documentation around for a longer period than afforded by
>> communication groups.
>>
>> bishop
>>
>>
>> > On Sun, 2008-04-20 at 19:38 -0400, Bishop Bettini wrote:
>> >> While I agree the code is horrendous in many places, I caution against
>> >> a wholesale rewrite, for the reasons Joel gives here:
>> >> http://www.joelonsoftware.com/articles/fog0000000069.html
>> >>
>> >> But, if that is the tack taken for v3, we should define the
>> >> requirements, write the functional specification, identify re-use and
>> >> re-factor candidates, decide on the platform tools, draw the road map,
>> >> and declare milestones.  In other words, do it right and try not to
>> >> make the same mistakes.
>> >>
>> >> On that note, is there a wiki or some other collaboration space where
>> >> this information (requirements, specifications, etc) can be maintained?
>> >>
>> >> bishop
>> >>
>> >> Quoting Franky Van Liedekerke <lie...@te...>:
>> >>
>> >> > On Sat, 19 Apr 2008 20:21:28 -0400
>> >> > Matthew Gregg <mat...@gm...> wrote:
>> >> >
>> >> >> So many things need to be redone in the current code base:
>> >> >> * Permission system
>> >> >> * User management
>> >> >> * The admin UI <-biggie
>> >> >> * Survey results export
>> >> >> * Survey question storage export/interchange
>> >> >> * etc...
>> >> >> and it's already in a pretty ugly state, that I have had "flip the
>> >> >> switch and start over" in my head for a long time.  I have worked
>> >> >> privately on a few proof of concepts for this, but never pushed to
>> >> >> have something usable.  Current code could be put into maintenance
>> >> >> mode and new dev only on this "branch".
>> >> >
>> >> > well, I agree here: the current code is ugly and I sometimes thought
>> >> > about beginning from scratch again also. So I'm in favour of starting
>> >> > over also.
>> >> >
>> >> > Franky
>> >> >
>> >> >   
>> -------------------------------------------------------------------------
>> >> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> >> > Don't miss this year's exciting event. There's still time to save $100.
>> >> > Use priority code J8TL2D2.
>> >> >
>> >>   
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> >> > _______________________________________________
>> >> > phpESP-devel mailing list
>> >> > php...@li...
>> >> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>> >> >
>> >>
>> >>
>> >>
>> > --
>> > Matthew Gregg <mat...@gm...>
>> >
>> >
>> > -------------------------------------------------------------------------
>> > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
>> > Don't miss this year's exciting event. There's still time to save $100.
>> > Use priority code J8TL2D2.
>> >   
>> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
>> > _______________________________________________
>> > phpESP-devel mailing list
>> > php...@li...
>> > https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>> >
>>
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

I don't think Hord is the kind of framework I was thinking of.
In PHP land, CakePHP and Symfony are probably the top contenders.

On Mon, 2008-04-21 at 11:51 -0400, Bishop Bettini wrote:
> Yes, Horde (www.horde.org) comes to mind (except the unit test  
> part...).  They already have a "Polls" application (scry), so Horde  
> might not be a good framework to use.  Did you have any particular  
> frameworks in mind?

Re: [phpesp-dev] updated version

[Bishop B. <ph...@id...>]

Never used either, both look reasonable.  The documentation for  
symfony seems to be more robust, but symfony also seems to be a more  
elaborate construct. Symfony is based upon propel, which I've never  
particularly cottoned, while CakePHP is based upon PDO, which I like.

I think Horde would work too -- it has all the foundation classes  
afforded by the others, and you don't need to actually run the  
application inside of a Horde install.  Though a Horde-based  
application running outside of a Horde install definitely has more  
mass than it needs.  But, I know numerous universities use Horde for  
email, etc, and getting hooked in with them might be an attractive  
addition to the phpESP community.

On the subject of attraction, one particularly attractive aspect of  
phpESP is its performance.  For my business cases, performance is a  
top concern: 10,000+ simultaneous requests are reasonable and should  
be actionable without the need for a leviathan box (eg 8-way processor  
and 32 GB of RAM).  IMO, whatever framework is chosen should not  
sacrifice performance.

To that point, I'm perfectly happy (and accustomed) to use:
* PEAR classes
* Smarty
* PHPUnit2
* phing

While not a "unified framework," these components provide all the  
functionality and flexibility needed, without shoehorning us into a  
framework's view of the world.

I'd say we should document the requirements then compare various  
frameworks and make a buy/build decision based on that analysis.

Of course, it all starts with requirements.... now where is that wiki. :)

bishop

Quoting Matthew Gregg <mat...@gm...>:

> I don't think Hord is the kind of framework I was thinking of.
> In PHP land, CakePHP and Symfony are probably the top contenders.
>
> On Mon, 2008-04-21 at 11:51 -0400, Bishop Bettini wrote:
>> Yes, Horde (www.horde.org) comes to mind (except the unit test
>> part...).  They already have a "Polls" application (scry), so Horde
>> might not be a good framework to use.  Did you have any particular
>> frameworks in mind?
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________
> phpESP-devel mailing list
> php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpesp-devel
>



-- 
Bishop Bettini
ideacode, Inc.
(main) +1 919 341 5170 / (fax) +1 919 521 4100

Visit us on the web at:
ideacode.com          Professional software research and development
reviewmysoftware.com  Improve sales! Review your software before you release
bytejar.com           Solutions to those annoying development problems

Re: [phpesp-dev] updated version

[Franky V. L. <lie...@te...>]

On 4/21/08, Bishop Bettini <ph...@id...> wrote:
>
> Yes, Horde (www.horde.org) comes to mind (except the unit test
> part...).  They already have a "Polls" application (scry), so Horde
> might not be a good framework to use.  Did you have any particular
> frameworks in mind?
>
> bishop



I've already seen horde, and it might be personal, but I don't like it very
much ...
Let's stick, like mentioned, to known technology: adodb (or pear, but then
we lose the xml db updating again ...), some templating engine (smarty
maybe?), etc ...

Franky

Re: [phpesp-dev] updated version

[Matthew G. <mat...@gm...>]

I also agree that Horde wouldn't be a very good fit, but I would like to
evaluate at least CakePHP, Symfony, CodeIgniter and perhaps Zend
Framework.

On Tue, 2008-04-22 at 09:54 +0200, Franky Van Liedekerke wrote:
> 
> On 4/21/08, Bishop Bettini <ph...@id...> wrote: 
>         Yes, Horde (www.horde.org) comes to mind (except the unit test
>         part...).  They already have a "Polls" application (scry), so
>         Horde
>         might not be a good framework to use.  Did you have any
>         particular
>         frameworks in mind?
>         
>         bishop
>  
>  
> I've already seen horde, and it might be personal, but I don't like it
> very much ...
> Let's stick, like mentioned, to known technology: adodb (or pear, but
> then we lose the xml db updating again ...), some templating engine
> (smarty maybe?), etc ...
>  
> Franky
> 
>  
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
> Don't miss this year's exciting event. There's still time to save $100. 
> Use priority code J8TL2D2. 
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> _______________________________________________ phpESP-devel mailing list php...@li... https://lists.sourceforge.net/lists/listinfo/phpesp-devel
-- 
Matthew Gregg <mat...@gm...>