Recommendations for PHP Form Validation Script

[Phil Powell]

Where can I find an online PHP form validator script library to use? I
have tried hacking the one here at work for weeks now and it's getting
more and more impossible to customize, especially now with form
elements that turn out to be arrays that have to be compared with one
another!

I have one form element, languages, a checkbox group. Beside each
checkbox is a dropdown, proficiency (which will become proficiency[]
alongside languages[]). The crux of the matter is that I have to
compare a checked language with the selected proficiency, the
proficiency dropdown beside the checked language must be selected;
furthermore, at least one language must be checked, up to 4.

To complicate matters further, Javascript client-side validation is
forbidden due to Section 508 U.S. Government compliance putting a lock
on any client-side validation script. Section 508 dictates that all
things in <script> tags must be followed by <noscript> corresponding
logic, which is impossible for validation, so no client-side
validation.

I am tired of hacking this existing set of classes and about 50
methods per class to validate more the more complicated forms I have
to develop. I didn't even mention that you have a group of form
elements pertaining to "job history": about 15 textboxes, 3 radio
buttons and 5 dropdowns - PER JOB HISTORY that will dynamically appear
per user clicking a "Add New Employment History" button. So now you
will have jobTitle[], jobAddress[], jobStartDateMon th[],
jobStartDateYea r[], jobEndDateDay[], etc.

So, basically it's either I keep hacking at the existing code.. or I
find an existing form validator package out there. Recommendations ,
anyone?

Thanx
Phil

[Guest]

Re: Recommendations for PHP Form Validation Script

"Phil Powell" <soazine@erols. com> wrote in message
news:1cdca2a7.0 310280816.e5e2d fa@posting.goog le.com...[color=blue]
>
> To complicate matters further, Javascript client-side validation is
> forbidden due to Section 508 U.S. Government compliance putting a lock
> on any client-side validation script. Section 508 dictates that all
> things in <script> tags must be followed by <noscript> corresponding
> logic, which is impossible for validation, so no client-side
> validation.[/color]

Why is it impossible? Just make a self-validating form (i.e., submits to
$_SERVER['PHP_SELF']), and insert the server validation code in the
<noscript></noscript> section. Something like...

if ($_POST['name'] && $_POST['email'] && $_POST['etc']) {
// form has been submitted - let's validate!
doValidation();
}

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/28/2003 02:16 PM, Phil Powell wrote:[color=blue]
> Where can I find an online PHP form validator script library to use? I
> have tried hacking the one here at work for weeks now and it's getting
> more and more impossible to customize, especially now with form
> elements that turn out to be arrays that have to be compared with one
> another!
>
> I have one form element, languages, a checkbox group. Beside each
> checkbox is a dropdown, proficiency (which will become proficiency[]
> alongside languages[]). The crux of the matter is that I have to
> compare a checked language with the selected proficiency, the
> proficiency dropdown beside the checked language must be selected;
> furthermore, at least one language must be checked, up to 4.
>
> To complicate matters further, Javascript client-side validation is
> forbidden due to Section 508 U.S. Government compliance putting a lock
> on any client-side validation script. Section 508 dictates that all
> things in <script> tags must be followed by <noscript> corresponding
> logic, which is impossible for validation, so no client-side
> validation.
>
> I am tired of hacking this existing set of classes and about 50
> methods per class to validate more the more complicated forms I have
> to develop. I didn't even mention that you have a group of form
> elements pertaining to "job history": about 15 textboxes, 3 radio
> buttons and 5 dropdowns - PER JOB HISTORY that will dynamically appear
> per user clicking a "Add New Employment History" button. So now you
> will have jobTitle[], jobAddress[], jobStartDateMon th[],
> jobStartDateYea r[], jobEndDateDay[], etc.
>
> So, basically it's either I keep hacking at the existing code.. or I
> find an existing form validator package out there. Recommendations ,
> anyone?[/color]

You may want to try this popular form validation class. It can do both
client side or server side validation. For the client side validation it
generates <noscript></noscript> sections to be compliant with your
requirements, but if you are not satisfied you can tell the class to not
generate client side validation at all.

http://www.phpclasses.org/formsgeneration

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Matthias Gutfeldt]

Re: Recommendations for PHP Form Validation Script

Manuel Lemos wrote:[color=blue]
> You may want to try this popular form validation class. It can do both
> client side or server side validation. For the client side validation it
> generates <noscript></noscript> sections to be compliant with your
> requirements, but if you are not satisfied you can tell the class to not
> generate client side validation at all.
>
> http://www.phpclasses.org/formsgeneration[/color]

Oh bother, it takes four clicks to get even close to the files. And each
time I have to wait until the advertising is loaded and finally the
actual links show up. And after all that, I have to register before I
can (hopefully? I gave up here) download the files...

Not the most convenient script repository :-(.


Matthias

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:[color=blue][color=green]
>> You may want to try this popular form validation class. It can do both
>> client side or server side validation. For the client side validation
>> it generates <noscript></noscript> sections to be compliant with your
>> requirements, but if you are not satisfied you can tell the class to
>> not generate client side validation at all.
>>
>> http://www.phpclasses.org/formsgeneration[/color]
>
>
> Oh bother, it takes four clicks to get even close to the files. And each[/color]

At least you can see the files before having to download the whole
package to your disk.

[color=blue]
> time I have to wait until the advertising is loaded and finally the[/color]

This is a free site where over 600 authors share their code. Developing
and hosting the site costs time and money. Advertising helps covering
the costs. At least the advertising in on topic. You practically only
see ads that have to do with the interests of the site users.

But if you find the advertising so disturbing, in the future there will
be a paid subscription model that for a small montly fee will provide
among other things, access to the site pages without advertising.

[color=blue]
> actual links show up. And after all that, I have to register before I
> can (hopefully? I gave up here) download the files...[/color]

Requiring registration before downloading is an option that is up to
each author to decide on each file of their packages.

Registration lets the set keep track of who downloaded what and so make
accurate top downloaded packages ranking. This provides useful
information for the authors, so see how well appreciated are their
packages. As an user you may not appreciate this much, but most authors
find that very motivating and encourages them to keep contributing.

At the same time, when an author updates a package, the site is able to
figure which users downloaded the package and send them a new content
alert message by e-mail. Of course, users that do not want this, may
specify that in their options page.

[color=blue]
> Not the most convenient script repository :-(.[/color]

If you still find thin inconvenient, you can always mail the authors of
the packages listed there and ask them to send you the packages you want.


--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Phil Powell]

Re: Recommendations for PHP Form Validation Script

Thanx for the tip. However, your packaged classes don't satisfy my needs.
The form contents are extremely complicated, consisting of dynamic arrays,
dynamic form element groups that dynamically grow upon a form submit click,
and even a set of enumerative arrays whose values are compared with keys of
an associative array - all within the same FORM! (the form has over 200
elements)

Phil

"Manuel Lemos" <mlemos@acm.org > wrote in message
news:bnpgd1$13r fvk$1@ID-138275.news.uni-berlin.de...[color=blue]
> Hello,
>
> On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:[color=green][color=darkred]
> >> You may want to try this popular form validation class. It can do both
> >> client side or server side validation. For the client side validation
> >> it generates <noscript></noscript> sections to be compliant with your
> >> requirements, but if you are not satisfied you can tell the class to
> >> not generate client side validation at all.
> >>
> >> http://www.phpclasses.org/formsgeneration[/color]
> >
> >
> > Oh bother, it takes four clicks to get even close to the files. And each[/color]
>
> At least you can see the files before having to download the whole
> package to your disk.
>
>[color=green]
> > time I have to wait until the advertising is loaded and finally the[/color]
>
> This is a free site where over 600 authors share their code. Developing
> and hosting the site costs time and money. Advertising helps covering
> the costs. At least the advertising in on topic. You practically only
> see ads that have to do with the interests of the site users.
>
> But if you find the advertising so disturbing, in the future there will
> be a paid subscription model that for a small montly fee will provide
> among other things, access to the site pages without advertising.
>
>[color=green]
> > actual links show up. And after all that, I have to register before I
> > can (hopefully? I gave up here) download the files...[/color]
>
> Requiring registration before downloading is an option that is up to
> each author to decide on each file of their packages.
>
> Registration lets the set keep track of who downloaded what and so make
> accurate top downloaded packages ranking. This provides useful
> information for the authors, so see how well appreciated are their
> packages. As an user you may not appreciate this much, but most authors
> find that very motivating and encourages them to keep contributing.
>
> At the same time, when an author updates a package, the site is able to
> figure which users downloaded the package and send them a new content
> alert message by e-mail. Of course, users that do not want this, may
> specify that in their options page.
>
>[color=green]
> > Not the most convenient script repository :-(.[/color]
>
> If you still find thin inconvenient, you can always mail the authors of
> the packages listed there and ask them to send you the packages you want.
>
>
> --
>
> Regards,
> Manuel Lemos
>
> Free ready to use OOP components written in PHP
> http://www.phpclasses.org/
>[/color]

[Matthias Gutfeldt]

Re: Recommendations for PHP Form Validation Script

Manuel Lemos wrote:[color=blue]
> On 10/29/2003 07:39 AM, Matthias Gutfeldt wrote:
>[color=green][color=darkred]
>>> You may want to try this popular form validation class. It can do
>>> both client side or server side validation. For the client side
>>> validation it generates <noscript></noscript> sections to be
>>> compliant with your requirements, but if you are not satisfied you
>>> can tell the class to not generate client side validation at all.
>>>
>>> http://www.phpclasses.org/formsgeneration[/color]
>>
>> Oh bother, it takes four clicks to get even close to the files. And each[/color]
>
> At least you can see the files before having to download the whole
> package to your disk.
>
>[color=green]
>> time I have to wait until the advertising is loaded and finally the[/color]
>
>
> This is a free site where over 600 authors share their code. Developing
> and hosting the site costs time and money. Advertising helps covering
> the costs. At least the advertising in on topic. You practically only
> see ads that have to do with the interests of the site users.[/color]

I know - I know! I'm not blasé enough to complain about free code,
really. And I'm grateful for all the work the authors put into those
classes. It's just a rather frustrating experience trying to get the
code, that's all. Perhaps there's a way to streamline the process.

[color=blue]
> But if you find the advertising so disturbing, in the future
> there will be a paid subscription model that for a small montly
> fee will provide among other things, access to the site pages
> without advertising.[/color]

Thanks for the info. I'll check that out when it's available.


Matthias

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/30/2003 05:58 AM, Phil Powell wrote:[color=blue]
> Thanx for the tip. However, your packaged classes don't satisfy my needs.
> The form contents are extremely complicated, consisting of dynamic arrays,
> dynamic form element groups that dynamically grow upon a form submit click,
> and even a set of enumerative arrays whose values are compared with keys of
> an associative array - all within the same FORM! (the form has over 200
> elements)[/color]

And what is the problem with that? In what way do you think the class
does not satisfy your needs or at least could be used to simplify the
solution to satisfy your needs?

[color=blue][color=green][color=darkred]
>>>>You may want to try this popular form validation class. It can do both
>>>>client side or server side validation. For the client side validation
>>>>it generates <noscript></noscript> sections to be compliant with your
>>>>requirement s, but if you are not satisfied you can tell the class to
>>>>not generate client side validation at all.
>>>>
>>>>http://www.phpclasses.org/formsgeneration[/color][/color][/color]


--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/30/2003 07:24 AM, Matthias Gutfeldt wrote:[color=blue][color=green]
>> This is a free site where over 600 authors share their code.
>> Developing and hosting the site costs time and money. Advertising
>> helps covering the costs. At least the advertising in on topic. You
>> practically only see ads that have to do with the interests of the
>> site users.[/color]
>
>
> I know - I know! I'm not blasé enough to complain about free code,
> really. And I'm grateful for all the work the authors put into those
> classes. It's just a rather frustrating experience trying to get the
> code, that's all. Perhaps there's a way to streamline the process.[/color]

The means justify the ends. Once you login, it is straight forward.

Anyway, the site has 4 years and many features have been implemented
upon suggestions of the users. If you have anything to suggest to
improve it in a realistic way, feel free to present your suggestion.



--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Zurab Davitiani]

Re: Recommendations for PHP Form Validation Script

Manuel Lemos wrote on Thursday 30 October 2003 10:27:
[color=blue]
> Anyway, the site has 4 years and many features have been implemented
> upon suggestions of the users. If you have anything to suggest to
> improve it in a realistic way, feel free to present your suggestion.[/color]

[OT from original discussion but] Here are two:

1. implement the class/package dependency listing. I made this suggestion to
you before, as a part of a bigger one, but not on its own. i.e., if
developer A creates class X that extends or uses developer B's (or his own)
class Y, then there needs to be a simple way for developer A to list class
Y as a dependency, rather than including that class in his package.

This becomes a bigger issue when you are talking about two or more packages
and not just single-file classes. This will also see a better use with much
better OO features in PHP5.

2. I would think number of developers may have already suggested to you, but
there needs to be a way to upload an archive directly to the site, rather
than each file one by one.

Hope this is helpful.

--
Business Web Solutions
ActiveLink, LLC

https://www.active-link.com/intranet/

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/30/2003 09:13 PM, Zurab Davitiani wrote:[color=blue][color=green]
>>Anyway, the site has 4 years and many features have been implemented
>>upon suggestions of the users. If you have anything to suggest to
>>improve it in a realistic way, feel free to present your suggestion.[/color]
>
>
> [OT from original discussion but] Here are two:
>
> 1. implement the class/package dependency listing. I made this suggestion to
> you before, as a part of a bigger one, but not on its own. i.e., if
> developer A creates class X that extends or uses developer B's (or his own)
> class Y, then there needs to be a simple way for developer A to list class
> Y as a dependency, rather than including that class in his package.
>
> This becomes a bigger issue when you are talking about two or more packages
> and not just single-file classes. This will also see a better use with much
> better OO features in PHP5.
>
> 2. I would think number of developers may have already suggested to you, but
> there needs to be a way to upload an archive directly to the site, rather
> than each file one by one.[/color]

Thank you for the suggestions. They have been on my to do list for some
time now.

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.


Any ideas to solve these problems in the most convinient way are welcomed.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Manuel Lemos]

Re: Recommendations for PHP Form Validation Script

Hello,

On 10/30/2003 09:13 PM, Zurab Davitiani wrote:[color=blue][color=green]
>>Anyway, the site has 4 years and many features have been implemented
>>upon suggestions of the users. If you have anything to suggest to
>>improve it in a realistic way, feel free to present your suggestion.[/color]
>
>
> [OT from original discussion but] Here are two:
>
> 1. implement the class/package dependency listing. I made this suggestion to
> you before, as a part of a bigger one, but not on its own. i.e., if
> developer A creates class X that extends or uses developer B's (or his own)
> class Y, then there needs to be a simple way for developer A to list class
> Y as a dependency, rather than including that class in his package.
>
> This becomes a bigger issue when you are talking about two or more packages
> and not just single-file classes. This will also see a better use with much
> better OO features in PHP5.
>
> 2. I would think number of developers may have already suggested to you, but
> there needs to be a way to upload an archive directly to the site, rather
> than each file one by one.[/color]

Thank you for the suggestions. They have been on my to do list for some
time now.

1. Class dependency is not hard. However, I have not envisioned how the
user interface would work to let authors pick dependency classes from
more than 1130 approved classes that exist now.

2. Bulk uploading is more complicated. Regardless how the authors upload
their classes, they need still need to enter descriptions and specify
the role for each file. I am not sure how this could be done and in the
end the authors do not complain that it is still bureaucratic.

Package bulk updating would be another issue because the site would have
to know which files are being updated and which are new.

I though of having support to synchronize with a remove CVS server
indicated by the author when the update is meant to be performed. but
not every author has their projects in a public CVS server.


Any ideas to solve these problems in the most convinient way are welcomed.

--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Zurab Davitiani]

Re: Recommendations for PHP Form Validation Script

Manuel Lemos wrote on Thursday 30 October 2003 19:32:
[color=blue]
> 1. Class dependency is not hard. However, I have not envisioned how the
> user interface would work to let authors pick dependency classes from
> more than 1130 approved classes that exist now.
>
> 2. Bulk uploading is more complicated. Regardless how the authors upload
> their classes, they need still need to enter descriptions and specify
> the role for each file. I am not sure how this could be done and in the
> end the authors do not complain that it is still bureaucratic.
>
> Package bulk updating would be another issue because the site would have
> to know which files are being updated and which are new.
>
> I though of having support to synchronize with a remove CVS server
> indicated by the author when the update is meant to be performed. but
> not every author has their projects in a public CVS server.
>
>
> Any ideas to solve these problems in the most convinient way are welcomed.[/color]

Just ask. I do have those :)

Now, I don't know the internals of your system, but having used it here are
what I think are some options on how to do those:

1. You are right - dependency may look simple on its face, but details may
end up being slightly more complicated. As far as picking dependency
packages, you could allow class authors to (1) search for packages by name
or description, (2) browse to it, or (3) type its ID; next, you find these
packages, let user select and confirm which packages they want to add as
dependencies, then add them.

One thing to consider in this, at some point, is versioning - you may want
to force developers to enter some kind of version number or an identifier
so that when a package is updated (say B and C are dependent on A),
- package A author selects whether the update he is making may break
compatibility (if A is listed as a dependency);
- if so, then dependent package authors (B and C) are notified of the change
and have an opportunity to check/fix compatibility;
- meanwhile, users on the website are notified whether compatibility has
been confirmed by developer(s).

On a user-side of things, when listing dependencies of a package, you may
want to have a link to "download all" to get all of them.

2. As far as bulk uploading, when an archive is uploaded (zip, tar.gz,
etc.), check every file by path and filename against existing package
entries, then provide 4 sections on the next page as follows:

(A) for the filenames that are already present in the package, simply let
the user know that they will be overwritten;

(B) for the filenames that are new, display a table (or a div/span
structure) for user to enter each new file's description and pick a role;

(C) for the filenames that were present in the original structure but are
missing from the uploaded archive, present user with the choice to keep
each one as is, or remove it from the package.

(D) for files that generated errors, e.g. binary files, etc. let user know
what error(s) occurred, correct errors and retry, or upload those files
individually afterwards.

Complete package update only after user confirms and approves what is
described in A, B, C, and D.

The only thing that you'll be missing is a changelog for each individual
file like you have it now. I don't know for other developers, but if you
ask me, that is not necessary - you may want to ask for an overall
changelog instead.

I don't think this will be "bureaucrat ic", since most updates should be
covered in (A), (B) would not happen a lot unless there were major changes
or a complete overhaul, (A) and (D) are simply notices, (C) should be a
pretty trivial boolean choice.

One thing to consider is that this may not cover situations when files are
moved around in different directories. e.g., developer moved myclass.php
file to /classes/myclass.php or renamed it. To account for these cases, you
may have to either:

(a) explain on the "upload archive" page that if that is the case, they
first need to make sure the path and filenames in the package match those
in the new archive (if not, modify the package first); otherwise, their
history, including download count may get lost;
OR
(b) in a more complicated case, allow users to provide an option to "merge"
(i.e. update) one file with a different file from the archive, as an
additional option in section (C).

3. Do you have your code open-sourced? Is it well-organized and documented?
Maybe some could help you with these types of features in their spare time.

--
Business Web Solutions
ActiveLink, LLC

https://www.active-link.com/intranet/

[Manuel Lemos]

PHP Classes suggestions (was Re: Recommendations for PHP Form ValidationScrip t)

Hello,

On 10/31/2003 06:48 AM, Zurab Davitiani wrote:[color=blue][color=green]
>>1. Class dependency is not hard. However, I have not envisioned how the
>>user interface would work to let authors pick dependency classes from
>>more than 1130 approved classes that exist now.
>>
>>2. Bulk uploading is more complicated. Regardless how the authors upload
>>their classes, they need still need to enter descriptions and specify
>>the role for each file. I am not sure how this could be done and in the
>>end the authors do not complain that it is still bureaucratic.
>>
>>Package bulk updating would be another issue because the site would have
>>to know which files are being updated and which are new.
>>
>>I though of having support to synchronize with a remove CVS server
>>indicated by the author when the update is meant to be performed. but
>>not every author has their projects in a public CVS server.
>>
>>
>>Any ideas to solve these problems in the most convinient way are welcomed.[/color]
>
>
> Just ask. I do have those :)
>
> Now, I don't know the internals of your system, but having used it here are
> what I think are some options on how to do those:
>
> 1. You are right - dependency may look simple on its face, but details may
> end up being slightly more complicated. As far as picking dependency
> packages, you could allow class authors to (1) search for packages by name
> or description, (2) browse to it, or (3) type its ID; next, you find these
> packages, let user select and confirm which packages they want to add as
> dependencies, then add them.[/color]

That would mean replicating the site navigation facilities.

I have a better idea. I will implement a sort of clipboard facility.
That would allow users to copy references to packages, groups, authors,
etc. so they could be user later for different purposes.

This way, if you want to add a dependency between two packages, first
you locate the dependency package and then copy it to the clipboard. In
the package page, you will have a link to a page to add a new package
dependency. In that page you can confirm that you want to add a
dependency to the current package on the clipboard. If there is no
package on the clipboard, you are told what to do to specify a package
to add a dependency.

What do you think?


[color=blue]
> One thing to consider in this, at some point, is versioning - you may want
> to force developers to enter some kind of version number or an identifier
> so that when a package is updated (say B and C are dependent on A),
> - package A author selects whether the update he is making may break
> compatibility (if A is listed as a dependency);
> - if so, then dependent package authors (B and C) are notified of the change
> and have an opportunity to check/fix compatibility;
> - meanwhile, users on the website are notified whether compatibility has
> been confirmed by developer(s).[/color]

I do not know if that is viable. First it is unrealistic to think that I
can force authors to do anything.

Currently the site requires that authors specify the role of each file
in a package. For old packages, I asked authors to do that themselves.
Most authors did not do it.

Some did it when they noticed that if they do not classify documentation
and example files as such, the users could not rate their packages in
those aspects.

They did it because they were loosing user rating ranking positions and
eventually the prizes that are offered every month by PHP-Editors site
to the best user rated packages in PHP Classes, but not all authors reacted.


Now, to your suggestions, it is viable to send the notifications and it
is a very good idea. What does not seem to be viable is to make sure the
developer really verified the compatibility when he was asked and confirmed.

So, the basic problem is what to do when these situations happen:
authors not versioning packages and authors pretended that confirmed
compatibility.

[color=blue]
> On a user-side of things, when listing dependencies of a package, you may
> want to have a link to "download all" to get all of them.[/color]

Yes, that would be a logical step.

There is however the problem of dependencies that are not so mandatory.

For instance, I have an email validation class that can work with the
DNS resolver class provided by other author in case GetMXRR is not
functional (for instance under Windows). It would be misleading to tell
users that do not really need that package to download it too because it
is a dependency. Maybe I should require authors to describe the scope of
the dependency.

[color=blue]
> 2. As far as bulk uploading, when an archive is uploaded (zip, tar.gz,
> etc.), check every file by path and filename against existing package
> entries, then provide 4 sections on the next page as follows:
>
> (A) for the filenames that are already present in the package, simply let
> the user know that they will be overwritten;
>
> (B) for the filenames that are new, display a table (or a div/span
> structure) for user to enter each new file's description and pick a role;
>
> (C) for the filenames that were present in the original structure but are
> missing from the uploaded archive, present user with the choice to keep
> each one as is, or remove it from the package.
>
> (D) for files that generated errors, e.g. binary files, etc. let user know
> what error(s) occurred, correct errors and retry, or upload those files
> individually afterwards.
>
> Complete package update only after user confirms and approves what is
> described in A, B, C, and D.[/color]

It sounds like a good plan but in practice there other problems to
solve, like where will be the data about the new files stored while the
author does not decide what to do with the files? Basically I would have
to replicate the files table which does not please me much.

It boils down all to have a upload staging system that I wanted to do
for another reason, which is to approve all the changes that the authors
do tio their packages. So, I think the solution may have to be better
thought to address both problems.


[color=blue]
> The only thing that you'll be missing is a changelog for each individual
> file like you have it now. I don't know for other developers, but if you
> ask me, that is not necessary - you may want to ask for an overall
> changelog instead.[/color]

It may not be necessary for you but it is for users of the packages.
When you add a new file you need to tell what it is. If you change a
file you can change descriptions as well tell what was changed, so the
site can provide useful information in the updated package e-mail message.

[color=blue]
> I don't think this will be "bureaucrat ic", since most updates should be
> covered in (A), (B) would not happen a lot unless there were major changes
> or a complete overhaul, (A) and (D) are simply notices, (C) should be a
> pretty trivial boolean choice.[/color]

I am not so sure about that. Anyway, it will be done as necessary. The
problem is that is if the authors end up not using it because it is too
bureaucratic. That would be a major waste of development effort for me.

[color=blue]
> One thing to consider is that this may not cover situations when files are
> moved around in different directories. e.g., developer moved myclass.php
> file to /classes/myclass.php or renamed it. To account for these cases, you
> may have to either:
>
> (a) explain on the "upload archive" page that if that is the case, they
> first need to make sure the path and filenames in the package match those
> in the new archive (if not, modify the package first); otherwise, their
> history, including download count may get lost;
> OR
> (b) in a more complicated case, allow users to provide an option to "merge"
> (i.e. update) one file with a different file from the archive, as an
> additional option in section (C).[/color]

Moving directories or renaming is the samething because the path is just
one field in the database. So, it would always be the case to let the
authors tell that a given file is meant to overwrite another existing file.

[color=blue]
> 3. Do you have your code open-sourced? Is it well-organized and documented?
> Maybe some could help you with these types of features in their spare time.[/color]

Thank you but this is not quite viable. The whole site is based on
classes but documenting it up to a level that it would make it useful
for others to understand and change would take me a very long time. So,
I would rather not commit to doing it when it is really not necessary.

Also, I do not want to open the source to not have to deal with
nightmare of people trying to fork the project and develop competitor
repositories.

I believe in opening the source code of projects when the advantages
outweight the disadvantages for the authors, which does not seem to be
the case.

Although this does not apply to everybody, the so called Open Source
community can be ungrateful and act against the authors that open the
code of their projects. When you open the source code of projects,
contributors often act as if they became owners of the project. I do not
agree with that.

A clear example of that was what happened to Sourceforge. I am sure that
if VA would not have opened the source code of the site itself if they
knew then what they know today, namely the ungrateful boycott and other
harmful actions against VA from members of the so called Free Software
Foundation.

Nothing against you, but I hope you understand why I would rather not
open the source code of the site.


--

Regards,
Manuel Lemos

Free ready to use OOP components written in PHP

http://www.phpclasses.org/

[Zurab Davitiani]

Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)

Manuel Lemos wrote on Saturday 01 November 2003 05:37:
[color=blue]
> That would mean replicating the site navigation facilities.
>
> I have a better idea. I will implement a sort of clipboard facility.
> That would allow users to copy references to packages, groups, authors,
> etc. so they could be user later for different purposes.
>
> This way, if you want to add a dependency between two packages, first
> you locate the dependency package and then copy it to the clipboard. In
> the package page, you will have a link to a page to add a new package
> dependency. In that page you can confirm that you want to add a
> dependency to the current package on the clipboard. If there is no
> package on the clipboard, you are told what to do to specify a package
> to add a dependency.
>
> What do you think?[/color]

That should be fine too. If you ask me, I'd be OK with simply typing an ID
as well. If a developer extending a class/package, they could easily look
up its ID without having to go through a slightly more involved clipboard.
[color=blue]
> Now, to your suggestions, it is viable to send the notifications and it
> is a very good idea. What does not seem to be viable is to make sure the
> developer really verified the compatibility when he was asked and
> confirmed.
>
> So, the basic problem is what to do when these situations happen:
> authors not versioning packages and authors pretended that confirmed
> compatibility.[/color]

Well, if you think they are not going to do versioning, then it's not worth
going through the hassle, I guess. Just send out the notices/requests to
confirm compatibility. But, I would think, as a side note, it would be
great to have an optional version field for a package anyway, so (for
authors/packages that would use them) users know if they are up-to-date or
not.

As far as compatibility itself, you cannot do compability testing for them
obviously, so it's totally 100% up to the authors. But when it comes down
to it the question is - is your inability to confirm compatibility between
dependent packages a good enough reason not to offer dependency linking
between packages altogether?

My answer would be "no" - let the developers sort out the compatibility
issues - you do your part of notifying both developers (via e-mail) and
users (on the website) when they may occur, and let the developers, users
and user ratings handle the rest.
[color=blue]
> For instance, I have an email validation class that can work with the
> DNS resolver class provided by other author in case GetMXRR is not
> functional (for instance under Windows). It would be misleading to tell
> users that do not really need that package to download it too because it
> is a dependency. Maybe I should require authors to describe the scope of
> the dependency.[/color]

Yeah, that's a good idea. A simple comment field should suffice. Otherwise,
you would have to get involved in multiple dependency trees involving
combinations of factors such as:
- PHP major/minor versions
- platforms and their major/minor versions
- compiled in or loadable modules and their major/minor versions
- etc.
[color=blue]
> It sounds like a good plan but in practice there other problems to
> solve, like where will be the data about the new files stored while the
> author does not decide what to do with the files? Basically I would have
> to replicate the files table which does not please me much.
>
> It boils down all to have a upload staging system that I wanted to do
> for another reason, which is to approve all the changes that the authors
> do tio their packages. So, I think the solution may have to be better
> thought to address both problems.[/color]

Well, if you plan to approve package changes manually, then that kind of
staging system is a good way to go.
[color=blue]
> It may not be necessary for you but it is for users of the packages.
> When you add a new file you need to tell what it is. If you change a
> file you can change descriptions as well tell what was changed, so the
> site can provide useful information in the updated package e-mail message.[/color]

I think the way I envisioned it (may not have been clear) is that in case of
new files, authors would still be required to put in their file
type/purpose and descriptions. As far as when the whole package is being
updated (as a whole) it may be an overkill to ask authors to provide
changelog for each file individually, but rather, ask for an overall
changelog instead. This way, users are advised of changes to the package,
rather than getting e-mails for each individual file update.

Again, I'm not suggesting any changes to the current system, but rather an
option on how to handle bulk package updates when uploading an archive.
[color=blue][color=green]
>> I don't think this will be "bureaucrat ic", since most updates should be
>> covered in (A), (B) would not happen a lot unless there were major
>> changes or a complete overhaul, (A) and (D) are simply notices, (C)
>> should be a pretty trivial boolean choice.[/color]
>
> I am not so sure about that. Anyway, it will be done as necessary. The
> problem is that is if the authors end up not using it because it is too
> bureaucratic. That would be a major waste of development effort for me.[/color]

I'm not sure what you mean by bureaucratic here. If I have to update 15
files in my package, one option is to go through each individual file and
re-upload it - about 30-45 pages to load/click through (depending on how
you do it); OR upload a single archive, and confirm changes (listed per
file) on the next page once. It seems to me it's a no-brainer.
[color=blue]
> Thank you but this is not quite viable. The whole site is based on
> classes but documenting it up to a level that it would make it useful
> for others to understand and change would take me a very long time. So,
> I would rather not commit to doing it when it is really not necessary.
>
> Also, I do not want to open the source to not have to deal with
> nightmare of people trying to fork the project and develop competitor
> repositories.
>
> I believe in opening the source code of projects when the advantages
> outweight the disadvantages for the authors, which does not seem to be
> the case.
>
> Although this does not apply to everybody, the so called Open Source
> community can be ungrateful and act against the authors that open the
> code of their projects. When you open the source code of projects,
> contributors often act as if they became owners of the project. I do not
> agree with that.
>
> A clear example of that was what happened to Sourceforge. I am sure that
> if VA would not have opened the source code of the site itself if they
> knew then what they know today, namely the ungrateful boycott and other
> harmful actions against VA from members of the so called Free Software
> Foundation.
>
> Nothing against you, but I hope you understand why I would rather not
> open the source code of the site.[/color]

Well, it's up to you, it was just a question. It's totally up to you for
whatever reasons you choose to keep it closed - it's none of my business.
Period.

I don't want to start a Sourceforge vs. Savannah flamewar but that's part of
open-sourcing - allowing others to extend your (generic "your") work the
way they see fit as long as they comply with the license. If I didn't agree
with how both FSF and VA update their product and provide the said service,
I could take Savannah or Sourceforge system and start providing my own
modified service. Who's to stop me?

From a strictly personal point of view, I wouldn't take a Sourceforge
example as a means of conclusion that open sourcing a project like that is
automatically "bad" since someone will likely take its controls over and
start providing a competitive service. I mean, that's [a predictable] part
of it, but not all of it. Take slashcode as an example, used by 100s (if
not more) sites, livejournal, even Sourceforge, in this respect, remains
extremely popular.

I guess what I am trying to say is that going one way or another is not a
simple straightforward line - it's a combination of a lot of different
factors; and, even in Sourceforge example, I cannot deduce that
sourceforge.net would have been a more popular service if it was NOT
open-sourced itself. I just can't draw that line.

Anyway, I thought I'd share my opinions.

--
Business Web Solutions
ActiveLink, LLC

https://www.active-link.com/intranet/