You are here

@John - Development Test Page questions

5 posts / 0 new
Last post
ZachHudock
ZachHudock's picture
Offline
Last seen: 1 year 5 months ago
Developer
Joined: 2006-12-06 18:07
@John - Development Test Page questions

I added the Version column so we can more easily keep track of the version that is packaged. If you don't like this idea or have something else in mind, let me know.

Now for my two questions:

1. Is there a way we can force the rows to stay at single row height and just cause the columns to expand to the proper width? I ask this because it makes things look much cleaner when it all has a uniform look.

2. Is there any chance that we could move all this data into a database at some point? Maintaining a database where all we would have to do is update 1 or 2 columns if an app status or release number changes, and simply add a new row for new apps would be much easier than manually editing the html source for the page, especially if we had a script that could automatically sort the data for us, then display it properly. If we could set up a database, I would not be able to host it, but I would have no problem maintaining it.

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 49 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Version

Version is supposed to be a part of the portable release column as it was for every entry before you'd begun maintaining it. Adding another column increases the chance of it being too wide (just the way tables work in HTML). Please recombine it back into the portable release column. I already switched your longer "Development Test" descriptions to "Dev Test". You could abbreviate them to "DT" if space is at a huge premium since everything in that table is a Development Test.

The description should be no longer than 3 or 4 words. We're not trying to fully describe an app, just classify it. Scite's 'text editor with syntax highlighting' should be just 'text editor', for instance.

When an app is updated, all you need to do usually is alter a version number or two. Editing can be done in place within the web page.

The database won't save that much time and will be a decent amount of work to set up. Unless it is within Drupal's database, we won't be using it. The system is well backed up with good redundancy in terms of the way things are set up. So while it would be easy to throw together a simple PHP/mysql page, it would be much harder to integrate it into the site layout/caching system within Drupal and get it into the backup setups.

Sometimes, the impossible can become possible, if you're awesome!

ZachHudock
ZachHudock's picture
Offline
Last seen: 1 year 5 months ago
Developer
Joined: 2006-12-06 18:07
I still think keeping the

I still think keeping the version number out, and next to the app name would be easier to see, but if you really want it back in the Portable Release column, I'll move that over tonight.

The problem with column width is mostly for the Developer name column. Geoff's name wraps, and before Geoff was added to the list, Patrick's name wrapped. I'll shorten the descriptions in the places that they don't fit.

I really do think maintaining a database would be easier and save time in the long run, but it definitely would take time to set up. Though I'm pretty sure there are scripts available to convert an html table to a database, or at least to an excel sheet, and many database editors can import excel sheets and convert them into the database info.

The developer formerly known as ZGitRDun8705

John T. Haller
John T. Haller's picture
Offline
Last seen: 1 hour 49 min ago
AdminDeveloperModeratorTranslator
Joined: 2005-11-28 22:21
Column

If you really think it would improve visibility, move the whole portable release column next to the app name:

GnuCash - 2.24 PR 1 - accounting software - Shawn Faucher - 2008-03-14

The version and the portable app version together are the version of the package and should be kept together.

As I've said a few times now, we can't go to a database right now. Unless someone knows of a Drupal integrated module that could handle what we want and already works with Drupal 5 and 6, it's a manual HTML editing job. It doesn't matter how easy it is to import into Excel, CVS or mySQL... without an easy way to integrate it into the Drupal system using a module that is supported on an ongoing basis... it's not an option. I don't want some custom hack biting us in the ass when it comes time to do another big CMS upgrade, server move, etc. We're already in that position with a couple modules preventing us from moving to Drupal 6 (and allowing us to have real forum mods, better performance, etc).

Sometimes, the impossible can become possible, if you're awesome!

ZachHudock
ZachHudock's picture
Offline
Last seen: 1 year 5 months ago
Developer
Joined: 2006-12-06 18:07
Alright, i'll move the

Alright, i'll move the Version column back into the Portable Release column.

And for the database, I didn't realize that integration into Drupal would be such an issue, but then i've never worked with Drupal so I don't know how all the modules and things work together. The HTML editing isn't hard, I just thought a database would simplify things.

The developer formerly known as ZGitRDun8705

Log in or register to post comments