Jonathan Ernst wrote:
Le vendredi 04 février 2005 à 23:33 -0500, Chris Morgan a écrit :
Tony pointed out a handful of cases where it is useful to have multiple urls for an appId and perhaps multiple urls for a versionId. Do we have that functionality right now via another mechanism? I think we should look to add such a capability back into the appdb since it was used for a small number of apps.
Chris
I'd be interested to know about these cases, do you have examples ?
An example of app where we have URLs in application is here: http://appdb.winehq.org/appview.php?appId=10 (Word). IMHO (if the examples you are speaking about are like the Word example), in this case it is much more clear to put the link in the description than to have only a one-word description for each link.
_BEFORE WITH URLS IN APPS_
¦ AbiWord ¦ ¦ ¦ CrossOver Office ¦ Description ¦ ¦ OpenOffice.org ¦ ¦
_APPS NOW_
¦ Description ¦ ¦ ¦ ¦ Try it with CrossOver Office ! ¦ ¦ ¦ ¦ *Native alternatives:* ¦ ¦ - AbiWord ¦ ¦ - OpenOffice.org ¦
As you can see you can be much more descriptive and classify the interesting links.
In versions URLs have still a lot of sense as you can do thinks like:
¦ Download app ¦ ¦ ¦ Download MSX.dll ¦ Description ¦ ¦ ¦ ¦
See here for example: http://appdb.winehq.org/appview.php?versionId=2463
As I said I'd be interested to see these special cases where App URLs make sense. If there are more than only 4-5 application that need it and you think that the way to do it above is not right in these cases (or in all cases) we should of course bring back this feature.
By your argument we do not need the urls at all and could easily put them all in the description.
To bring it back:
- readd appid in appdata table: bad as it is strange to have columns
with appid=0 for screenshots and versionid=0 for URLs
OR
- rename appdata in versiondata, create a new appdata table and create
an url class that has an appid and version id parameter, if appid is given, queries will be made in appdata and if it's versionid they'll be made in versiondata
OR
- readd appid in appdata table and let people ad screenshots for
applications (this can be screenshot of the application running in windows to show people how it looks like normally). I personnaly don't like it too much as the purpose of removing App URLs and version Keywords was to remove the bloat in editing pages to ease the task of maintainers and try to have a consistant appdb.
OR
...
Regards. Jonathan
Option 1 is the way to go as far as I can see. We should not give up functionality for normalization. Normalization is fine but it is not an end in itself. The appdata table _worked_ the way it was. Sure it was not normalized but that was not a big problem. Adding a new table is not needed.
--
Tony Lambregts