Standardization of variable names proposal

[Stalker]

I propose to standardize some common variable names used in templates. I think this would greatly help database maintainability and template interoperability. Additionally, I think it will raise the quality of entries in online app database.

Basically, I think we have all decided to use {version} instead of {vers}, {v} etc. Why not to do the same for other variables ?

 

For example:

{download_url} - contains full URL of application to download. Used only when full URL is dynamically scraped.

{referrer} - contains a referrer URL

{download_filename} - contains file name part of application to download. Used when whole file name is dynamically scraped.

[CybTekSol]

I agree this would make new templates posted here easier to adopt for Ketarin users but we can not force anyone to adopt our proposed standards Stalker. I wish we could, so for now I guess we'll just have to be satisfied with a 'global search & replace' strategy in an xml editor. If we could get everybody on-board... I say go for it! Thoughts everyone?

[andreone]

Maybe by replacing the edit box where you enter the variable name by a combo-box suggesting a list of common user variables, hopefully people would used them instead of typing other names.

[FranciscoR]

My 2 cents for this discussion Stalker... I've managed to simplify my 200 jobs variable's names into the following 8 base names (I prefer shorter names and I append a number to the end if necessary):

• {version} - version
  
• {durl} - complete download url (...sometimes without protocol)
  
• {path} - part or complete path
  
• {filename} - part or complete filename
  
• {redir} - redirection url (complete)
  
• {decode} - function(s) to decode part or a complete url
  
• {regex} - alternative regexes
  
• {value} - anything that doesn't fit the previous 'categories'
  

[CybTekSol]

Very similar to what I am doing FranciscoR. I currently use {download_url} for a full URL with protocol and {truncated_url} for a shortened capture of a portion of a full URL which I am going to shorten to {durl} and {turl} soon for simplicity and standardization of my xml. I also have arrived at the conclusion that shortened variable names are the route to go. There is also the benefit of fewer entries that are displayed in the right-click display of variables in the GUI with standardization. With all of my apps now, I suspect it will take me a while to complete this with all the variations of templates I have used from the beginning. This task will be a little easier when Flo fully implements the search feature. I definitely would prefer that those whom post templates here, post them with some standardization of variables in mind. With this in mind, I propose that others add to this 'variables list' you have started so we can come to a consensus for ALL to use in posting templates in the future. Likewise, if Ketarin users agree/disagree with this goal, please post feedback in this thread.

[Stalker]

Well, personally my programming practice shows that shortening variable names leads to more headache in the end.

[FranciscoR]

Likewise, if Ketarin users agree/disagree with this goal, please post feedback in this thread.

Inc. Flo. =D

[FranciscoR]

{turl} is a good idea and I might as well replace my {path} with it: path is complicated as sometimes path doesn't exist at all, and in my database sometime also includes filename... a truncate url variable is better/more intuitive.

[FranciscoR]

Some stats:

[floele]

Oh well, I guess I'll exclude myself from the variable naming committee

[CybTekSol]

Any other guinea pigs with input? lol

[shawn]

I use the following:

• {swebsite} - website URL (a replacement for the "website" box on the information tab so that I can access it programmatically)
  
• {schangelog} - changelog URL for this program, often needs to be computed based on other input, such as the version or date
  
• {snotes} - long text description of the program or other oddities of it, such as prerequisites or installation instructions
  
• {version} - duh
  
• {sdownload} - if present, the partial or complete URL to download
  
• {filepath} - a fragment used in building {sdownload}
  
• {filestart} - a fragment used in building {sdownload}
  
• {filemiddle} - a fragment used in building {sdownload}
  
• {fileend} - a fragment used in building {sdownload}
  
• {fileext} - a fragment used in building {sdownload}
  
• {filepattern} - a regex pattern used in building {sdownload}
  
• {tag} - (or {sftag}, {mstag} or similar) is a specific key to obtaining the correct URL from a search or index page on the source site.
  
• {aversion} - fragment or 'step' in building the correct {version} string
  
• {bversion} - fragment or 'step' in building the correct {version} string
  
• {cversion} - fragment or 'step' in building the correct {version} string, repeat ad nauseum until the version is formatted correctly, but rarely is it required to iterate this more than 3 or 4 times.
  

[jeff9315]

Being new to Ketarin, I am just starting to write my own app definitions and would really like to see some consistency to make it easier for everyone to adapt other people's work to their own needs and to develop standard templates. Since it's been almost 3 months since the last post on this topic, I hope that this subject gets resurrected and a consensus gets reached.

 

I agree with CyberTekSol that no one should be forced. I also like andreone's suggestion that Flo develop a dropdown box of suggested variable names (and their definitions) which will "encourage" people to use them.

 

CyberTekSol, FranciscoR, and Shawn all seem to prefer using short names while Stalker prefers long variable names.

 

I can certainly live with anything, but I personally prefer long names. I'm a team lead of a few progerammers and I just checked with 5 programmers and 4 of them prefer longer names (FWIW). I'm too new to know which variables are commonly used (or even what some of the ones listed above are used for).

 

Also, would it make sense to have 2 variables that can be used for each item ... a short name and a long name? That eliminates the likelihood of an infinite number of names without forcing anyone to be "left out" because they disagree on the subject of long vs. short.

 

Anyway, since we've got conflicting viewpoints, does anyone have a suggestion as to how to break the logjam and begin adopting some guidelines for people to use? I'm deliberately saying guidelines not standards since we don't want to force anyone to use them, but we do want to encourage people to use them.

 

Thanks ... Jeff

[Omniferum]

In the end the guidelines should be the presented defaults, to help most newbies.

 

As it stands afer making a .db of 150 apps the only real things that need to be put into place is a default variable for the download path and the installation path as they are the ones that i'm sure would be standard for everybody. All things downloaded/installed you'd want in a central location further varied by variables in that variable like {category}