Someone know where i can do pulldowns for the admin-tool for fields with fix values?
Thank you, Robert
Thank you, Robert
Dec 4, 1999, 6:19 AM
Veteran / Moderator (6956 posts)
Dec 4, 1999, 6:19 AM
Post #2 of 6
Views: 2859
I think that's the same -- you just have to set that up in the .def file. Unfortunately, I think any time you regenerate the .def file you'll have to do that.
For whatever reason, Links doesn't automatically recognize the select fields (though it could by looking for a '|' in the default value)...
ReceiveMail => 'Yes,No',
isChanged => 'Yes,No',
isNew => 'Yes,No',
isPopular => 'Yes,No'
I've asked about, and have on my to-do-list if alex doesn't get around to it, a way to change the defaults in the routine that sets them up. I think it's in DBSQL.pm, a block of code that writes out the .def file, but inserts defaults. What that could/should do is go back and check the SQL.mysql or similar file, for the local-defaults and overrides, so that when the .def file is rebuilt, you don't have to make all the changes again. (I'm a fan of keeping things together, so putting all the local 'setup information' in one place, like SQL.mysql is attractive to me... that makes a set-up file with system defaults, and a config file - Links.pm -- for operational settings).
This would work, since the only thing that is _really_ resync'd is the database fields-- it's information that is already in the table, that written to a file so that Links can make some extra assumptions about it, and work a bit faster (such as field numbers).
If when Links is re-writing the file it looks to see if there are overrides for local defaults such as "weight" "not_null" (the two big overrides) and the pattern match, if the table had a field with the same name, the local overrides were used.
When a table is edited in the admin area, the local overrides are updated.
This shouldn't be too hard, since a quick hack would be to make it a function call to set the defaults over what Links just set them to, and in the admin area a function call to write the defaults out. A more elegant solution would be to take each of the links tests, and "if" them so that if a local value exists use it, otherwise use the default..... But the more changes to Links, the more you'll have to do in an update, so the override function call is probably the best short-term solution.
[This message has been edited by pugdog (edited December 04, 1999).]
For whatever reason, Links doesn't automatically recognize the select fields (though it could by looking for a '|' in the default value)...
Code:
%db_select_fields = ( ReceiveMail => 'Yes,No',
isChanged => 'Yes,No',
isNew => 'Yes,No',
isPopular => 'Yes,No'
I've asked about, and have on my to-do-list if alex doesn't get around to it, a way to change the defaults in the routine that sets them up. I think it's in DBSQL.pm, a block of code that writes out the .def file, but inserts defaults. What that could/should do is go back and check the SQL.mysql or similar file, for the local-defaults and overrides, so that when the .def file is rebuilt, you don't have to make all the changes again. (I'm a fan of keeping things together, so putting all the local 'setup information' in one place, like SQL.mysql is attractive to me... that makes a set-up file with system defaults, and a config file - Links.pm -- for operational settings).
This would work, since the only thing that is _really_ resync'd is the database fields-- it's information that is already in the table, that written to a file so that Links can make some extra assumptions about it, and work a bit faster (such as field numbers).
If when Links is re-writing the file it looks to see if there are overrides for local defaults such as "weight" "not_null" (the two big overrides) and the pattern match, if the table had a field with the same name, the local overrides were used.
When a table is edited in the admin area, the local overrides are updated.
This shouldn't be too hard, since a quick hack would be to make it a function call to set the defaults over what Links just set them to, and in the admin area a function call to write the defaults out. A more elegant solution would be to take each of the links tests, and "if" them so that if a local value exists use it, otherwise use the default..... But the more changes to Links, the more you'll have to do in an update, so the override function call is probably the best short-term solution.
[This message has been edited by pugdog (edited December 04, 1999).]
Dec 4, 1999, 6:30 AM
Enthusiast (901 posts)
Dec 4, 1999, 6:30 AM
Post #3 of 6
Views: 2871
Thank you a lot, that works fine.
Updating is really a horrible thing, i work now for the last 5 days at this damned thing :-) and i hate it the same as i love it.
Maybe i could be a good idea, if Alex could do every update twice times. One time normal for users who wants to buy the newest version and for us only a list with changes, so we could do them.
For the next version i will try this for myself, with competing both, the new and old files.
I have so many changes inside, thatīs not funny anymore :-(
Btw: Do you know, how i can give out the last searched terms? Alex wrote inother thread this function is inside, but i dont know where and how to do.
Robert
Updating is really a horrible thing, i work now for the last 5 days at this damned thing :-) and i hate it the same as i love it.
Maybe i could be a good idea, if Alex could do every update twice times. One time normal for users who wants to buy the newest version and for us only a list with changes, so we could do them.
For the next version i will try this for myself, with competing both, the new and old files.
I have so many changes inside, thatīs not funny anymore :-(
Btw: Do you know, how i can give out the last searched terms? Alex wrote inother thread this function is inside, but i dont know where and how to do.
Robert
Dec 4, 1999, 7:02 AM
Veteran / Moderator (6956 posts)
Dec 4, 1999, 7:02 AM
Post #4 of 6
Views: 2859
The update-changed is a big thing, I know how it feels on my end, and what Alex has to do to keep track of it...
As the program matures, it will become more modular. This will make changes and upgrades much easier. This 1.1. upgrade was major because some of the core functioning and databases got changed.
I would like to see each function of the program in a separate module, so that each module can be worked on individually. A small performance hit on a build is a small price to pay for the ability to make upgrades and changes more easily.
That way, searching, editing, building, email, dynamic, users, etc would all be modules that interact through a main shell, and changes to one would not necessarily (except core functioning) mean changes to any other.
To do this when starting out means you don't have a working program for months... but once the program _IS_ out, it bcomes essential to do this. Maintennance is the #1 problem for webmasters and it has to be the #1 situation addressed in programs of this grade.
Many of us have put our businesses and economic futures on this program (and programs like them). It's important to us all to see that the program is modular enough to allow upgrades to functions and routines without affecting the look/feel of the site.
Basically form and function need to be separated to the n-th degree....
As the program matures, it will become more modular. This will make changes and upgrades much easier. This 1.1. upgrade was major because some of the core functioning and databases got changed.
I would like to see each function of the program in a separate module, so that each module can be worked on individually. A small performance hit on a build is a small price to pay for the ability to make upgrades and changes more easily.
That way, searching, editing, building, email, dynamic, users, etc would all be modules that interact through a main shell, and changes to one would not necessarily (except core functioning) mean changes to any other.
To do this when starting out means you don't have a working program for months... but once the program _IS_ out, it bcomes essential to do this. Maintennance is the #1 problem for webmasters and it has to be the #1 situation addressed in programs of this grade.
Many of us have put our businesses and economic futures on this program (and programs like them). It's important to us all to see that the program is modular enough to allow upgrades to functions and routines without affecting the look/feel of the site.
Basically form and function need to be separated to the n-th degree....
Dec 4, 1999, 7:10 AM
Veteran / Moderator (6956 posts)
Dec 4, 1999, 7:10 AM
Post #5 of 6
Views: 2865
I run several sites to make upgrading easier.... I try all the new software on one, move it up to the next level, then sometimes to a 3rd beta, then deploy it.
That way I keep the one site working until I make the upgrade look like it, then stop Apache for a couple of minutes, change a few symlinks, and restart it... the users think the network slowed down, and I've made sure the thing looks the same.
It's a lot of discipline to not make changes to the main site (even templates)... but it pays off.
I ran only one links 2.0 site, and any changes I made had the occasionally nasty effect of killing the site....
I knew nothing about SQL when I started this, so I set up a lot of beta sites, and now have a pretty good system.
I also keep a log of changes I make, and I use ##_## at the begining of all my modifications, so I can quickly find any changes I've made to a file. Fortunately LinkSQL has only a few files (but it also means that even minor changes can ripple through the whole program). On programs that have broken things up into more files, I also rename the original file with an '_' at the end, so when the directory is sorted this extra file shows up next to the modified one, and I know quickly which files were changed and which weren't. Then inside I use the ##_## to find the changes.
A program that's in as much flux as LinkSQL you need to be careful about making too many changes, since the next version might wipe them out... If you are comfortable with the functionality at this level, that's one thing, but if you are looking for new versions, make the changes that are essential only -- and let us and Alex know what they are here in the forum. May be they can be incorporated as options in the next release.
That way I keep the one site working until I make the upgrade look like it, then stop Apache for a couple of minutes, change a few symlinks, and restart it... the users think the network slowed down, and I've made sure the thing looks the same.
It's a lot of discipline to not make changes to the main site (even templates)... but it pays off.
I ran only one links 2.0 site, and any changes I made had the occasionally nasty effect of killing the site....
I knew nothing about SQL when I started this, so I set up a lot of beta sites, and now have a pretty good system.
I also keep a log of changes I make, and I use ##_## at the begining of all my modifications, so I can quickly find any changes I've made to a file. Fortunately LinkSQL has only a few files (but it also means that even minor changes can ripple through the whole program). On programs that have broken things up into more files, I also rename the original file with an '_' at the end, so when the directory is sorted this extra file shows up next to the modified one, and I know quickly which files were changed and which weren't. Then inside I use the ##_## to find the changes.
A program that's in as much flux as LinkSQL you need to be careful about making too many changes, since the next version might wipe them out... If you are comfortable with the functionality at this level, that's one thing, but if you are looking for new versions, make the changes that are essential only -- and let us and Alex know what they are here in the forum. May be they can be incorporated as options in the next release.