appdb/ ./appview.php ./screenshots.php admin/a ...

[Tony Lambregts]

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:
> 1) readd appid in appdata table: bad as it is strange to have columns
> with appid=0 for screenshots and versionid=0 for URLs
> 
> OR
> 
> 2) 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
> 
> 3) 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