PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)
From: Manuel Lemos (mlemos_at_acm.org)
Date: 11/01/03
- Previous message: R. Rajesh Jeba Anbiah: "Re: Extract data from table html"
- Next in thread: Zurab Davitiani: "Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)"
- Reply: Zurab Davitiani: "Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 01 Nov 2003 11:37:10 -0200
Hello,
On 10/31/2003 06:48 AM, Zurab Davitiani wrote:
>>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.
>
>
> 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.
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?
> 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).
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.
> 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.
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.
> 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.
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.
> 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.
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.
> I don't think this will be "bureaucratic", 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.
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.
> 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).
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.
> 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.
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/
- Previous message: R. Rajesh Jeba Anbiah: "Re: Extract data from table html"
- Next in thread: Zurab Davitiani: "Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)"
- Reply: Zurab Davitiani: "Re: PHP Classes suggestions (was Re: Recommendations for PHP Form Validation Script)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
