Menu
▾
▴
Re: [Tsheetx-developers] Who's actively working on the TSNG system?
|
From: Scott M. <sco...@gm...> - 2011-02-11 16:56:10
|
Some actual code from common.inc file (I'm currently developing off trunk,
but I want to check out the 2.0-demo thing too):
class ConfigInformation {
var $Info;
var $Html;
function getCfgInfo() {
require("table_names.inc");
require("database_credentials.inc");
list($qh, $num) = dbQuery("SELECT * FROM $NEW_CONFIG_TABLE where
name not like '%LDAP%' and name not like 'HTML%'");
while ($data = dbResult($qh)) {
$this->Info[$data['name']]=$data[$data['type']];
}
list($qh, $num) = dbQuery("SELECT * FROM $NEW_CONFIG_TABLE where
name like 'HTML%'");
while ($data = dbResult($qh)) {
$this->Html[$data['name']]=$data[$data['type']];
}
}
}
$Cfg = new ConfigInformation;
$Cfg->getCfgInfo();
function getWeekStartDay() {
global $Cfg;
return $Cfg->Info['weekstartday'];
}
function getProjectItemsPerPage() {
global $Cfg;
return $Cfg->Info['project_items_per_page'];
}
function getTaskItemsPerPage() {
global $Cfg;
return $Cfg->Info['task_items_per_page'];
}
function getTimeFormat() {
global $Cfg;
return $Cfg->Info['timeformat'];
}
----------------------------------------
On a side note, since the config stuff is loaded in common.inc and thus
available to all the other code, all these "get" functions can now be
eliminated. But, it works for now...
I did rename the html configuration entites to start with "HTML" instead of
ending with "html". (ie footerhtml was changed to HTMLfooter, etc)
Oh, and the LDAP stuff is loaded similarly in the
class.AuthenticationManager.php file...
-Scott
On Fri, Feb 11, 2011 at 4:19 PM, Mark Wrightson <ma...@rw...>wrote:
> I recently came up with a nice OO way to handle exactly this but without
> using a db for the config tables. ( there is no reason why a db couldn't be
> used though.)
>
> If you have a config class that contains the default config of the system.
>
> To sumarise:
> config.factory.class.php:
>
> class ConfigFactory{
>
> protected static itemOne = 'something';
>
> public static function initialise(){}
>
> public static getItemOne(){
> return self::itemOne;
> }
>
> ....more config params here....
>
> }
>
> config.class.php:
>
> class Config extends ConfigFactory{
>
> /**
> * initialise the config class
> */
> public static function initialise(){
>
> if(file_exists('include/config/config.php')){
> include('include/config/config.php');
> }
>
> parent::initialise();
> }
>
>
> }
>
>
> and finally in include/config/config.php the actual userdefined config:
>
> parent::$itemOne = "somethingelse";
>
> i think this would be slightly better than an ini file albeit of similar
> concept.
>
> Using this type of topology database credentials could be stored in a file
> and a database hook to grab other config data from the database in the
> config::initialise() function.
>
> This ensures default values are always present and then overwritten with
> specific config parameters for the users setup.
>
> so in the application code access would be as follows:
> Config::getItemOne();
>
>
> However the final solution is done, the data from the config table should
> be loaded into some from of class structure. This minimises the potential
> for coding errors. :)
>
> Thoughts please? - (this is an extension to the config setup currently in
> my and peters branch.)
>
>
>
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 11/02/2011 15:56, Scott Miller wrote:
>
> Yes, I've given some thought to default entries, as well as the potential
> issues when items that are supposed to exist don't.
>
> It could be handled by putting the defaults into an .ini type file, and we
> could just load the defaults from the ini file before we then over write
> them with info from the database, that would help ensure that missing
> configuration items from the database wouldn't necessarily break the
> application.
>
> I'm not convinced this is a good idea because that would mean the
> application would have to read configuration data from two places with every
> page load. And if some admin is dumb enough to delete configuration stuff
> out of the database, they deserve to have the app break on them :-)
>
> But, putting that info in an .ini file, we could then still have the
> "revert to default" buttons on the configuration page, and if needed, we
> could then load that info from the .ini file. Or we could have default
> entries in the database itself. I'm kinda leaning toward the ini file
> though.
>
> -Scott
>
> On Fri, Feb 11, 2011 at 3:22 PM, David Thompson <
> tom...@us...> wrote:
>
>> Scott - I like your idea with the generic config table, but have you
>> considered defaults?
>> Mark, Peter - I am impressed by your progress, well done, a rework like
>> this will give the "next gen" feel that we need. And don't worry about
>> rewriting 90% of the code, go ahead if necessary.
>>
>> I am not actively working on anything (well, related to TSNG I mean), but
>> I keep an eye on what is going on. There are a number of branches where
>> changes have been made that should really be completed and merged into the
>> trunk, or merged into txsheet-2.0 and further developed there. Can anyone
>> claim responsibility for the changes?
>>
>> Cheers
>> tommo
>>
>> ------------------------------
>> Date: Fri, 11 Feb 2011 10:21:53 +1100
>> From: pal...@gm...
>> To: tsh...@li...
>> Subject: [Tsheetx-developers] [SPAM] Re: Who's actively working on the
>> TSNG system?
>>
>>
>> Scott,
>> you asked if I have done more work on the 'management approval' area. The
>> answer is no. I have incorporated the management approval process into
>> branches/txsheet-2.0-demo but nothing further has been added. I have spent
>> most of my development time on the changes made in conjunction with Mark.
>>
>> Peter
>>
>> On 11/02/11 05:00, Scott Miller wrote:
>>
>> Oh, sorry, I didn't answer what the new config stuff would look like:
>> rather than having each configuration item have it's own column in the
>> database, I'm making the table generic, so we can easily add whatever we
>> want to the configuration table. So it currently looks like this:
>>
>> columns are: name | type | INT | FLOAT | TEXT
>> INT and FLOAT are their namesake types, name is varchar(35), type is an
>> enum ('INT','FLOAT','TEXT') defaulting to text, and TEXT is of type
>> MEDIUMTEXT (which was done to make sure there was enough space for the HTML
>> entities, which with your work, would mean we could probably safely make
>> that of type TEXT instead)
>>
>> An example select from the database looks like this:
>> mysql> select * from tstrunk_new_config where name not like "HTML%";
>>
>> +------------------------+------+------+-------+------------------------------+
>> | name | type | INT | FLOAT |
>> TEXT |
>>
>> +------------------------+------+------+-------+------------------------------+
>> | version | TEXT | NULL | NULL |
>> 1.6.0 |
>> | locale | TEXT | NULL | NULL
>> | |
>> | timezone | TEXT | NULL | NULL |
>> US/Central |
>> | timeformat | INT | 12 | NULL |
>> NULL |
>> | weekstartday | INT | 1 | NULL |
>> NULL |
>> | startPage | TEXT | NULL | NULL |
>> monthly |
>> | project_items_per_page | INT | 20 | NULL |
>> NULL |
>> | task_items_per_page | INT | 20 | NULL |
>> NULL |
>> | simpleTimesheetLayout | TEXT | NULL | NULL | small work description
>> field |
>> | useLDAP | INT | 0 | NULL |
>> NULL |
>> | LDAPurl | TEXT | NULL | NULL | ldap://watson:389
>> |
>> | LDAPBaseDN | TEXT | NULL | NULL |
>> dc=watson |
>> | LDAPUsernameAttribute | TEXT | NULL | NULL |
>> cn |
>> | LDAPSearchScope | TEXT | NULL | NULL |
>> base |
>> | LDAPFilter | TEXT | NULL | NULL
>> | |
>> | LDAPProtocolVersion | TEXT | NULL | NULL |
>> 3 |
>> | LDAPBindUsername | TEXT | NULL | NULL
>> | |
>> | LDAPBindPassword | TEXT | NULL | NULL
>> | |
>> | LDAPReferrals | INT | 0 | NULL |
>> NULL |
>> | LDAPFallback | INT | 0 | NULL |
>> NULL |
>>
>> +------------------------+------+------+-------+------------------------------+
>>
>> Oh, you can also see above, I've replaced several of the old LDAP items
>> with an LDAPurl item instead...
>>
>> -Scott
>>
>> On Thu, Feb 10, 2011 at 5:42 PM, Scott Miller <sco...@gm...>wrote:
>>
>> Good to hear about the HTML stuff in the database now being ignored, and
>> moving to some sort of template system; I think that will be much nicer than
>> having that stuff in the database. I would certainly be interested in
>> reading what peter has...
>>
>> There are many suggested improvements that are impossible without having
>> per user configuration options. Things like having each user able to create
>> a default set of time entries per week, eventually allowing the user to set
>> their own timezone (once we can store times as UTC). Once we have this
>> ability a whole myriad of new possibilities are opened up to further improve
>> the user experience.
>>
>> Peter Lazarus, are you still working on improving the "managment approval"
>> area?
>>
>> -Scott
>>
>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen. Find and fix more
>> than 250 security defects in the development cycle. Locate bottlenecks in
>> serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>>
>> _______________________________________________ Tsheetx-developers mailing
>> list Tsh...@li...
>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>
>>
>> ------------------------------------------------------------------------------
>> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
>> Pinpoint memory and threading errors before they happen.
>> Find and fix more than 250 security defects in the development cycle.
>> Locate bottlenecks in serial and parallel code that limit performance.
>> http://p.sf.net/sfu/intel-dev2devfeb
>> _______________________________________________
>> Tsheetx-developers mailing list
>> Tsh...@li...
>> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>>
>>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
>
>
> _______________________________________________
> Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tsheetx-developers mailing list
> Tsh...@li...
> https://lists.sourceforge.net/lists/listinfo/tsheetx-developers
>
>
|
