Component Repository (ideas and thoughts)

[Knut]

Hi everyone,

We had some discussions on what to do with our Component Repository on PradoCamp last month. We agreed on two things:

1) The current solution with sharing components through the forum is not good.
2) We should start a thread on what to do.

So here are my thoughts on this subject, and these ideas are open for discussion:

1) We should have a shared Subversion repository and Trac environment (i.e. http://svn.pradosoft.com/repos/components and http://trac.pradosoft.com/components).
This way we have a coordinated community process, and you can always get the latest version by checking out trunk of the component.

I propose a repository structure like this:

Code:

components/
  Services/
    ...
  Modules/
    ...
  WebControls/
    TCaptcha/
      trunk/
        README
        INSTALL
        HISTORY
        src/
          TCaptcha.php
          TCaptcha.tpl
        doc/
        tests/
          unit/
          functional/
        build.xml
      tags/
        1.0/
  ActiveControls/
    ...

Or should we split it up in categories like: "Maps", "Media", "Caching", "Date and Time" etc.?

We should maybe have some kind of standard INFO-file that can provide the content that should be displayed on the corresponding front-end page for the component.

2) All components should belong to a category and have a nice front-end (i.e. http://www.pradosoft.com/components)
Here you can browse through all components and read all the details about them. Here you should also be able to download both the latest stable and unstable version of the component.

See: http://pear.php.net/packages, http://pecl.php.net/packages and http://drupal.org/project/Modules for inspiration.

Please raise your voice if you feel you have something to say about this, or you want to help out in some way. I can do the setup of subversion and trac for this and organize who gets access to what. Someone need to take care of the front-end part

[DaMule]

I believe to make the a component repository useful the uses (person looking for a component) needs to be able to judge the quality and usefulness relative to the user of the component. There a number of metrics we could do this with.

• User based rating (e.g. star rating of Amazon)
• Date Uploaded (when the component was added to the repository)
• Last Update
• Number of downloads
• User comments (Allow anonymous user comments to be added)
• Author stats (Number of other components uploaded, avg. rating, testimonials from other users)
• Installation instructions (helpful if your looking for something you can quickly get working
• View Source Code

There are more things, I'll add them to my list as I think of any more good ones. I think we can take inspiration from site like:

phpclasses
Amazon
Fresh Meat
Source Forge

All theses sites give you tools to decide if this thing your looking at is what you want.

[Knut]

Do you think we should consider using something like GForge? (http://gforge.org/)

Some examples of various repositories:
- http://www.sugarexchange.com/
- http://joomlacode.org/
- http://forge.mysql.com/

[DaMule]

GForge does seem like a good idea, we are migrating over to it at The Selling Source, but I'm not sure if it's right for the Prado community. It's a big commitment in terms of installation it's not really just an app you can install on your web server, it's a whole environment. If we could find someone to install and manage it that it won't be quite such a problem.

I also think it would be good for Prado is we wrote the component repository (cr) using Prado, I know I would be on board for doing development for it and the components we use to build the cr would help kick off the collection of components.

[Knut]

I've just set up a Subversion repository and a Trac environment for our Component Repository.

Subversion: http://svn.pradosoft.com/repos/components
Trac: http://trac.pradosoft.com/components

I submitted the MPLightBoxImage component under Media as a demo (http://trac.pradosoft.com/components/changeset/1) and some categories (http://trac.pradosoft.com/components/changeset/2). I'll add a build.xml file for Phing which can be used as a template in addition to some unit and functional tests.

Let's start from here now. We'll use the wiki in trac to document guidelines on how to write components.

To get write access to http://svn.pradosoft.com/repos/components please PM me on the forum with some details on what component you are gonna submit, and you'll get access as soon as possible.

Remember to clearly state the licensing terms of your component. It's preferred that it's compatible with the new BSD license that PRADO is using.

[tof06]

Hi Knut,

This sounds great !
The current subversion repository can't be downloaded anonymously, is it normal ?

While waiting for a cool web interface to search/document/download/upload/rate/... components, we can use the wiki also to make a small presentation of the component, what it does, licence, ...
We could define a standard structure (and perhaps wiki macros) to help components developpers to make this page.

Well, this is a good start to our new component repository

Tof.

[Knut]

Sorry, now it is public read access: http://svn.pradosoft.com/repos/components/

I'm thinking of using a really simple structure and using both the plain text files and a standard Phing build file to do all needed tasks for building the front-end of all components just to make it really easy for the developers. I think we should use HISTORY, README and INSTALL. If presented it could be used as part as the web based documentation. We should have a "doc" target to generate phpdoc from the components. Development should happen in trunk/ and releases should be placed in tags/. This way it's easy to find the latest stable version and the latest development version and do nightly packaging for easy download.

[DaMule]

Is there a way I can help get involved with the front end part of the project. I'd love to help build a slick system.

[mata_svada]

Ok, I've just commited (read "after one hour of struggle with subversion because it was the first time I used it I finally managed to commit something that looks allright") my SEmailer component. Here you can have a look at the source code.

To get the source code do this (if you're using a Unix-based system, don't know how to do this in Windows):

svn checkout http://svn.pradosoft.com/repos/components/Mail/SEmailer/trunk/

P.S.: Don't forget to check out the demo...

[Ben]

P.S.: Don't forget to check out the demo...

"Demo" - That's it!

I really love the samples in quick start tutorial!
Maybe it could be possible to provide something similar for the component repository?

It's so helpfull to see a sample of how a component works, how the author intended it to be used and what basic features it provides.

[schmunk]

Hi,

I am very happy about this thread. Looks like things are moving in a very good direction

I like the idea of a subversion repository for components very much, because you can stay bleeding edge or just download (export) a part of the repository. But we really have to deal with permissions and naming conventions.

About permissions
Gforge looks nice, but I think it's a bit too much, as DaMule mentioned it.

Subversion can handle links to external repositories ... including a "link" to itself. So, what do you think about creating a "user" or "by_user" directory with folders with usernames inside, like
|-- Debug
|   `-- JOEControl <== svn:external
|       `-- JOEControl.php
|-- user
|   `-- joe
|       `-- JOEControl
|           |-- branches
|           |-- tag
|           `-- trunk
|               `-- JOEControl.php
while there is a svn:external property in Debug, defining an external pointing to, i.e.
JOEControl  http://svn.pradosoft.com/repos/components/user/joe/JOEControl/trunk/

This would give us cool options, like
1. manage the user permissions only in the user directory
2. a convenient naming
3. components can be added, i.e. when reviewed and removed, i.e. inactivity (propedit svn:external) from the "catalogue" by a master admin, but still stays available in the user directory
4. developers could manage their subfolder permissions via a web interface, i.e. adding write-access for a component (folder)
5. creating customized sets of components i.e. a /Applications/PradoBlog
Trac should be able to handle this:
http://trac.edgewall.org/ticket/2340
http://trac.edgewall.org/ticket/4672 (funny)


About naming conventions
I would really recommend, no I will insist on a strict convention on prefixing controls.
Imagine you always have to think about the prefixes like ... was it "LxImage" or "LXImage"? And even better, when your on a Mac, with - usually - a case-insensitive file-system, you will get exceptions not until your're on your Linux production box ...
Therfore: strict prefixing rules!

A suggestion:
1. all prefixes are 2 or 3 chars in length
2. first character is upper-case, second and or third lower-case (the prado-style option)
for sure, there could also be an upper-case only rule. Do we need a poll for this?
3. all prefix-chars have to be letters from A-Z
or alphanumeric?

Examples:
LxImage
BtzRepeater
HmControl
XccPageService

If possible, we should use a svn-hook to ensure this; maybe also an admin could approve prefixes and add them to a regexp per user-dir. I'm not that familar with regexps in svn-hooks, but I think about something like:
/^[A-Z]{1}[a-z]{1,2}/
for these directories /components/user/*/.


I would like to see this project go hand in hand with the portlet system, mentioned here: http://www.pradosoft.com/forum/index.php/topic,7791.0.html


Best regards,
schmunk

[Guizmo]

lol ok let's play with the examples http://modxcms.com/resources.html or more simply http://www.hotscripts.com/. The latter would also be a good Prado project example that would also serves the community as a component repository. So this frontend along a subversion repository would be near perfect.

Whatever this Prado component repository is a recurrent subject with no end unhappily  maybe, i hope, this thread and new volunteers will make things change, tout would also not be luxury as it's very strange that a component framework does not have a component repository for its community 

Before thinking of developping a frontend like hotscript and following the idea to use an existing product, i were thinking of using gForge also but as Damule said, it's a whole environment. I suppose, but this has to be checked, the problem is the same with gForge AS (advanced server). Whatever i think we don't have this problem with the following products :
- Codebeamer http://www.intland.com/products/codebeamer.html?source=javaforge
- Collabnet http://www.collab.net/products/enterprise_edition/

That were for the java part, now the php side :
- Savane    https://gna.org/projects/savane
- Siteforge  http://www.sitelliteforge.com/index/siteforge-app/proj.siteforge

Using one of this product right now would bring a true end to this subject which is debated along months and years... now on an ideal side, DaMule and i have the same opinion enounced at the begginning : building our component repository

[Guizmo]

By the way, Tanus started some work months ago http://components.fivethingsabout.com/

[Thor]

So what ever happened to the component repository ideea?

I really like what Tanus did over there, is it his code? Maybe we can make it official, and spread it.

Where can i get more info on it's status?

[mikl]

I also think a demo section is important. Most people are too lazy busy to download and install a component and not having it seen in action first.

BTW i'd be happy to share a component of mine i call "MEffectPanel" which evolved from this discussion: http://www.pradosoft.com/forum/index.php/topic,6135.0.html. So some SVN acces would be great.