Menu
▾
▴
tsheetx-developers — Timesheet Next Gen - Developer's mailing list
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(1) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
|
Apr
(6) |
May
(10) |
Jun
(1) |
Jul
(3) |
Aug
(19) |
Sep
(52) |
Oct
(5) |
Nov
(15) |
Dec
|
| 2011 |
Jan
|
Feb
(65) |
Mar
(53) |
Apr
(55) |
May
(37) |
Jun
|
Jul
(1) |
Aug
(17) |
Sep
(28) |
Oct
(7) |
Nov
|
Dec
|
| 2012 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
|
May
(4) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: Mark W. <ma...@rw...> - 2011-02-20 18:40:03
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
I dont particularly think svn revision numbers are a good way of
controlling the actual version of the application. because a single
change to the trunk should not constitute a requirement to run
update scripts to modify the database etc.<br>
<br>
Maybe it should be just a text field? it doesn't really make much
difference though does it? I'm thinking that in future we may end
up storing serialised objects in the database and it may quite
easily get larger than 255 chars. Or should we just use tinytext?
I personally have no preference. 255 chars would probably be fine.<br>
<br>
<br>
The way the installer works is:<br>
<br>
site.class.php:<br>
<br>
1. init config<br>
2. connect to database<br>
If the connection to the db fails then check the config::isInstalled
variable.<br>
If it is installed then show an error page, if it is not installed
goto the page install.php?page=install<br>
<br>
Assuming the site is installed and the database connects ok
Config::getDbConfig() is called to grab the data out of the new
config database table.<br>
Inside this function it the calls runVersionCheck() which compares
the version grabbed from the database to the value of
ConfigFactory::$version<br>
If the versions do not match then goto the page
install.php?page=upgrade<br>
<br>
By redirecting to install.php, the usual path of the site loading
through index.php doesn't apply. the install.php file loads the
install.site.class.php instead of site.class.php<br>
which is slightly different.<br>
<br>
Cheers<br>
<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 18/02/2011 23:32, Scott Miller wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Mark, can you give me a brief outline of how the
system figures out if it needs to upgrade itself? I think I'm
done with the sql stuff, but need to test it, and want to know
what calls what.<br>
<br>
I'd start figuring it out on my own, but I need to head out for
the weekend myself, hopefully you'll have responded by the time I
get in Morning :-)<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at 8:16 PM, Scott
Miller <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Oh, I'd forgotten another issue I wanted to discuss. Do you
really think that it's necessary to have the configuration
table use a long text field? Honestly, I'm thinking a tiny
text field (256 characters) might be good enough, especially
since we're planning to not have HTML info in this new
configuration table. However, as soon as we agree to cover
ourselves for the need for longer fields with text or medium
text, we may as well go with long text. The same amount of
storage is actually used (the actual size of the data) with
any of those text types.<br>
<br>
So, is 256 characters enough for a limit in our new
configuration table? The longest field needed in the new
configuration table so far takes up less than 30 characters.<br>
<font color="#888888"><br>
-Scott</font>
<div>
<div class="h5"><br>
<br>
<div class="gmail_quote">
On Fri, Feb 18, 2011 at 8:04 PM, Scott Miller <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Yes, using svn for version numbers would be a good
idea, I remember doing some research on this, but I've
never actually done it.<br>
<br>
I like the ideas behind how to update/upgrade in the
future. But for now, what I think I'm going to try to
do is take the old way of having an <a
moz-do-not-send="true" href="http://sql.in"
target="_blank">sql.in</a> file for our next version
(1.5.3), and add additional logic behind that to
convert the existing config table and turn it into the
new configuration table, then when the "real" sql file
is run against the database, that work is done
correctly. So, from that, I think the added logic
needed for the version 1.5.3 upgrade stuff will
actually get placed in the install script itself...<br>
<font color="#888888">
<br>
-Scott</font>
<div>
<div><br>
<br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at
4:08 PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:
0pt 0pt 0pt 0.8ex; border-left: 1px solid
rgb(204, 204, 204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Hi
Scott, <br>
<br>
The way you would 'auto increment' the
version would be to use the svn feature that
can insert version numbers into a specific
place in a file upon commit. But i think
auto increment is a bad idea.<br>
<br>
I am going to be away all weekend so won't
be able to do any work. I have been
thinking about how to do upgrades a bit and
what I was thinking was a bit like having
1.5.3.sql also have a 1.5.3.php file with a
string of instructions that can be run.<br>
<br>
How about having a folder: 'install/version'
?<br>
For now maybe place your cvt-cfg.php in
install/version as '1.5.4.php' or whatever
the next version number is? and then modify
the text in the upgrade.php file to indicate
that this file needs to be run?<br>
<br>
For future work: to form a structure for the
upgrade.php files I think we should have
something like:<br>
<br>
class upgrade_1_5_4 extends Upgrade{<br>
.... some stuff in here<br>
}<br>
<br>
abstract class Upgrade{<br>
<br>
abstract public function __construct();<br>
abstract public function functionName();<br>
}<br>
<br>
If the upgrade php files have a common
structure and known function names then it
would mean the upgrade script could be
written quite robustly.
<div><br>
<br>
Regards<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 18/02/2011 15:41, Scott Miller
wrote:
<blockquote type="cite">Mark,<br>
<br>
Well, what I have is a php script that
takes the LDAP and other misc stuff
from the existing config table and
inserts those entries into the new
configuration table. So, it is also
ignoring all the html and acl
entries. It changes several LDAP
entries and creates the new LDAPurl
item, and modifies the version to be
1.5.3. I've thought about trying to
figure out how to "auto increment" the
version, but I'm thinking we actually
don't want that to happen.<br>
<br>
So, this is in a script currently
called cvt-cfg.php in the install
directory. I'm just now starting to
think about how and where to run this
script... should it be imbedded as
part of the upgrade script(s)? Or
should I just check this new file in
for now?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Thu, Feb
17, 2011 at 10:25 PM, Mark Wrightson
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div text="#000000"
bgcolor="#ffffff"> Hi Scott, <br>
<br>
Yeah remove the id column. The
option name should really be the
unique key anyway.<br>
<br>
If you:<br>
<br>
1.create an sql file with the
change in
install/sql/{version_number}.sql<br>
2. increment the version in the
config table, and put that in
the sql file from above.<br>
3. increment the version value
in config.factory.class.php
(such that this value will match
the value entered in the sql
above)<br>
it will force the upgrade script
to appear and inform developers
that there is a change to the
database :)<br>
<br>
I think for the time being we
should sideline the
authorisation changes as they do
work, and concentrate on
finishing the css changes that
are still on going. Some user
testing wouldn't go a miss
either.<br>
<br>
Regards<br>
<font color="#888888"> Mark
Wrightson</font>
<div><br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 17/02/2011 21:52,
Scott Miller wrote:
<blockquote type="cite">Hey
Mark,<br>
<br>
I've actually had time to
do some stuff with it
today, yesterday ended up
being filled with work. <br>
<br>
Can I propose that we
remove the ID column from
the new configuration
table? I can't see that
being useful in the
future...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On
Thu, Feb 17, 2011 at
9:06 AM, Mark Wrightson
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin: 0pt 0pt
0pt 0.8ex;
border-left: 1px solid
rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000"
bgcolor="#ffffff">
Ah right ok. It may
take a while to
rewrite the install
script. I need to
get a structure on
paper first i think.<br>
<br>
I'll have a think
about the excel
stuff. One of the
feature requests was
to output to csv
also.
<div><br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On
16/02/2011
16:41, Scott
Miller wrote:
<blockquote
type="cite">Yes,
the installer
stuff is what
I was talking
about. If you
can clean it
up, great, I
don't have a
good vision
for how that
would look, so
the best I can
do is take
what we've got
and continue
to add in our
new changes.
I should be
able to fix
bugs in the
current system
if you can
find them, but
again, if you
can re-write
it so that
it's not
nearly as
complicated
and works
better, I'd
say that would
be a good
thing.<br>
<br>
As for the
excel
exporting,
there was a
really old
mechanism that
I could never
get to work,
and someone
else had
created and
submitted a
different
report with a
different
mechanism that
worked for me,
so I just took
what worked
and applied it
to the rest of
the reports.
The way it
works, we
would have had
a ton of
"replicated
code" if we
attempted to
have exporting
call a
different
script than
the one that
created the
report for the
screen, and
that would
have been even
worse to
maintain.
Again, if you
have a better
way to do it,
great.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Wed, Feb 16,
2011 at 4:28
PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;">
<div
text="#000000"
bgcolor="#ffffff"> Hi Scott, <br>
<br>
I don't
understand
what you mean?<br>
---
<div><br>
"Yes, it took
me quite a
while to wrap
my brain
around what
all was
happening.
The same
script is
called
repeatedly for
each step of
the process,
so figuring
out how and
where to add
things was
interesting."<br>
</div>
---<br>
<br>
Ohhh - do you
mean how the
original
install script
worked was
interesting?
If that is
what you mean
then yes i do
agree. I'm
looking to
take
inspiration
from the old
install script
and write a
new object
orientated
version. The
main grief I
had with the
old installer
was that if
you asked it
to create the
database for
you, it
sometimes
messed things
up good n
proper and got
itself all
confused. In
the end I went
through
phpmyadmin,
reversed what
it had done
and setup the
database
manually
through that.<br>
<br>
Yes completing
the transition
from the old
config to the
new config
would
definitely be
good :)<br>
Other things
that need
looking at are
going through
and just
seeing if the
timesheet app
works because
very little
has been
tested since
it was
rewritten.<br>
Oh also the
excel export
features on a
couple of
pages really
have been
hacked into
tsng. the
view and
export options
should be
totally
separate pages
all together
to tidy up the
code instead
of being
munged all
into one file.<br>
<br>
Regards
<div><br>
Mark<br>
<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On
16/02/2011
16:06, Scott
Miller wrote:
<blockquote
type="cite">Yes,
it took me
quite a while
to wrap my
brain around
what all was
happening.
The same
script is
called
repeatedly for
each step of
the process,
so figuring
out how and
where to add
things was
interesting.<br>
<br>
I'll help get
that fixed up
if you want,
but today,
I'll attempt
to work on
taking data
from the
existing
config
database and
populating our
new
configuration
table with
that stuff.
And if I get
that done,
I'll then
start working
on getting
that config
stuff loaded
with the
config
classes...<br>
<br>
Maybe tomorrow
I'll do
something
about the
install/upgrade
stuff...<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Wed, Feb 16,
2011 at 12:49
AM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;">
<div
text="#000000"
bgcolor="#ffffff"> Hi Scott, Ok I will commit everything that I have
done.<br>
This will then
put you in a
good position
to complete
the transfer
from the old
config table
to the new
one.<br>
<br>
I am just
adding in some
warnings to
the install
script to say
that it isn't
complete and
how to do a
manual update.<br>
<br>
It is now
00:47 here. :)
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On
15/02/2011
23:47, Scott
Miller wrote:
<blockquote
type="cite">well,
considering
it's in the
demo branch,
I'd say commit
it now. Might
quickly
document that
the install
script isn't
working yet...<br>
<br>
I'd like to
help you, but
I'm a bit wary
about what
part to change
as much as you
changed within
the past day
or so :-)<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Tue, Feb 15,
2011 at 11:44
PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;">
<div
text="#000000"
bgcolor="#ffffff"> I think we should skip 1.6 and go straight to 2.0 - a
major update
requires a
major release
number. :)<br>
<br>
Yes, I was the
one suggesting
removing
everything
except the
string field
in the config
table.<br>
<br>
This install
script stuff
is quite
complex, i'm
now at the
point where
the site will
automatically
detect that
the database
version is no
longer<br>
in sync with
the codebase
version and
will start an
upgrade
process. I've
also got the
hooks in place
to detect a
new
installation.<br>
The new
install script
won't need to
be deleted and
it uses the
templating
system so can
use a theme to
make it look
really smart
:)<br>
<br>
When do you
think I should
start
committing it
back up? - it
is currently
at a stage
where it tells
the user what
needs to
happen, just
doesn't
actually
perform the
install
/upgrade. I
think the
actual install
script bit
could take a
while to
write. I
could commit
it now, it
would just
mean that only
a manual
install would
be possible.
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On
15/02/2011
22:59, Scott
Miller wrote:
<blockquote
type="cite">I
think with all
the changes
we're making
with this
version, it
will be
version 1.6
:-)<br>
I don't
remember if
you were the
one to suggest
removing all
but the string
variable in
the new config
table, I'd
thought about
that myself,
so, that's
probably a
good direction
to head.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Tue, Feb 15,
2011 at 5:16
PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;"> Hi
Scott,<br>
<br>
I thought I
would drop you
an email to
ask what
position you
were in
regards to
updating the
config
database
table?<br>
last night in
my work to
update the
installer I
had to write a
small amount
of code along
the lines of
what you are
working on.<br>
<br>
I made the
following
additions to
config.class.php<br>
<br>
<br>
One new
function:<br>
<br>
public
static
function
getDbConfig(){<br>
<br>
$q =
"SELECT * FROM
".tbl::getNewConfigTable();<br>
<br>
$data =
Site::getDatabase()->sql($q,true,
MySQLDB::TYPE_OBJECT);<br>
if($data ==
MySQLDB::SQL_EMPTY
|| $data ==
MySQLDB::SQL_ERROR)return;<br>
<br>
foreach($data
as $obj){<br>
<br>
...
[truncated message content] |
|
From: Scott M. <sco...@gm...> - 2011-02-18 23:32:35
|
Mark, can you give me a brief outline of how the system figures out if it
needs to upgrade itself? I think I'm done with the sql stuff, but need to
test it, and want to know what calls what.
I'd start figuring it out on my own, but I need to head out for the weekend
myself, hopefully you'll have responded by the time I get in Morning :-)
-Scott
On Fri, Feb 18, 2011 at 8:16 PM, Scott Miller <sco...@gm...>wrote:
> Oh, I'd forgotten another issue I wanted to discuss. Do you really think
> that it's necessary to have the configuration table use a long text field?
> Honestly, I'm thinking a tiny text field (256 characters) might be good
> enough, especially since we're planning to not have HTML info in this new
> configuration table. However, as soon as we agree to cover ourselves for
> the need for longer fields with text or medium text, we may as well go with
> long text. The same amount of storage is actually used (the actual size of
> the data) with any of those text types.
>
> So, is 256 characters enough for a limit in our new configuration table?
> The longest field needed in the new configuration table so far takes up less
> than 30 characters.
>
> -Scott
>
>
> On Fri, Feb 18, 2011 at 8:04 PM, Scott Miller <sco...@gm...>wrote:
>
>> Yes, using svn for version numbers would be a good idea, I remember doing
>> some research on this, but I've never actually done it.
>>
>> I like the ideas behind how to update/upgrade in the future. But for now,
>> what I think I'm going to try to do is take the old way of having an
>> sql.in file for our next version (1.5.3), and add additional logic behind
>> that to convert the existing config table and turn it into the new
>> configuration table, then when the "real" sql file is run against the
>> database, that work is done correctly. So, from that, I think the added
>> logic needed for the version 1.5.3 upgrade stuff will actually get placed in
>> the install script itself...
>>
>> -Scott
>>
>>
>> On Fri, Feb 18, 2011 at 4:08 PM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>> Hi Scott,
>>>
>>> The way you would 'auto increment' the version would be to use the svn
>>> feature that can insert version numbers into a specific place in a file upon
>>> commit. But i think auto increment is a bad idea.
>>>
>>> I am going to be away all weekend so won't be able to do any work. I
>>> have been thinking about how to do upgrades a bit and what I was thinking
>>> was a bit like having 1.5.3.sql also have a 1.5.3.php file with a string of
>>> instructions that can be run.
>>>
>>> How about having a folder: 'install/version' ?
>>> For now maybe place your cvt-cfg.php in install/version as '1.5.4.php' or
>>> whatever the next version number is? and then modify the text in the
>>> upgrade.php file to indicate that this file needs to be run?
>>>
>>> For future work: to form a structure for the upgrade.php files I think we
>>> should have something like:
>>>
>>> class upgrade_1_5_4 extends Upgrade{
>>> .... some stuff in here
>>> }
>>>
>>> abstract class Upgrade{
>>>
>>> abstract public function __construct();
>>> abstract public function functionName();
>>> }
>>>
>>> If the upgrade php files have a common structure and known function names
>>> then it would mean the upgrade script could be written quite robustly.
>>>
>>>
>>> Regards
>>> Mark
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 18/02/2011 15:41, Scott Miller wrote:
>>>
>>> Mark,
>>>
>>> Well, what I have is a php script that takes the LDAP and other misc
>>> stuff from the existing config table and inserts those entries into the new
>>> configuration table. So, it is also ignoring all the html and acl entries.
>>> It changes several LDAP entries and creates the new LDAPurl item, and
>>> modifies the version to be 1.5.3. I've thought about trying to figure out
>>> how to "auto increment" the version, but I'm thinking we actually don't want
>>> that to happen.
>>>
>>> So, this is in a script currently called cvt-cfg.php in the install
>>> directory. I'm just now starting to think about how and where to run this
>>> script... should it be imbedded as part of the upgrade script(s)? Or
>>> should I just check this new file in for now?
>>>
>>> -Scott
>>>
>>> On Thu, Feb 17, 2011 at 10:25 PM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> Yeah remove the id column. The option name should really be the unique
>>>> key anyway.
>>>>
>>>> If you:
>>>>
>>>> 1.create an sql file with the change in install/sql/{version_number}.sql
>>>> 2. increment the version in the config table, and put that in the sql
>>>> file from above.
>>>> 3. increment the version value in config.factory.class.php (such that
>>>> this value will match the value entered in the sql above)
>>>> it will force the upgrade script to appear and inform developers that
>>>> there is a change to the database :)
>>>>
>>>> I think for the time being we should sideline the authorisation changes
>>>> as they do work, and concentrate on finishing the css changes that are still
>>>> on going. Some user testing wouldn't go a miss either.
>>>>
>>>> Regards
>>>> Mark Wrightson
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob: 07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>> On 17/02/2011 21:52, Scott Miller wrote:
>>>>
>>>> Hey Mark,
>>>>
>>>> I've actually had time to do some stuff with it today, yesterday ended
>>>> up being filled with work.
>>>>
>>>> Can I propose that we remove the ID column from the new configuration
>>>> table? I can't see that being useful in the future...
>>>>
>>>> -Scott
>>>>
>>>> On Thu, Feb 17, 2011 at 9:06 AM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>> Ah right ok. It may take a while to rewrite the install script. I
>>>>> need to get a structure on paper first i think.
>>>>>
>>>>> I'll have a think about the excel stuff. One of the feature requests
>>>>> was to output to csv also.
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob: 07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>> On 16/02/2011 16:41, Scott Miller wrote:
>>>>>
>>>>> Yes, the installer stuff is what I was talking about. If you can clean
>>>>> it up, great, I don't have a good vision for how that would look, so the
>>>>> best I can do is take what we've got and continue to add in our new
>>>>> changes. I should be able to fix bugs in the current system if you can find
>>>>> them, but again, if you can re-write it so that it's not nearly as
>>>>> complicated and works better, I'd say that would be a good thing.
>>>>>
>>>>> As for the excel exporting, there was a really old mechanism that I
>>>>> could never get to work, and someone else had created and submitted a
>>>>> different report with a different mechanism that worked for me, so I just
>>>>> took what worked and applied it to the rest of the reports. The way it
>>>>> works, we would have had a ton of "replicated code" if we attempted to have
>>>>> exporting call a different script than the one that created the report for
>>>>> the screen, and that would have been even worse to maintain. Again, if you
>>>>> have a better way to do it, great.
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Wed, Feb 16, 2011 at 4:28 PM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>> Hi Scott,
>>>>>>
>>>>>> I don't understand what you mean?
>>>>>> ---
>>>>>>
>>>>>> "Yes, it took me quite a while to wrap my brain around what all was
>>>>>> happening. The same script is called repeatedly for each step of the
>>>>>> process, so figuring out how and where to add things was interesting."
>>>>>> ---
>>>>>>
>>>>>> Ohhh - do you mean how the original install script worked was
>>>>>> interesting? If that is what you mean then yes i do agree. I'm looking to
>>>>>> take inspiration from the old install script and write a new object
>>>>>> orientated version. The main grief I had with the old installer was that if
>>>>>> you asked it to create the database for you, it sometimes messed things up
>>>>>> good n proper and got itself all confused. In the end I went through
>>>>>> phpmyadmin, reversed what it had done and setup the database manually
>>>>>> through that.
>>>>>>
>>>>>> Yes completing the transition from the old config to the new config
>>>>>> would definitely be good :)
>>>>>> Other things that need looking at are going through and just seeing if
>>>>>> the timesheet app works because very little has been tested since it was
>>>>>> rewritten.
>>>>>> Oh also the excel export features on a couple of pages really have
>>>>>> been hacked into tsng. the view and export options should be totally
>>>>>> separate pages all together to tidy up the code instead of being munged all
>>>>>> into one file.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob: 07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>> On 16/02/2011 16:06, Scott Miller wrote:
>>>>>>
>>>>>> Yes, it took me quite a while to wrap my brain around what all was
>>>>>> happening. The same script is called repeatedly for each step of the
>>>>>> process, so figuring out how and where to add things was interesting.
>>>>>>
>>>>>> I'll help get that fixed up if you want, but today, I'll attempt to
>>>>>> work on taking data from the existing config database and populating our new
>>>>>> configuration table with that stuff. And if I get that done, I'll then
>>>>>> start working on getting that config stuff loaded with the config classes...
>>>>>>
>>>>>> Maybe tomorrow I'll do something about the install/upgrade stuff...
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> On Wed, Feb 16, 2011 at 12:49 AM, Mark Wrightson <
>>>>>> ma...@rw...> wrote:
>>>>>>
>>>>>>> Hi Scott, Ok I will commit everything that I have done.
>>>>>>> This will then put you in a good position to complete the transfer
>>>>>>> from the old config table to the new one.
>>>>>>>
>>>>>>> I am just adding in some warnings to the install script to say that
>>>>>>> it isn't complete and how to do a manual update.
>>>>>>>
>>>>>>> It is now 00:47 here. :)
>>>>>>>
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> _____________________________________________
>>>>>>>
>>>>>>> Mob: 07725 695178
>>>>>>> Email: ma...@rw...
>>>>>>>
>>>>>>>
>>>>>>> On 15/02/2011 23:47, Scott Miller wrote:
>>>>>>>
>>>>>>> well, considering it's in the demo branch, I'd say commit it now.
>>>>>>> Might quickly document that the install script isn't working yet...
>>>>>>>
>>>>>>> I'd like to help you, but I'm a bit wary about what part to change as
>>>>>>> much as you changed within the past day or so :-)
>>>>>>>
>>>>>>> -Scott
>>>>>>>
>>>>>>> On Tue, Feb 15, 2011 at 11:44 PM, Mark Wrightson <
>>>>>>> ma...@rw...> wrote:
>>>>>>>
>>>>>>>> I think we should skip 1.6 and go straight to 2.0 - a major update
>>>>>>>> requires a major release number. :)
>>>>>>>>
>>>>>>>> Yes, I was the one suggesting removing everything except the string
>>>>>>>> field in the config table.
>>>>>>>>
>>>>>>>> This install script stuff is quite complex, i'm now at the point
>>>>>>>> where the site will automatically detect that the database version is no
>>>>>>>> longer
>>>>>>>> in sync with the codebase version and will start an upgrade
>>>>>>>> process. I've also got the hooks in place to detect a new installation.
>>>>>>>> The new install script won't need to be deleted and it uses the
>>>>>>>> templating system so can use a theme to make it look really smart :)
>>>>>>>>
>>>>>>>> When do you think I should start committing it back up? - it is
>>>>>>>> currently at a stage where it tells the user what needs to happen, just
>>>>>>>> doesn't actually perform the install /upgrade. I think the actual install
>>>>>>>> script bit could take a while to write. I could commit it now, it would
>>>>>>>> just mean that only a manual install would be possible.
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> _____________________________________________
>>>>>>>>
>>>>>>>> Mob: 07725 695178
>>>>>>>> Email: ma...@rw...
>>>>>>>>
>>>>>>>>
>>>>>>>> On 15/02/2011 22:59, Scott Miller wrote:
>>>>>>>>
>>>>>>>> I think with all the changes we're making with this version, it will
>>>>>>>> be version 1.6 :-)
>>>>>>>> I don't remember if you were the one to suggest removing all but the
>>>>>>>> string variable in the new config table, I'd thought about that myself, so,
>>>>>>>> that's probably a good direction to head.
>>>>>>>>
>>>>>>>> -Scott
>>>>>>>>
>>>>>>>> On Tue, Feb 15, 2011 at 5:16 PM, Mark Wrightson <
>>>>>>>> ma...@rw...> wrote:
>>>>>>>>
>>>>>>>>> Hi Scott,
>>>>>>>>>
>>>>>>>>> I thought I would drop you an email to ask what position you were
>>>>>>>>> in regards to updating the config database table?
>>>>>>>>> last night in my work to update the installer I had to write a
>>>>>>>>> small amount of code along the lines of what you are working on.
>>>>>>>>>
>>>>>>>>> I made the following additions to config.class.php
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> One new function:
>>>>>>>>>
>>>>>>>>> public static function getDbConfig(){
>>>>>>>>>
>>>>>>>>> $q = "SELECT * FROM ".tbl::getNewConfigTable();
>>>>>>>>>
>>>>>>>>> $data = Site::getDatabase()->sql($q,true,
>>>>>>>>> MySQLDB::TYPE_OBJECT);
>>>>>>>>> if($data == MySQLDB::SQL_EMPTY || $data ==
>>>>>>>>> MySQLDB::SQL_ERROR)return;
>>>>>>>>>
>>>>>>>>> foreach($data as $obj){
>>>>>>>>>
>>>>>>>>> if($obj->name == 'version'){
>>>>>>>>> parent::$databaseVersion = $obj->value;
>>>>>>>>> self::runVersionCheck();
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> //more config variables to be stored into the
>>>>>>>>> //config class or config.factory.class
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> and in /index.php
>>>>>>>>>
>>>>>>>>> Config::getDbConfig(); on the line after the database has been
>>>>>>>>> instantiated. (self::$database = new MySQLDB();)
>>>>>>>>>
>>>>>>>>> so:
>>>>>>>>> self::$database = new MySQLDB();
>>>>>>>>> Config::getDbConfig();
>>>>>>>>>
>>>>>>>>> I realised that the database stored can't be done when config is
>>>>>>>>> initialised as the database hasn't been connected at this point.
>>>>>>>>> There is then a reverse dependency that prevents the database from
>>>>>>>>> connecting until config has been initialised.
>>>>>>>>>
>>>>>>>>> Therefore the program flow had to be:
>>>>>>>>> 1. init Config
>>>>>>>>> 2. init Database
>>>>>>>>> 3. get database stored config
>>>>>>>>>
>>>>>>>>> What I would like to do is align this with the updates you are
>>>>>>>>> working on. I have populated my new temporary config table with just
>>>>>>>>> ('version','1.5.3')
>>>>>>>>>
>>>>>>>>> Finally, what country are you based in scott? I'm in the UK.
>>>>>>>>>
>>>>>>>>> Cheers
>>>>>>>>> Mark
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> _____________________________________________
>>>>>>>>>
>>>>>>>>> Mob: 07725 695178
>>>>>>>>> Email: ma...@rw...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Scott M. <sco...@gm...> - 2011-02-18 20:17:40
|
Oh, I'd forgotten another issue I wanted to discuss. Do you really think
that it's necessary to have the configuration table use a long text field?
Honestly, I'm thinking a tiny text field (256 characters) might be good
enough, especially since we're planning to not have HTML info in this new
configuration table. However, as soon as we agree to cover ourselves for
the need for longer fields with text or medium text, we may as well go with
long text. The same amount of storage is actually used (the actual size of
the data) with any of those text types.
So, is 256 characters enough for a limit in our new configuration table?
The longest field needed in the new configuration table so far takes up less
than 30 characters.
-Scott
On Fri, Feb 18, 2011 at 8:04 PM, Scott Miller <sco...@gm...>wrote:
> Yes, using svn for version numbers would be a good idea, I remember doing
> some research on this, but I've never actually done it.
>
> I like the ideas behind how to update/upgrade in the future. But for now,
> what I think I'm going to try to do is take the old way of having an
> sql.in file for our next version (1.5.3), and add additional logic behind
> that to convert the existing config table and turn it into the new
> configuration table, then when the "real" sql file is run against the
> database, that work is done correctly. So, from that, I think the added
> logic needed for the version 1.5.3 upgrade stuff will actually get placed in
> the install script itself...
>
> -Scott
>
>
> On Fri, Feb 18, 2011 at 4:08 PM, Mark Wrightson <ma...@rw...>wrote:
>
>> Hi Scott,
>>
>> The way you would 'auto increment' the version would be to use the svn
>> feature that can insert version numbers into a specific place in a file upon
>> commit. But i think auto increment is a bad idea.
>>
>> I am going to be away all weekend so won't be able to do any work. I have
>> been thinking about how to do upgrades a bit and what I was thinking was a
>> bit like having 1.5.3.sql also have a 1.5.3.php file with a string of
>> instructions that can be run.
>>
>> How about having a folder: 'install/version' ?
>> For now maybe place your cvt-cfg.php in install/version as '1.5.4.php' or
>> whatever the next version number is? and then modify the text in the
>> upgrade.php file to indicate that this file needs to be run?
>>
>> For future work: to form a structure for the upgrade.php files I think we
>> should have something like:
>>
>> class upgrade_1_5_4 extends Upgrade{
>> .... some stuff in here
>> }
>>
>> abstract class Upgrade{
>>
>> abstract public function __construct();
>> abstract public function functionName();
>> }
>>
>> If the upgrade php files have a common structure and known function names
>> then it would mean the upgrade script could be written quite robustly.
>>
>>
>> Regards
>> Mark
>>
>> _____________________________________________
>>
>> Mob: 07725 695178
>> Email: ma...@rw...
>>
>>
>> On 18/02/2011 15:41, Scott Miller wrote:
>>
>> Mark,
>>
>> Well, what I have is a php script that takes the LDAP and other misc stuff
>> from the existing config table and inserts those entries into the new
>> configuration table. So, it is also ignoring all the html and acl entries.
>> It changes several LDAP entries and creates the new LDAPurl item, and
>> modifies the version to be 1.5.3. I've thought about trying to figure out
>> how to "auto increment" the version, but I'm thinking we actually don't want
>> that to happen.
>>
>> So, this is in a script currently called cvt-cfg.php in the install
>> directory. I'm just now starting to think about how and where to run this
>> script... should it be imbedded as part of the upgrade script(s)? Or
>> should I just check this new file in for now?
>>
>> -Scott
>>
>> On Thu, Feb 17, 2011 at 10:25 PM, Mark Wrightson <
>> ma...@rw...> wrote:
>>
>>> Hi Scott,
>>>
>>> Yeah remove the id column. The option name should really be the unique
>>> key anyway.
>>>
>>> If you:
>>>
>>> 1.create an sql file with the change in install/sql/{version_number}.sql
>>> 2. increment the version in the config table, and put that in the sql
>>> file from above.
>>> 3. increment the version value in config.factory.class.php (such that
>>> this value will match the value entered in the sql above)
>>> it will force the upgrade script to appear and inform developers that
>>> there is a change to the database :)
>>>
>>> I think for the time being we should sideline the authorisation changes
>>> as they do work, and concentrate on finishing the css changes that are still
>>> on going. Some user testing wouldn't go a miss either.
>>>
>>> Regards
>>> Mark Wrightson
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 17/02/2011 21:52, Scott Miller wrote:
>>>
>>> Hey Mark,
>>>
>>> I've actually had time to do some stuff with it today, yesterday ended up
>>> being filled with work.
>>>
>>> Can I propose that we remove the ID column from the new configuration
>>> table? I can't see that being useful in the future...
>>>
>>> -Scott
>>>
>>> On Thu, Feb 17, 2011 at 9:06 AM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>> Ah right ok. It may take a while to rewrite the install script. I
>>>> need to get a structure on paper first i think.
>>>>
>>>> I'll have a think about the excel stuff. One of the feature requests
>>>> was to output to csv also.
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob: 07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>> On 16/02/2011 16:41, Scott Miller wrote:
>>>>
>>>> Yes, the installer stuff is what I was talking about. If you can clean
>>>> it up, great, I don't have a good vision for how that would look, so the
>>>> best I can do is take what we've got and continue to add in our new
>>>> changes. I should be able to fix bugs in the current system if you can find
>>>> them, but again, if you can re-write it so that it's not nearly as
>>>> complicated and works better, I'd say that would be a good thing.
>>>>
>>>> As for the excel exporting, there was a really old mechanism that I
>>>> could never get to work, and someone else had created and submitted a
>>>> different report with a different mechanism that worked for me, so I just
>>>> took what worked and applied it to the rest of the reports. The way it
>>>> works, we would have had a ton of "replicated code" if we attempted to have
>>>> exporting call a different script than the one that created the report for
>>>> the screen, and that would have been even worse to maintain. Again, if you
>>>> have a better way to do it, great.
>>>>
>>>> -Scott
>>>>
>>>> On Wed, Feb 16, 2011 at 4:28 PM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>> Hi Scott,
>>>>>
>>>>> I don't understand what you mean?
>>>>> ---
>>>>>
>>>>> "Yes, it took me quite a while to wrap my brain around what all was
>>>>> happening. The same script is called repeatedly for each step of the
>>>>> process, so figuring out how and where to add things was interesting."
>>>>> ---
>>>>>
>>>>> Ohhh - do you mean how the original install script worked was
>>>>> interesting? If that is what you mean then yes i do agree. I'm looking to
>>>>> take inspiration from the old install script and write a new object
>>>>> orientated version. The main grief I had with the old installer was that if
>>>>> you asked it to create the database for you, it sometimes messed things up
>>>>> good n proper and got itself all confused. In the end I went through
>>>>> phpmyadmin, reversed what it had done and setup the database manually
>>>>> through that.
>>>>>
>>>>> Yes completing the transition from the old config to the new config
>>>>> would definitely be good :)
>>>>> Other things that need looking at are going through and just seeing if
>>>>> the timesheet app works because very little has been tested since it was
>>>>> rewritten.
>>>>> Oh also the excel export features on a couple of pages really have been
>>>>> hacked into tsng. the view and export options should be totally separate
>>>>> pages all together to tidy up the code instead of being munged all into one
>>>>> file.
>>>>>
>>>>> Regards
>>>>>
>>>>> Mark
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob: 07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>> On 16/02/2011 16:06, Scott Miller wrote:
>>>>>
>>>>> Yes, it took me quite a while to wrap my brain around what all was
>>>>> happening. The same script is called repeatedly for each step of the
>>>>> process, so figuring out how and where to add things was interesting.
>>>>>
>>>>> I'll help get that fixed up if you want, but today, I'll attempt to
>>>>> work on taking data from the existing config database and populating our new
>>>>> configuration table with that stuff. And if I get that done, I'll then
>>>>> start working on getting that config stuff loaded with the config classes...
>>>>>
>>>>> Maybe tomorrow I'll do something about the install/upgrade stuff...
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Wed, Feb 16, 2011 at 12:49 AM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>> Hi Scott, Ok I will commit everything that I have done.
>>>>>> This will then put you in a good position to complete the transfer
>>>>>> from the old config table to the new one.
>>>>>>
>>>>>> I am just adding in some warnings to the install script to say that it
>>>>>> isn't complete and how to do a manual update.
>>>>>>
>>>>>> It is now 00:47 here. :)
>>>>>>
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob: 07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>> On 15/02/2011 23:47, Scott Miller wrote:
>>>>>>
>>>>>> well, considering it's in the demo branch, I'd say commit it now.
>>>>>> Might quickly document that the install script isn't working yet...
>>>>>>
>>>>>> I'd like to help you, but I'm a bit wary about what part to change as
>>>>>> much as you changed within the past day or so :-)
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> On Tue, Feb 15, 2011 at 11:44 PM, Mark Wrightson <
>>>>>> ma...@rw...> wrote:
>>>>>>
>>>>>>> I think we should skip 1.6 and go straight to 2.0 - a major update
>>>>>>> requires a major release number. :)
>>>>>>>
>>>>>>> Yes, I was the one suggesting removing everything except the string
>>>>>>> field in the config table.
>>>>>>>
>>>>>>> This install script stuff is quite complex, i'm now at the point
>>>>>>> where the site will automatically detect that the database version is no
>>>>>>> longer
>>>>>>> in sync with the codebase version and will start an upgrade process.
>>>>>>> I've also got the hooks in place to detect a new installation.
>>>>>>> The new install script won't need to be deleted and it uses the
>>>>>>> templating system so can use a theme to make it look really smart :)
>>>>>>>
>>>>>>> When do you think I should start committing it back up? - it is
>>>>>>> currently at a stage where it tells the user what needs to happen, just
>>>>>>> doesn't actually perform the install /upgrade. I think the actual install
>>>>>>> script bit could take a while to write. I could commit it now, it would
>>>>>>> just mean that only a manual install would be possible.
>>>>>>>
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> _____________________________________________
>>>>>>>
>>>>>>> Mob: 07725 695178
>>>>>>> Email: ma...@rw...
>>>>>>>
>>>>>>>
>>>>>>> On 15/02/2011 22:59, Scott Miller wrote:
>>>>>>>
>>>>>>> I think with all the changes we're making with this version, it will
>>>>>>> be version 1.6 :-)
>>>>>>> I don't remember if you were the one to suggest removing all but the
>>>>>>> string variable in the new config table, I'd thought about that myself, so,
>>>>>>> that's probably a good direction to head.
>>>>>>>
>>>>>>> -Scott
>>>>>>>
>>>>>>> On Tue, Feb 15, 2011 at 5:16 PM, Mark Wrightson <
>>>>>>> ma...@rw...> wrote:
>>>>>>>
>>>>>>>> Hi Scott,
>>>>>>>>
>>>>>>>> I thought I would drop you an email to ask what position you were in
>>>>>>>> regards to updating the config database table?
>>>>>>>> last night in my work to update the installer I had to write a small
>>>>>>>> amount of code along the lines of what you are working on.
>>>>>>>>
>>>>>>>> I made the following additions to config.class.php
>>>>>>>>
>>>>>>>>
>>>>>>>> One new function:
>>>>>>>>
>>>>>>>> public static function getDbConfig(){
>>>>>>>>
>>>>>>>> $q = "SELECT * FROM ".tbl::getNewConfigTable();
>>>>>>>>
>>>>>>>> $data = Site::getDatabase()->sql($q,true,
>>>>>>>> MySQLDB::TYPE_OBJECT);
>>>>>>>> if($data == MySQLDB::SQL_EMPTY || $data ==
>>>>>>>> MySQLDB::SQL_ERROR)return;
>>>>>>>>
>>>>>>>> foreach($data as $obj){
>>>>>>>>
>>>>>>>> if($obj->name == 'version'){
>>>>>>>> parent::$databaseVersion = $obj->value;
>>>>>>>> self::runVersionCheck();
>>>>>>>> }
>>>>>>>>
>>>>>>>> //more config variables to be stored into the
>>>>>>>> //config class or config.factory.class
>>>>>>>>
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> and in /index.php
>>>>>>>>
>>>>>>>> Config::getDbConfig(); on the line after the database has been
>>>>>>>> instantiated. (self::$database = new MySQLDB();)
>>>>>>>>
>>>>>>>> so:
>>>>>>>> self::$database = new MySQLDB();
>>>>>>>> Config::getDbConfig();
>>>>>>>>
>>>>>>>> I realised that the database stored can't be done when config is
>>>>>>>> initialised as the database hasn't been connected at this point.
>>>>>>>> There is then a reverse dependency that prevents the database from
>>>>>>>> connecting until config has been initialised.
>>>>>>>>
>>>>>>>> Therefore the program flow had to be:
>>>>>>>> 1. init Config
>>>>>>>> 2. init Database
>>>>>>>> 3. get database stored config
>>>>>>>>
>>>>>>>> What I would like to do is align this with the updates you are
>>>>>>>> working on. I have populated my new temporary config table with just
>>>>>>>> ('version','1.5.3')
>>>>>>>>
>>>>>>>> Finally, what country are you based in scott? I'm in the UK.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> --
>>>>>>>> _____________________________________________
>>>>>>>>
>>>>>>>> Mob: 07725 695178
>>>>>>>> Email: ma...@rw...
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Scott M. <sco...@gm...> - 2011-02-18 20:16:58
|
Yes, using svn for version numbers would be a good idea, I remember doing
some research on this, but I've never actually done it.
I like the ideas behind how to update/upgrade in the future. But for now,
what I think I'm going to try to do is take the old way of having an
sql.infile for our next version (1.5.3), and add additional logic
behind that to
convert the existing config table and turn it into the new configuration
table, then when the "real" sql file is run against the database, that work
is done correctly. So, from that, I think the added logic needed for the
version 1.5.3 upgrade stuff will actually get placed in the install script
itself...
-Scott
On Fri, Feb 18, 2011 at 4:08 PM, Mark Wrightson <ma...@rw...>wrote:
> Hi Scott,
>
> The way you would 'auto increment' the version would be to use the svn
> feature that can insert version numbers into a specific place in a file upon
> commit. But i think auto increment is a bad idea.
>
> I am going to be away all weekend so won't be able to do any work. I have
> been thinking about how to do upgrades a bit and what I was thinking was a
> bit like having 1.5.3.sql also have a 1.5.3.php file with a string of
> instructions that can be run.
>
> How about having a folder: 'install/version' ?
> For now maybe place your cvt-cfg.php in install/version as '1.5.4.php' or
> whatever the next version number is? and then modify the text in the
> upgrade.php file to indicate that this file needs to be run?
>
> For future work: to form a structure for the upgrade.php files I think we
> should have something like:
>
> class upgrade_1_5_4 extends Upgrade{
> .... some stuff in here
> }
>
> abstract class Upgrade{
>
> abstract public function __construct();
> abstract public function functionName();
> }
>
> If the upgrade php files have a common structure and known function names
> then it would mean the upgrade script could be written quite robustly.
>
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 18/02/2011 15:41, Scott Miller wrote:
>
> Mark,
>
> Well, what I have is a php script that takes the LDAP and other misc stuff
> from the existing config table and inserts those entries into the new
> configuration table. So, it is also ignoring all the html and acl entries.
> It changes several LDAP entries and creates the new LDAPurl item, and
> modifies the version to be 1.5.3. I've thought about trying to figure out
> how to "auto increment" the version, but I'm thinking we actually don't want
> that to happen.
>
> So, this is in a script currently called cvt-cfg.php in the install
> directory. I'm just now starting to think about how and where to run this
> script... should it be imbedded as part of the upgrade script(s)? Or
> should I just check this new file in for now?
>
> -Scott
>
> On Thu, Feb 17, 2011 at 10:25 PM, Mark Wrightson <ma...@rw...
> > wrote:
>
>> Hi Scott,
>>
>> Yeah remove the id column. The option name should really be the unique
>> key anyway.
>>
>> If you:
>>
>> 1.create an sql file with the change in install/sql/{version_number}.sql
>> 2. increment the version in the config table, and put that in the sql file
>> from above.
>> 3. increment the version value in config.factory.class.php (such that this
>> value will match the value entered in the sql above)
>> it will force the upgrade script to appear and inform developers that
>> there is a change to the database :)
>>
>> I think for the time being we should sideline the authorisation changes as
>> they do work, and concentrate on finishing the css changes that are still on
>> going. Some user testing wouldn't go a miss either.
>>
>> Regards
>> Mark Wrightson
>>
>> _____________________________________________
>>
>> Mob: 07725 695178
>> Email: ma...@rw...
>>
>>
>> On 17/02/2011 21:52, Scott Miller wrote:
>>
>> Hey Mark,
>>
>> I've actually had time to do some stuff with it today, yesterday ended up
>> being filled with work.
>>
>> Can I propose that we remove the ID column from the new configuration
>> table? I can't see that being useful in the future...
>>
>> -Scott
>>
>> On Thu, Feb 17, 2011 at 9:06 AM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>> Ah right ok. It may take a while to rewrite the install script. I need
>>> to get a structure on paper first i think.
>>>
>>> I'll have a think about the excel stuff. One of the feature requests was
>>> to output to csv also.
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 16/02/2011 16:41, Scott Miller wrote:
>>>
>>> Yes, the installer stuff is what I was talking about. If you can clean
>>> it up, great, I don't have a good vision for how that would look, so the
>>> best I can do is take what we've got and continue to add in our new
>>> changes. I should be able to fix bugs in the current system if you can find
>>> them, but again, if you can re-write it so that it's not nearly as
>>> complicated and works better, I'd say that would be a good thing.
>>>
>>> As for the excel exporting, there was a really old mechanism that I could
>>> never get to work, and someone else had created and submitted a different
>>> report with a different mechanism that worked for me, so I just took what
>>> worked and applied it to the rest of the reports. The way it works, we
>>> would have had a ton of "replicated code" if we attempted to have exporting
>>> call a different script than the one that created the report for the screen,
>>> and that would have been even worse to maintain. Again, if you have a
>>> better way to do it, great.
>>>
>>> -Scott
>>>
>>> On Wed, Feb 16, 2011 at 4:28 PM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>> Hi Scott,
>>>>
>>>> I don't understand what you mean?
>>>> ---
>>>>
>>>> "Yes, it took me quite a while to wrap my brain around what all was
>>>> happening. The same script is called repeatedly for each step of the
>>>> process, so figuring out how and where to add things was interesting."
>>>> ---
>>>>
>>>> Ohhh - do you mean how the original install script worked was
>>>> interesting? If that is what you mean then yes i do agree. I'm looking to
>>>> take inspiration from the old install script and write a new object
>>>> orientated version. The main grief I had with the old installer was that if
>>>> you asked it to create the database for you, it sometimes messed things up
>>>> good n proper and got itself all confused. In the end I went through
>>>> phpmyadmin, reversed what it had done and setup the database manually
>>>> through that.
>>>>
>>>> Yes completing the transition from the old config to the new config
>>>> would definitely be good :)
>>>> Other things that need looking at are going through and just seeing if
>>>> the timesheet app works because very little has been tested since it was
>>>> rewritten.
>>>> Oh also the excel export features on a couple of pages really have been
>>>> hacked into tsng. the view and export options should be totally separate
>>>> pages all together to tidy up the code instead of being munged all into one
>>>> file.
>>>>
>>>> Regards
>>>>
>>>> Mark
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob: 07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>> On 16/02/2011 16:06, Scott Miller wrote:
>>>>
>>>> Yes, it took me quite a while to wrap my brain around what all was
>>>> happening. The same script is called repeatedly for each step of the
>>>> process, so figuring out how and where to add things was interesting.
>>>>
>>>> I'll help get that fixed up if you want, but today, I'll attempt to work
>>>> on taking data from the existing config database and populating our new
>>>> configuration table with that stuff. And if I get that done, I'll then
>>>> start working on getting that config stuff loaded with the config classes...
>>>>
>>>> Maybe tomorrow I'll do something about the install/upgrade stuff...
>>>>
>>>> -Scott
>>>>
>>>> On Wed, Feb 16, 2011 at 12:49 AM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>> Hi Scott, Ok I will commit everything that I have done.
>>>>> This will then put you in a good position to complete the transfer from
>>>>> the old config table to the new one.
>>>>>
>>>>> I am just adding in some warnings to the install script to say that it
>>>>> isn't complete and how to do a manual update.
>>>>>
>>>>> It is now 00:47 here. :)
>>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob: 07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>> On 15/02/2011 23:47, Scott Miller wrote:
>>>>>
>>>>> well, considering it's in the demo branch, I'd say commit it now. Might
>>>>> quickly document that the install script isn't working yet...
>>>>>
>>>>> I'd like to help you, but I'm a bit wary about what part to change as
>>>>> much as you changed within the past day or so :-)
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Tue, Feb 15, 2011 at 11:44 PM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>> I think we should skip 1.6 and go straight to 2.0 - a major update
>>>>>> requires a major release number. :)
>>>>>>
>>>>>> Yes, I was the one suggesting removing everything except the string
>>>>>> field in the config table.
>>>>>>
>>>>>> This install script stuff is quite complex, i'm now at the point where
>>>>>> the site will automatically detect that the database version is no longer
>>>>>> in sync with the codebase version and will start an upgrade process.
>>>>>> I've also got the hooks in place to detect a new installation.
>>>>>> The new install script won't need to be deleted and it uses the
>>>>>> templating system so can use a theme to make it look really smart :)
>>>>>>
>>>>>> When do you think I should start committing it back up? - it is
>>>>>> currently at a stage where it tells the user what needs to happen, just
>>>>>> doesn't actually perform the install /upgrade. I think the actual install
>>>>>> script bit could take a while to write. I could commit it now, it would
>>>>>> just mean that only a manual install would be possible.
>>>>>>
>>>>>>
>>>>>> Mark
>>>>>>
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob: 07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>> On 15/02/2011 22:59, Scott Miller wrote:
>>>>>>
>>>>>> I think with all the changes we're making with this version, it will
>>>>>> be version 1.6 :-)
>>>>>> I don't remember if you were the one to suggest removing all but the
>>>>>> string variable in the new config table, I'd thought about that myself, so,
>>>>>> that's probably a good direction to head.
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>> On Tue, Feb 15, 2011 at 5:16 PM, Mark Wrightson <
>>>>>> ma...@rw...> wrote:
>>>>>>
>>>>>>> Hi Scott,
>>>>>>>
>>>>>>> I thought I would drop you an email to ask what position you were in
>>>>>>> regards to updating the config database table?
>>>>>>> last night in my work to update the installer I had to write a small
>>>>>>> amount of code along the lines of what you are working on.
>>>>>>>
>>>>>>> I made the following additions to config.class.php
>>>>>>>
>>>>>>>
>>>>>>> One new function:
>>>>>>>
>>>>>>> public static function getDbConfig(){
>>>>>>>
>>>>>>> $q = "SELECT * FROM ".tbl::getNewConfigTable();
>>>>>>>
>>>>>>> $data = Site::getDatabase()->sql($q,true,
>>>>>>> MySQLDB::TYPE_OBJECT);
>>>>>>> if($data == MySQLDB::SQL_EMPTY || $data ==
>>>>>>> MySQLDB::SQL_ERROR)return;
>>>>>>>
>>>>>>> foreach($data as $obj){
>>>>>>>
>>>>>>> if($obj->name == 'version'){
>>>>>>> parent::$databaseVersion = $obj->value;
>>>>>>> self::runVersionCheck();
>>>>>>> }
>>>>>>>
>>>>>>> //more config variables to be stored into the
>>>>>>> //config class or config.factory.class
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> and in /index.php
>>>>>>>
>>>>>>> Config::getDbConfig(); on the line after the database has been
>>>>>>> instantiated. (self::$database = new MySQLDB();)
>>>>>>>
>>>>>>> so:
>>>>>>> self::$database = new MySQLDB();
>>>>>>> Config::getDbConfig();
>>>>>>>
>>>>>>> I realised that the database stored can't be done when config is
>>>>>>> initialised as the database hasn't been connected at this point.
>>>>>>> There is then a reverse dependency that prevents the database from
>>>>>>> connecting until config has been initialised.
>>>>>>>
>>>>>>> Therefore the program flow had to be:
>>>>>>> 1. init Config
>>>>>>> 2. init Database
>>>>>>> 3. get database stored config
>>>>>>>
>>>>>>> What I would like to do is align this with the updates you are
>>>>>>> working on. I have populated my new temporary config table with just
>>>>>>> ('version','1.5.3')
>>>>>>>
>>>>>>> Finally, what country are you based in scott? I'm in the UK.
>>>>>>>
>>>>>>> Cheers
>>>>>>> Mark
>>>>>>>
>>>>>>> --
>>>>>>> _____________________________________________
>>>>>>>
>>>>>>> Mob: 07725 695178
>>>>>>> Email: ma...@rw...
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Scott M. <sco...@gm...> - 2011-02-18 16:27:33
|
Hi all, Adding a bit of code, or message history has had us hitting the limit of 40 KB for an auto approved message quite often, so I've bumped this up to 60 KB. -Scott |
|
From: Mark W. <ma...@rw...> - 2011-02-18 16:08:33
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
The way you would 'auto increment' the version would be to use the
svn feature that can insert version numbers into a specific place in
a file upon commit. But i think auto increment is a bad idea.<br>
<br>
I am going to be away all weekend so won't be able to do any work.
I have been thinking about how to do upgrades a bit and what I was
thinking was a bit like having 1.5.3.sql also have a 1.5.3.php file
with a string of instructions that can be run.<br>
<br>
How about having a folder: 'install/version' ?<br>
For now maybe place your cvt-cfg.php in install/version as
'1.5.4.php' or whatever the next version number is? and then modify
the text in the upgrade.php file to indicate that this file needs to
be run?<br>
<br>
For future work: to form a structure for the upgrade.php files I
think we should have something like:<br>
<br>
class upgrade_1_5_4 extends Upgrade{<br>
.... some stuff in here<br>
}<br>
<br>
abstract class Upgrade{<br>
<br>
abstract public function __construct();<br>
abstract public function functionName();<br>
}<br>
<br>
If the upgrade php files have a common structure and known function
names then it would mean the upgrade script could be written quite
robustly.<br>
<br>
Regards<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 18/02/2011 15:41, Scott Miller wrote:
<blockquote
cite="mid:AANLkTimcoysL5Yi=mAf...@ma..."
type="cite">Mark,<br>
<br>
Well, what I have is a php script that takes the LDAP and other
misc stuff from the existing config table and inserts those
entries into the new configuration table. So, it is also ignoring
all the html and acl entries. It changes several LDAP entries and
creates the new LDAPurl item, and modifies the version to be
1.5.3. I've thought about trying to figure out how to "auto
increment" the version, but I'm thinking we actually don't want
that to happen.<br>
<br>
So, this is in a script currently called cvt-cfg.php in the
install directory. I'm just now starting to think about how and
where to run this script... should it be imbedded as part of the
upgrade script(s)? Or should I just check this new file in for
now?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Thu, Feb 17, 2011 at 10:25 PM, Mark
Wrightson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Hi Scott, <br>
<br>
Yeah remove the id column. The option name should really be
the unique key anyway.<br>
<br>
If you:<br>
<br>
1.create an sql file with the change in
install/sql/{version_number}.sql<br>
2. increment the version in the config table, and put that
in the sql file from above.<br>
3. increment the version value in config.factory.class.php
(such that this value will match the value entered in the
sql above)<br>
it will force the upgrade script to appear and inform
developers that there is a change to the database :)<br>
<br>
I think for the time being we should sideline the
authorisation changes as they do work, and concentrate on
finishing the css changes that are still on going. Some
user testing wouldn't go a miss either.<br>
<br>
Regards<br>
<font color="#888888"> Mark Wrightson</font>
<div class="im"><br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div class="h5"> On 17/02/2011 21:52, Scott Miller wrote:
<blockquote type="cite">Hey Mark,<br>
<br>
I've actually had time to do some stuff with it today,
yesterday ended up being filled with work. <br>
<br>
Can I propose that we remove the ID column from the
new configuration table? I can't see that being
useful in the future...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Thu, Feb 17, 2011 at 9:06
AM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Ah right
ok. It may take a while to rewrite the install
script. I need to get a structure on paper
first i think.<br>
<br>
I'll have a think about the excel stuff. One of
the feature requests was to output to csv also.
<div><br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 16/02/2011 16:41, Scott Miller wrote:
<blockquote type="cite">Yes, the installer
stuff is what I was talking about. If you
can clean it up, great, I don't have a
good vision for how that would look, so
the best I can do is take what we've got
and continue to add in our new changes. I
should be able to fix bugs in the current
system if you can find them, but again, if
you can re-write it so that it's not
nearly as complicated and works better,
I'd say that would be a good thing.<br>
<br>
As for the excel exporting, there was a
really old mechanism that I could never
get to work, and someone else had created
and submitted a different report with a
different mechanism that worked for me, so
I just took what worked and applied it to
the rest of the reports. The way it
works, we would have had a ton of
"replicated code" if we attempted to have
exporting call a different script than the
one that created the report for the
screen, and that would have been even
worse to maintain. Again, if you have a
better way to do it, great.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Wed, Feb 16,
2011 at 4:28 PM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
I don't understand what you mean?<br>
---
<div><br>
"Yes, it took me quite a while to
wrap my brain around what all was
happening. The same script is
called repeatedly for each step of
the process, so figuring out how
and where to add things was
interesting."<br>
</div>
---<br>
<br>
Ohhh - do you mean how the original
install script worked was
interesting? If that is what you
mean then yes i do agree. I'm
looking to take inspiration from the
old install script and write a new
object orientated version. The main
grief I had with the old installer
was that if you asked it to create
the database for you, it sometimes
messed things up good n proper and
got itself all confused. In the end
I went through phpmyadmin, reversed
what it had done and setup the
database manually through that.<br>
<br>
Yes completing the transition from
the old config to the new config
would definitely be good :)<br>
Other things that need looking at
are going through and just seeing if
the timesheet app works because very
little has been tested since it was
rewritten.<br>
Oh also the excel export features on
a couple of pages really have been
hacked into tsng. the view and
export options should be totally
separate pages all together to tidy
up the code instead of being munged
all into one file.<br>
<br>
Regards
<div><br>
Mark<br>
<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 16/02/2011 16:06, Scott
Miller wrote:
<blockquote type="cite">Yes, it
took me quite a while to wrap
my brain around what all was
happening. The same script is
called repeatedly for each
step of the process, so
figuring out how and where to
add things was interesting.<br>
<br>
I'll help get that fixed up if
you want, but today, I'll
attempt to work on taking data
from the existing config
database and populating our
new configuration table with
that stuff. And if I get that
done, I'll then start working
on getting that config stuff
loaded with the config
classes...<br>
<br>
Maybe tomorrow I'll do
something about the
install/upgrade stuff...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On
Wed, Feb 16, 2011 at 12:49
AM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px
solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000"
bgcolor="#ffffff"> Hi
Scott, Ok I will commit
everything that I have
done.<br>
This will then put you
in a good position to
complete the transfer
from the old config
table to the new one.<br>
<br>
I am just adding in some
warnings to the install
script to say that it
isn't complete and how
to do a manual update.<br>
<br>
It is now 00:47 here. :)
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 15/02/2011
23:47, Scott Miller
wrote:
<blockquote
type="cite">well,
considering it's
in the demo
branch, I'd say
commit it now.
Might quickly
document that the
install script
isn't working
yet...<br>
<br>
I'd like to help
you, but I'm a bit
wary about what
part to change as
much as you
changed within the
past day or so :-)<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Tue, Feb 15,
2011 at 11:44
PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;">
<div
text="#000000"
bgcolor="#ffffff"> I think we should skip 1.6 and go straight to 2.0 - a
major update
requires a
major release
number. :)<br>
<br>
Yes, I was the
one suggesting
removing
everything
except the
string field
in the config
table.<br>
<br>
This install
script stuff
is quite
complex, i'm
now at the
point where
the site will
automatically
detect that
the database
version is no
longer<br>
in sync with
the codebase
version and
will start an
upgrade
process. I've
also got the
hooks in place
to detect a
new
installation.<br>
The new
install script
won't need to
be deleted and
it uses the
templating
system so can
use a theme to
make it look
really smart
:)<br>
<br>
When do you
think I should
start
committing it
back up? - it
is currently
at a stage
where it tells
the user what
needs to
happen, just
doesn't
actually
perform the
install
/upgrade. I
think the
actual install
script bit
could take a
while to
write. I
could commit
it now, it
would just
mean that only
a manual
install would
be possible.
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On
15/02/2011
22:59, Scott
Miller wrote:
<blockquote
type="cite">I
think with all
the changes
we're making
with this
version, it
will be
version 1.6
:-)<br>
I don't
remember if
you were the
one to suggest
removing all
but the string
variable in
the new config
table, I'd
thought about
that myself,
so, that's
probably a
good direction
to head.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Tue, Feb 15,
2011 at 5:16
PM, Mark
Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;"> Hi
Scott,<br>
<br>
I thought I
would drop you
an email to
ask what
position you
were in
regards to
updating the
config
database
table?<br>
last night in
my work to
update the
installer I
had to write a
small amount
of code along
the lines of
what you are
working on.<br>
<br>
I made the
following
additions to
config.class.php<br>
<br>
<br>
One new
function:<br>
<br>
public
static
function
getDbConfig(){<br>
<br>
$q =
"SELECT * FROM
".tbl::getNewConfigTable();<br>
<br>
$data =
Site::getDatabase()->sql($q,true,
MySQLDB::TYPE_OBJECT);<br>
if($data ==
MySQLDB::SQL_EMPTY
|| $data ==
MySQLDB::SQL_ERROR)return;<br>
<br>
foreach($data
as $obj){<br>
<br>
if($obj->name
== 'version'){<br>
parent::$databaseVersion
=
$obj->value;<br>
self::runVersionCheck();<br>
}<br>
<br>
//more config
variables to
be stored into
the<br>
//config
class or
config.factory.class<br>
<br>
<br>
}<br>
<br>
<br>
}<br>
<br>
<br>
and in
/index.php<br>
<br>
Config::getDbConfig();
on the line
after the
database has
been
instantiated.
(self::$database
= new
MySQLDB();)<br>
<br>
so:<br>
self::$database
= new
MySQLDB();<br>
Config::getDbConfig();<br>
<br>
I realised
that the
database
stored can't
be done when
config is
initialised as
the database
hasn't been
connected at
this point.<br>
There is then
a reverse
dependency
that prevents
the database
from
connecting
until config
has been
initialised.<br>
<br>
Therefore the
program flow
had to be:<br>
1. init Config<br>
2. init
Database<br>
3. get
database
stored config<br>
<br>
What I would
like to do is
align this
with the
updates you
are working
on. I have
populated my
new temporary
config table
with just
('version','1.5.3')<br>
<br>
Finally, what
country are
you based in
scott? I'm in
the UK.<br>
<br>
Cheers<br>
Mark<br>
<font
color="#888888">
<br>
-- <br>
_____________________________________________<br>
<br>
Mob: 07725
695178<br>
Email: <a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a><br>
<br>
</font></blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-18 15:42:02
|
Mark,
Well, what I have is a php script that takes the LDAP and other misc stuff
from the existing config table and inserts those entries into the new
configuration table. So, it is also ignoring all the html and acl entries.
It changes several LDAP entries and creates the new LDAPurl item, and
modifies the version to be 1.5.3. I've thought about trying to figure out
how to "auto increment" the version, but I'm thinking we actually don't want
that to happen.
So, this is in a script currently called cvt-cfg.php in the install
directory. I'm just now starting to think about how and where to run this
script... should it be imbedded as part of the upgrade script(s)? Or
should I just check this new file in for now?
-Scott
On Thu, Feb 17, 2011 at 10:25 PM, Mark Wrightson
<ma...@rw...>wrote:
> Hi Scott,
>
> Yeah remove the id column. The option name should really be the unique key
> anyway.
>
> If you:
>
> 1.create an sql file with the change in install/sql/{version_number}.sql
> 2. increment the version in the config table, and put that in the sql file
> from above.
> 3. increment the version value in config.factory.class.php (such that this
> value will match the value entered in the sql above)
> it will force the upgrade script to appear and inform developers that there
> is a change to the database :)
>
> I think for the time being we should sideline the authorisation changes as
> they do work, and concentrate on finishing the css changes that are still on
> going. Some user testing wouldn't go a miss either.
>
> Regards
> Mark Wrightson
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 17/02/2011 21:52, Scott Miller wrote:
>
> Hey Mark,
>
> I've actually had time to do some stuff with it today, yesterday ended up
> being filled with work.
>
> Can I propose that we remove the ID column from the new configuration
> table? I can't see that being useful in the future...
>
> -Scott
>
> On Thu, Feb 17, 2011 at 9:06 AM, Mark Wrightson <ma...@rw...>wrote:
>
>> Ah right ok. It may take a while to rewrite the install script. I need
>> to get a structure on paper first i think.
>>
>> I'll have a think about the excel stuff. One of the feature requests was
>> to output to csv also.
>>
>> _____________________________________________
>>
>> Mob: 07725 695178
>> Email: ma...@rw...
>>
>>
>> On 16/02/2011 16:41, Scott Miller wrote:
>>
>> Yes, the installer stuff is what I was talking about. If you can clean it
>> up, great, I don't have a good vision for how that would look, so the best I
>> can do is take what we've got and continue to add in our new changes. I
>> should be able to fix bugs in the current system if you can find them, but
>> again, if you can re-write it so that it's not nearly as complicated and
>> works better, I'd say that would be a good thing.
>>
>> As for the excel exporting, there was a really old mechanism that I could
>> never get to work, and someone else had created and submitted a different
>> report with a different mechanism that worked for me, so I just took what
>> worked and applied it to the rest of the reports. The way it works, we
>> would have had a ton of "replicated code" if we attempted to have exporting
>> call a different script than the one that created the report for the screen,
>> and that would have been even worse to maintain. Again, if you have a
>> better way to do it, great.
>>
>> -Scott
>>
>> On Wed, Feb 16, 2011 at 4:28 PM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>> Hi Scott,
>>>
>>> I don't understand what you mean?
>>> ---
>>>
>>> "Yes, it took me quite a while to wrap my brain around what all was
>>> happening. The same script is called repeatedly for each step of the
>>> process, so figuring out how and where to add things was interesting."
>>> ---
>>>
>>> Ohhh - do you mean how the original install script worked was
>>> interesting? If that is what you mean then yes i do agree. I'm looking to
>>> take inspiration from the old install script and write a new object
>>> orientated version. The main grief I had with the old installer was that if
>>> you asked it to create the database for you, it sometimes messed things up
>>> good n proper and got itself all confused. In the end I went through
>>> phpmyadmin, reversed what it had done and setup the database manually
>>> through that.
>>>
>>> Yes completing the transition from the old config to the new config would
>>> definitely be good :)
>>> Other things that need looking at are going through and just seeing if
>>> the timesheet app works because very little has been tested since it was
>>> rewritten.
>>> Oh also the excel export features on a couple of pages really have been
>>> hacked into tsng. the view and export options should be totally separate
>>> pages all together to tidy up the code instead of being munged all into one
>>> file.
>>>
>>> Regards
>>>
>>> Mark
>>>
>>> _____________________________________________
>>>
>>> Mob: 07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 16/02/2011 16:06, Scott Miller wrote:
>>>
>>> Yes, it took me quite a while to wrap my brain around what all was
>>> happening. The same script is called repeatedly for each step of the
>>> process, so figuring out how and where to add things was interesting.
>>>
>>> I'll help get that fixed up if you want, but today, I'll attempt to work
>>> on taking data from the existing config database and populating our new
>>> configuration table with that stuff. And if I get that done, I'll then
>>> start working on getting that config stuff loaded with the config classes...
>>>
>>> Maybe tomorrow I'll do something about the install/upgrade stuff...
>>>
>>> -Scott
>>>
>>> On Wed, Feb 16, 2011 at 12:49 AM, Mark Wrightson <
>>> ma...@rw...> wrote:
>>>
>>>> Hi Scott, Ok I will commit everything that I have done.
>>>> This will then put you in a good position to complete the transfer from
>>>> the old config table to the new one.
>>>>
>>>> I am just adding in some warnings to the install script to say that it
>>>> isn't complete and how to do a manual update.
>>>>
>>>> It is now 00:47 here. :)
>>>>
>>>>
>>>> Mark
>>>>
>>>> _____________________________________________
>>>>
>>>> Mob: 07725 695178
>>>> Email: ma...@rw...
>>>>
>>>>
>>>> On 15/02/2011 23:47, Scott Miller wrote:
>>>>
>>>> well, considering it's in the demo branch, I'd say commit it now. Might
>>>> quickly document that the install script isn't working yet...
>>>>
>>>> I'd like to help you, but I'm a bit wary about what part to change as
>>>> much as you changed within the past day or so :-)
>>>>
>>>> -Scott
>>>>
>>>> On Tue, Feb 15, 2011 at 11:44 PM, Mark Wrightson <
>>>> ma...@rw...> wrote:
>>>>
>>>>> I think we should skip 1.6 and go straight to 2.0 - a major update
>>>>> requires a major release number. :)
>>>>>
>>>>> Yes, I was the one suggesting removing everything except the string
>>>>> field in the config table.
>>>>>
>>>>> This install script stuff is quite complex, i'm now at the point where
>>>>> the site will automatically detect that the database version is no longer
>>>>> in sync with the codebase version and will start an upgrade process.
>>>>> I've also got the hooks in place to detect a new installation.
>>>>> The new install script won't need to be deleted and it uses the
>>>>> templating system so can use a theme to make it look really smart :)
>>>>>
>>>>> When do you think I should start committing it back up? - it is
>>>>> currently at a stage where it tells the user what needs to happen, just
>>>>> doesn't actually perform the install /upgrade. I think the actual install
>>>>> script bit could take a while to write. I could commit it now, it would
>>>>> just mean that only a manual install would be possible.
>>>>>
>>>>>
>>>>> Mark
>>>>>
>>>>> _____________________________________________
>>>>>
>>>>> Mob: 07725 695178
>>>>> Email: ma...@rw...
>>>>>
>>>>>
>>>>> On 15/02/2011 22:59, Scott Miller wrote:
>>>>>
>>>>> I think with all the changes we're making with this version, it will be
>>>>> version 1.6 :-)
>>>>> I don't remember if you were the one to suggest removing all but the
>>>>> string variable in the new config table, I'd thought about that myself, so,
>>>>> that's probably a good direction to head.
>>>>>
>>>>> -Scott
>>>>>
>>>>> On Tue, Feb 15, 2011 at 5:16 PM, Mark Wrightson <
>>>>> ma...@rw...> wrote:
>>>>>
>>>>>> Hi Scott,
>>>>>>
>>>>>> I thought I would drop you an email to ask what position you were in
>>>>>> regards to updating the config database table?
>>>>>> last night in my work to update the installer I had to write a small
>>>>>> amount of code along the lines of what you are working on.
>>>>>>
>>>>>> I made the following additions to config.class.php
>>>>>>
>>>>>>
>>>>>> One new function:
>>>>>>
>>>>>> public static function getDbConfig(){
>>>>>>
>>>>>> $q = "SELECT * FROM ".tbl::getNewConfigTable();
>>>>>>
>>>>>> $data = Site::getDatabase()->sql($q,true,
>>>>>> MySQLDB::TYPE_OBJECT);
>>>>>> if($data == MySQLDB::SQL_EMPTY || $data ==
>>>>>> MySQLDB::SQL_ERROR)return;
>>>>>>
>>>>>> foreach($data as $obj){
>>>>>>
>>>>>> if($obj->name == 'version'){
>>>>>> parent::$databaseVersion = $obj->value;
>>>>>> self::runVersionCheck();
>>>>>> }
>>>>>>
>>>>>> //more config variables to be stored into the
>>>>>> //config class or config.factory.class
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> }
>>>>>>
>>>>>>
>>>>>> and in /index.php
>>>>>>
>>>>>> Config::getDbConfig(); on the line after the database has been
>>>>>> instantiated. (self::$database = new MySQLDB();)
>>>>>>
>>>>>> so:
>>>>>> self::$database = new MySQLDB();
>>>>>> Config::getDbConfig();
>>>>>>
>>>>>> I realised that the database stored can't be done when config is
>>>>>> initialised as the database hasn't been connected at this point.
>>>>>> There is then a reverse dependency that prevents the database from
>>>>>> connecting until config has been initialised.
>>>>>>
>>>>>> Therefore the program flow had to be:
>>>>>> 1. init Config
>>>>>> 2. init Database
>>>>>> 3. get database stored config
>>>>>>
>>>>>> What I would like to do is align this with the updates you are working
>>>>>> on. I have populated my new temporary config table with just
>>>>>> ('version','1.5.3')
>>>>>>
>>>>>> Finally, what country are you based in scott? I'm in the UK.
>>>>>>
>>>>>> Cheers
>>>>>> Mark
>>>>>>
>>>>>> --
>>>>>> _____________________________________________
>>>>>>
>>>>>> Mob: 07725 695178
>>>>>> Email: ma...@rw...
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Mark W. <ma...@rw...> - 2011-02-17 22:25:18
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
Yeah remove the id column. The option name should really be the
unique key anyway.<br>
<br>
If you:<br>
<br>
1.create an sql file with the change in
install/sql/{version_number}.sql<br>
2. increment the version in the config table, and put that in the
sql file from above.<br>
3. increment the version value in config.factory.class.php (such
that this value will match the value entered in the sql above)<br>
it will force the upgrade script to appear and inform developers
that there is a change to the database :)<br>
<br>
I think for the time being we should sideline the authorisation
changes as they do work, and concentrate on finishing the css
changes that are still on going. Some user testing wouldn't go a
miss either.<br>
<br>
Regards<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 17/02/2011 21:52, Scott Miller wrote:
<blockquote
cite="mid:AANLkTimkHv2KKs4kzvBZ=VJG...@ma..."
type="cite">Hey Mark,<br>
<br>
I've actually had time to do some stuff with it today, yesterday
ended up being filled with work. <br>
<br>
Can I propose that we remove the ID column from the new
configuration table? I can't see that being useful in the
future...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Thu, Feb 17, 2011 at 9:06 AM, Mark
Wrightson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Ah right ok. It may
take a while to rewrite the install script. I need to get a
structure on paper first i think.<br>
<br>
I'll have a think about the excel stuff. One of the feature
requests was to output to csv also.
<div class="im"><br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div class="h5"> On 16/02/2011 16:41, Scott Miller wrote:
<blockquote type="cite">Yes, the installer stuff is what
I was talking about. If you can clean it up, great, I
don't have a good vision for how that would look, so
the best I can do is take what we've got and continue
to add in our new changes. I should be able to fix
bugs in the current system if you can find them, but
again, if you can re-write it so that it's not nearly
as complicated and works better, I'd say that would be
a good thing.<br>
<br>
As for the excel exporting, there was a really old
mechanism that I could never get to work, and someone
else had created and submitted a different report with
a different mechanism that worked for me, so I just
took what worked and applied it to the rest of the
reports. The way it works, we would have had a ton of
"replicated code" if we attempted to have exporting
call a different script than the one that created the
report for the screen, and that would have been even
worse to maintain. Again, if you have a better way to
do it, great.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Wed, Feb 16, 2011 at 4:28
PM, Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt
0pt 0pt 0.8ex; border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Hi Scott, <br>
<br>
I don't understand what you mean?<br>
---
<div><br>
"Yes, it took me quite a while to wrap my
brain around what all was happening. The same
script is called repeatedly for each step of
the process, so figuring out how and where to
add things was interesting."<br>
</div>
---<br>
<br>
Ohhh - do you mean how the original install
script worked was interesting? If that is what
you mean then yes i do agree. I'm looking to
take inspiration from the old install script and
write a new object orientated version. The main
grief I had with the old installer was that if
you asked it to create the database for you, it
sometimes messed things up good n proper and got
itself all confused. In the end I went through
phpmyadmin, reversed what it had done and setup
the database manually through that.<br>
<br>
Yes completing the transition from the old
config to the new config would definitely be
good :)<br>
Other things that need looking at are going
through and just seeing if the timesheet app
works because very little has been tested since
it was rewritten.<br>
Oh also the excel export features on a couple of
pages really have been hacked into tsng. the
view and export options should be totally
separate pages all together to tidy up the code
instead of being munged all into one file.<br>
<br>
Regards
<div><br>
Mark<br>
<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 16/02/2011 16:06, Scott Miller wrote:
<blockquote type="cite">Yes, it took me
quite a while to wrap my brain around what
all was happening. The same script is
called repeatedly for each step of the
process, so figuring out how and where to
add things was interesting.<br>
<br>
I'll help get that fixed up if you want,
but today, I'll attempt to work on taking
data from the existing config database and
populating our new configuration table
with that stuff. And if I get that done,
I'll then start working on getting that
config stuff loaded with the config
classes...<br>
<br>
Maybe tomorrow I'll do something about the
install/upgrade stuff...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Wed, Feb 16,
2011 at 12:49 AM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff">
Hi Scott, Ok I will commit
everything that I have done.<br>
This will then put you in a good
position to complete the transfer
from the old config table to the new
one.<br>
<br>
I am just adding in some warnings to
the install script to say that it
isn't complete and how to do a
manual update.<br>
<br>
It is now 00:47 here. :)
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 15/02/2011 23:47, Scott
Miller wrote:
<blockquote type="cite">well,
considering it's in the demo
branch, I'd say commit it now.
Might quickly document that
the install script isn't
working yet...<br>
<br>
I'd like to help you, but I'm
a bit wary about what part to
change as much as you changed
within the past day or so :-)<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On
Tue, Feb 15, 2011 at 11:44
PM, Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px
solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000"
bgcolor="#ffffff"> I
think we should skip 1.6
and go straight to 2.0 -
a major update requires
a major release number.
:)<br>
<br>
Yes, I was the one
suggesting removing
everything except the
string field in the
config table.<br>
<br>
This install script
stuff is quite complex,
i'm now at the point
where the site will
automatically detect
that the database
version is no longer<br>
in sync with the
codebase version and
will start an upgrade
process. I've also got
the hooks in place to
detect a new
installation.<br>
The new install script
won't need to be deleted
and it uses the
templating system so can
use a theme to make it
look really smart :)<br>
<br>
When do you think I
should start committing
it back up? - it is
currently at a stage
where it tells the user
what needs to happen,
just doesn't actually
perform the install
/upgrade. I think the
actual install script
bit could take a while
to write. I could
commit it now, it would
just mean that only a
manual install would be
possible.
<div><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 15/02/2011
22:59, Scott Miller
wrote:
<blockquote
type="cite">I
think with all the
changes we're
making with this
version, it will
be version 1.6 :-)<br>
I don't remember
if you were the
one to suggest
removing all but
the string
variable in the
new config table,
I'd thought about
that myself, so,
that's probably a
good direction to
head.<br>
<br>
-Scott<br>
<br>
<div
class="gmail_quote">On
Tue, Feb 15,
2011 at 5:16 PM,
Mark Wrightson <span
dir="ltr"><<a
moz-do-not-send="true" href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote
class="gmail_quote"
style="margin:
0pt 0pt 0pt
0.8ex;
border-left:
1px solid
rgb(204, 204,
204);
padding-left:
1ex;"> Hi
Scott,<br>
<br>
I thought I
would drop you
an email to
ask what
position you
were in
regards to
updating the
config
database
table?<br>
last night in
my work to
update the
installer I
had to write a
small amount
of code along
the lines of
what you are
working on.<br>
<br>
I made the
following
additions to
config.class.php<br>
<br>
<br>
One new
function:<br>
<br>
public
static
function
getDbConfig(){<br>
<br>
$q =
"SELECT * FROM
".tbl::getNewConfigTable();<br>
<br>
$data =
Site::getDatabase()->sql($q,true,
MySQLDB::TYPE_OBJECT);<br>
if($data ==
MySQLDB::SQL_EMPTY
|| $data ==
MySQLDB::SQL_ERROR)return;<br>
<br>
foreach($data
as $obj){<br>
<br>
if($obj->name
== 'version'){<br>
parent::$databaseVersion
=
$obj->value;<br>
self::runVersionCheck();<br>
}<br>
<br>
//more config
variables to
be stored into
the<br>
//config
class or
config.factory.class<br>
<br>
<br>
}<br>
<br>
<br>
}<br>
<br>
<br>
and in
/index.php<br>
<br>
Config::getDbConfig();
on the line
after the
database has
been
instantiated.
(self::$database
= new
MySQLDB();)<br>
<br>
so:<br>
self::$database
= new
MySQLDB();<br>
Config::getDbConfig();<br>
<br>
I realised
that the
database
stored can't
be done when
config is
initialised as
the database
hasn't been
connected at
this point.<br>
There is then
a reverse
dependency
that prevents
the database
from
connecting
until config
has been
initialised.<br>
<br>
Therefore the
program flow
had to be:<br>
1. init Config<br>
2. init
Database<br>
3. get
database
stored config<br>
<br>
What I would
like to do is
align this
with the
updates you
are working
on. I have
populated my
new temporary
config table
with just
('version','1.5.3')<br>
<br>
Finally, what
country are
you based in
scott? I'm in
the UK.<br>
<br>
Cheers<br>
Mark<br>
<font
color="#888888">
<br>
-- <br>
_____________________________________________<br>
<br>
Mob: 07725
695178<br>
Email: <a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a><br>
<br>
</font></blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-17 18:04:22
|
forgot to include the list...
---------- Forwarded message ----------
From: Scott Miller <sco...@gm...>
Date: Thu, Feb 17, 2011 at 5:16 PM
Subject: Re: [Tsheetx-developers] security model
To: Mark Wrightson <ma...@rw...>
I too had thought about using a group model for security, but I didn't have
working code to use.
But, after thinking about it awhile, does this proposed implementation
actually do a better job of defining group access than the existing
version? Although it is not as well defined, I think the existing model and
this new proposed model may not be sufficiently different from each other to
warrant making all the needed changes.
-Scott
On Thu, Feb 17, 2011 at 2:20 PM, Mark Wrightson <ma...@rw...>wrote:
> Hi Dave,
>
> I see your point that it does add extra complexity, however it won't
> introduce extra bugs because the code
> is already tried and tested. If you would like I am able to demonstrate
> the auth stuff on another site?
> The main benefit the update will bring is scalability.
>
> Only one line of code is required to check for authorisation:
>
> if(Auth::ACCESS_GRANTED == Auth::requestAuth('monthly','view'){
> yes
> }
> else{
> no
> }
>
> Every page in tsng already has the one line of code at the top of the page
> to check whether a given user can access a page or not.
>
> Regards
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 17/02/2011 11:00, David Thompson wrote:
>
> My feedback: it looks very complicated, for something that at the moment is
> relatively simple.
> So does it justify introducing a lot of code, and bugs, for the feature
> that it brings (finer user access control)?
>
> ------------------------------
> Date: Thu, 17 Feb 2011 09:32:57 +0000
> From: ma...@rw...
> To: tsh...@li...
> Subject: Re: [Tsheetx-developers] [SPAM] Re: security model
>
> Hi Peter,
>
> The privilege levels i.e. user, reporter, manager, administrator would be
> created as different user groups. A user can be a member of several groups.
>
> so
> user table:
> 1 admin
> 2 joe bloggs
> 3. test user
>
> user group table:
> guest
> user
> reporter
> manager
> admin
>
> user group assignment
> admin -> administrator
> admin -> manager
> joe blogs ->user
> joe blogs ->report
> test user ->user
> test user ->report
>
> privilege table:
> 1. monthly,view
> 2. stopwatch, view
> 3. clockings, edit
> 4. reports, view
>
>
> privilege assignment:
> reporter -> 4 (reports,view) granted
> user ->1 (...) granted
> user ->2 granted
> manager ->3 granted
> test user ->4 denied
>
>
> If a request to access an area that hasn't been defined in a users access
> control list then it is a denied access.
> If a user is denied access at any point that is it. Denied. i.e. test
> user above is granted access to reports through the reports group but
> is denied access on a specific user basis. Therefore he is denied access.
> A deny should always overrule an allow in my opinion.
>
> The (monthly, view) bit is just a way of allowing pseudo groups of
> privileges to exist so that they can be searched more easily. The fact that
> it is two fields 'monthly', 'view' has no real effect.
>
> In terms of default user groups this would be configured. An unlogged in
> user is part of the group guest. A new signup is part of the group user.
> So therefore I would add an extra group above 'tsx_users' so that a new
> signup has to request access to be able to start using the timesheet
> functions. Alternatively an admin could register a new user and give them
> access straight away.
>
> Please could I have some feedback on my proposed update?
>
> Regards
> Mark Wrightson
>
>
> ------------------------------------------------------------------------------
> 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
>
>
|
|
From: Mark W. <ma...@rw...> - 2011-02-17 14:20:17
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Dave, <br>
<br>
I see your point that it does add extra complexity, however it won't
introduce extra bugs because the code<br>
is already tried and tested. If you would like I am able to
demonstrate the auth stuff on another site?<br>
The main benefit the update will bring is scalability.<br>
<br>
Only one line of code is required to check for authorisation:<br>
<br>
if(Auth::ACCESS_GRANTED == Auth::requestAuth('monthly','view'){<br>
yes<br>
}<br>
else{<br>
no<br>
}<br>
<br>
Every page in tsng already has the one line of code at the top of
the page to check whether a given user can access a page or not.<br>
<br>
Regards<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 17/02/2011 11:00, David Thompson wrote:
<blockquote cite="mid:BAY...@ph...l"
type="cite">
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
My feedback: it looks very complicated, for something that at the
moment is relatively simple.<br>
So does it justify introducing a lot of code, and bugs, for the
feature that it brings (finer user access control)?<br>
<br>
<hr id="stopSpelling">
Date: Thu, 17 Feb 2011 09:32:57 +0000<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:tsh...@li...">tsh...@li...</a><br>
Subject: Re: [Tsheetx-developers] [SPAM] Re: security model<br>
<br>
<meta name="Generator" content="Microsoft SafeHTML">
Hi Peter, <br>
<br>
The privilege levels i.e. user, reporter, manager, administrator
would be created as different user groups. A user can be a member
of several groups.<br>
<br>
so<br>
user table:<br>
1 admin<br>
2 joe bloggs<br>
3. test user<br>
<br>
user group table:<br>
guest<br>
user<br>
reporter<br>
manager<br>
admin<br>
<br>
user group assignment<br>
admin -> administrator<br>
admin -> manager<br>
joe blogs ->user<br>
joe blogs ->report<br>
test user ->user<br>
test user ->report<br>
<br>
privilege table:<br>
1. monthly,view<br>
2. stopwatch, view<br>
3. clockings, edit<br>
4. reports, view <br>
<br>
<br>
privilege assignment:<br>
reporter -> 4 (reports,view) granted<br>
user ->1 (...) granted<br>
user ->2 granted<br>
manager ->3 granted<br>
test user ->4 denied<br>
<br>
<br>
If a request to access an area that hasn't been defined in a users
access control list then it is a denied access.<br>
If a user is denied access at any point that is it. Denied. i.e.
test user above is granted access to reports through the reports
group but<br>
is denied access on a specific user basis. Therefore he is denied
access. A deny should always overrule an allow in my opinion.<br>
<br>
The (monthly, view) bit is just a way of allowing pseudo groups of
privileges to exist so that they can be searched more easily. The
fact that<br>
it is two fields 'monthly', 'view' has no real effect.<br>
<br>
In terms of default user groups this would be configured. An
unlogged in user is part of the group guest. A new signup is part
of the group user.<br>
So therefore I would add an extra group above 'tsx_users' so that
a new signup has to request access to be able to start using the
timesheet functions. Alternatively an admin could register a new
user and give them access straight away.<br>
<br>
Please could I have some feedback on my proposed update?<br>
<br>
Regards<br>
Mark Wrightson<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: David T. <tom...@us...> - 2011-02-17 11:00:33
|
My feedback: it looks very complicated, for something that at the moment is relatively simple. So does it justify introducing a lot of code, and bugs, for the feature that it brings (finer user access control)? Date: Thu, 17 Feb 2011 09:32:57 +0000 From: ma...@rw... To: tsh...@li... Subject: Re: [Tsheetx-developers] [SPAM] Re: security model Hi Peter, The privilege levels i.e. user, reporter, manager, administrator would be created as different user groups. A user can be a member of several groups. so user table: 1 admin 2 joe bloggs 3. test user user group table: guest user reporter manager admin user group assignment admin -> administrator admin -> manager joe blogs ->user joe blogs ->report test user ->user test user ->report privilege table: 1. monthly,view 2. stopwatch, view 3. clockings, edit 4. reports, view privilege assignment: reporter -> 4 (reports,view) granted user ->1 (...) granted user ->2 granted manager ->3 granted test user ->4 denied If a request to access an area that hasn't been defined in a users access control list then it is a denied access. If a user is denied access at any point that is it. Denied. i.e. test user above is granted access to reports through the reports group but is denied access on a specific user basis. Therefore he is denied access. A deny should always overrule an allow in my opinion. The (monthly, view) bit is just a way of allowing pseudo groups of privileges to exist so that they can be searched more easily. The fact that it is two fields 'monthly', 'view' has no real effect. In terms of default user groups this would be configured. An unlogged in user is part of the group guest. A new signup is part of the group user. So therefore I would add an extra group above 'tsx_users' so that a new signup has to request access to be able to start using the timesheet functions. Alternatively an admin could register a new user and give them access straight away. Please could I have some feedback on my proposed update? Regards Mark Wrightson |
|
From: Mark W. <ma...@rw...> - 2011-02-17 09:33:03
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Peter, <br>
<br>
The privilege levels i.e. user, reporter, manager, administrator
would be created as different user groups. A user can be a member
of several groups.<br>
<br>
so<br>
user table:<br>
1 admin<br>
2 joe bloggs<br>
3. test user<br>
<br>
user group table:<br>
guest<br>
user<br>
reporter<br>
manager<br>
admin<br>
<br>
user group assignment<br>
admin -> administrator<br>
admin -> manager<br>
joe blogs ->user<br>
joe blogs ->report<br>
test user ->user<br>
test user ->report<br>
<br>
privilege table:<br>
1. monthly,view<br>
2. stopwatch, view<br>
3. clockings, edit<br>
4. reports, view <br>
<br>
<br>
privilege assignment:<br>
reporter -> 4 (reports,view) granted<br>
user ->1 (...) granted<br>
user ->2 granted<br>
manager ->3 granted<br>
test user ->4 denied<br>
<br>
<br>
If a request to access an area that hasn't been defined in a users
access control list then it is a denied access.<br>
If a user is denied access at any point that is it. Denied. i.e.
test user above is granted access to reports through the reports
group but<br>
is denied access on a specific user basis. Therefore he is denied
access. A deny should always overrule an allow in my opinion.<br>
<br>
The (monthly, view) bit is just a way of allowing pseudo groups of
privileges to exist so that they can be searched more easily. The
fact that<br>
it is two fields 'monthly', 'view' has no real effect.<br>
<br>
In terms of default user groups this would be configured. An
unlogged in user is part of the group guest. A new signup is part
of the group user.<br>
So therefore I would add an extra group above 'tsx_users' so that a
new signup has to request access to be able to start using the
timesheet functions. Alternatively an admin could register a new
user and give them access straight away.<br>
<br>
Please could I have some feedback on my proposed update?<br>
<br>
Regards<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 17/02/2011 07:32, Peter Lazarus wrote:
<blockquote cite="mid:4D5...@gm..." type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
Mark,<br>
I have some questions about how privileges are defined, mostly to
try and understand how this design hangs together.<br>
<br>
In the privileges table example below you show 'monthly' which
relates to the php script or form to be used. And 'view', being
the privilege level etc. So if these are just text type fields,
then different privilege levels can be easily added later as
required. And the privileges table defines all allowed
combinations of privilege level and form name and whether they are
granted or not. <br>
<br>
Now a user can be linked to a usergroup, or not, or is there a
default usergroup? Then priviliges are linked by the privilege
assigments table. So an individual user could have his privileges
defined either by the group he belongs to, by individual
privileges, or by an individual privilege over-riding the group
privilege?<br>
<br>
Another question I have on this design is how will a hierarchy of
user types and privileges be defined? <br>
<br>
Now you may well have solved all these issues. It's just that I'm
trying to understand how it hangs together.<br>
<br>
Peter <br>
<br>
<br>
On 17/02/11 05:40, Mark Wrightson wrote:
<blockquote cite="mid:4D5...@rw..."
type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
Hi Scott, <br>
<br>
Agreed that the authentication model needs an update. I have
already done half the work required to do exactly this.<br>
In the code you will see an include/auth/auth.class.php which
is currently a stub class waiting to have some more code added
in.<br>
(the code is already written, i didn't want to change it until
there was a robust way of sending database updates to
developers).<br>
<br>
The way it works is<br>
<br>
a table of users<br>
a table of user groups<br>
a table assigning users to usergroups<br>
a table of privileges (i.e. monthly, viewpage, granted) more
specifically in the db('monthly', 'view','1')<br>
a table of privilege assignments that maps a privilege to
individual users or a user group.<br>
<br>
The structure is such that it is 100% expandable. The
inspiration for the structure was active directory.<br>
<br>
The only thing I haven't got as far as writing is a gui to
control the privileges. (if someone could help here maybe?)<br>
<br>
Along with the auth update is a menu system update to improve
how the menu is built. - drop down menus etc (database driven)<br>
The gui is complete for that bit.<br>
<br>
Finally I have an update for the login / logout scripts /
account management /registration / forgot password scripts.
More information to follow on that.<br>
<br>
Regards<br>
Mark<br>
<br>
<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 16/02/2011 16:58, Scott Miller wrote:
<blockquote
cite="mid:AANLkTikVQiZwMT85hL4hB1aV370QGXrjV2kF=B7...@ma..."
type="cite">I'm preparing to work on translating the existing
config database table into our new configuration table, and
when I went to start, I realized I'd worked on creating a new
security model and thus new security tables.<br>
<br>
So, currently our security model consists of each login being
give one of 3 access levels: user, manager, administrator.
Also, each page is given one of 4 access levels: user,
manager, administrator, none. To successfully get access to a
page, your access level must be greater than or equal to the
level the page has been given.<br>
<br>
Within the database, those accesses are defined via an ENUM
mechanism, and believe it was a mistake to use enums, because
if you want to add a new level, you have to modify the
database schema. I propose to eliminate the enums, and just
use raw integer values for the page and user access levels.<br>
<br>
2ndly I propose to take the page security definitions out of
the configuration table completely, and create a new page
security table. The security table would have the page name
and the default access, and I was intending to add a field to
determine whether the page name was allowed on the menu bar at
all.<br>
<br>
I had also thought that it would be nice, particularly for
some reports, to allow a security exception. I envisioned
this to be per user, and another new table would be needed.
username, pagename, and an access override code. The override
code was to be 0 - no access, 1- read access, 3 - read and
save access (it's a binary bit map (save, read) - 2 would be
save only, but without read that would be rather useless). I
envisioned a check in the code for each page would query if
there was an exception entry for the username/page, and if
not, normal access would be granted; if so, the override
access would be used.<br>
<br>
What do you all think about these proposals?<br>
<br>
-Scott<br>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Mark W. <ma...@rw...> - 2011-02-16 18:40:22
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
Agreed that the authentication model needs an update. I have
already done half the work required to do exactly this.<br>
In the code you will see an include/auth/auth.class.php which is
currently a stub class waiting to have some more code added in.<br>
(the code is already written, i didn't want to change it until there
was a robust way of sending database updates to developers).<br>
<br>
The way it works is<br>
<br>
a table of users<br>
a table of user groups<br>
a table assigning users to usergroups<br>
a table of privileges (i.e. monthly, viewpage, granted) more
specifically in the db('monthly', 'view','1')<br>
a table of privilege assignments that maps a privilege to individual
users or a user group.<br>
<br>
The structure is such that it is 100% expandable. The inspiration
for the structure was active directory.<br>
<br>
The only thing I haven't got as far as writing is a gui to control
the privileges. (if someone could help here maybe?)<br>
<br>
Along with the auth update is a menu system update to improve how
the menu is built. - drop down menus etc (database driven)<br>
The gui is complete for that bit.<br>
<br>
Finally I have an update for the login / logout scripts / account
management /registration / forgot password scripts. More
information to follow on that.<br>
<br>
Regards<br>
Mark<br>
<br>
<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 16/02/2011 16:58, Scott Miller wrote:
<blockquote
cite="mid:AANLkTikVQiZwMT85hL4hB1aV370QGXrjV2kF=B7...@ma..."
type="cite">I'm preparing to work on translating the existing
config database table into our new configuration table, and when I
went to start, I realized I'd worked on creating a new security
model and thus new security tables.<br>
<br>
So, currently our security model consists of each login being give
one of 3 access levels: user, manager, administrator. Also, each
page is given one of 4 access levels: user, manager,
administrator, none. To successfully get access to a page, your
access level must be greater than or equal to the level the page
has been given.<br>
<br>
Within the database, those accesses are defined via an ENUM
mechanism, and believe it was a mistake to use enums, because if
you want to add a new level, you have to modify the database
schema. I propose to eliminate the enums, and just use raw
integer values for the page and user access levels.<br>
<br>
2ndly I propose to take the page security definitions out of the
configuration table completely, and create a new page security
table. The security table would have the page name and the
default access, and I was intending to add a field to determine
whether the page name was allowed on the menu bar at all.<br>
<br>
I had also thought that it would be nice, particularly for some
reports, to allow a security exception. I envisioned this to be
per user, and another new table would be needed. username,
pagename, and an access override code. The override code was to
be 0 - no access, 1- read access, 3 - read and save access (it's a
binary bit map (save, read) - 2 would be save only, but without
read that would be rather useless). I envisioned a check in the
code for each page would query if there was an exception entry for
the username/page, and if not, normal access would be granted; if
so, the override access would be used.<br>
<br>
What do you all think about these proposals?<br>
<br>
-Scott<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-16 16:58:29
|
I'm preparing to work on translating the existing config database table into our new configuration table, and when I went to start, I realized I'd worked on creating a new security model and thus new security tables. So, currently our security model consists of each login being give one of 3 access levels: user, manager, administrator. Also, each page is given one of 4 access levels: user, manager, administrator, none. To successfully get access to a page, your access level must be greater than or equal to the level the page has been given. Within the database, those accesses are defined via an ENUM mechanism, and believe it was a mistake to use enums, because if you want to add a new level, you have to modify the database schema. I propose to eliminate the enums, and just use raw integer values for the page and user access levels. 2ndly I propose to take the page security definitions out of the configuration table completely, and create a new page security table. The security table would have the page name and the default access, and I was intending to add a field to determine whether the page name was allowed on the menu bar at all. I had also thought that it would be nice, particularly for some reports, to allow a security exception. I envisioned this to be per user, and another new table would be needed. username, pagename, and an access override code. The override code was to be 0 - no access, 1- read access, 3 - read and save access (it's a binary bit map (save, read) - 2 would be save only, but without read that would be rather useless). I envisioned a check in the code for each page would query if there was an exception entry for the username/page, and if not, normal access would be granted; if so, the override access would be used. What do you all think about these proposals? -Scott |
|
From: Mark W. <ma...@rw...> - 2011-02-16 01:29:53
|
The first stage of the config table update and the installer update has now been completed. Unfortunately this means that the installer in the txsheet-2.0-demo is currently not particularly functional. Warning messages and instructions will be displayed instead for the time being. When you next run an svn update the system should inform you that you need to manually modify your table_names.inc file and also run an sql script against your current db. Please let me know if all doesn't go to plan! Night Night! Mark Wrightson -- _____________________________________________ Mob: 07725 695178 Email: ma...@rw... |
|
From: Mark W. <ma...@rw...> - 2011-02-15 17:53:28
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
I think there is a potential security issue placing db credentials
in an ini file. The htaccess file has to be set to ensure that the
ini file cannot be seen from the outside, whereas if the credentials
are in a php file then this isn't a possibility. Where is the added
value of moving the relativeRoot and absoluteRoot into an array
called self::$roots? The relativeRoot and documentRoot are pretty
integral to how the paths throughout this version of tsng operate.
By merging them into an array, it starts to disguise exactly what
they do. At least with individual variables you get the javadoc
style comments that add understanding to the code. Also if
everything is properly commented in this fashion:<br>
<br>
/**<br>
* the document root is the filesystem path to the website
directory<br>
* i.e. /home/mark4703/public_html/minisite<br>
*/<br>
protected static $documentRoot;<br>
<br>
then the site codebase can be run through an app such as phpdoc to
generate a full set of API webpages. I assume you use eclipse so
get all the code auto completion features?<br>
<br>
I guess the config stuff could be reduced to less files. i.e.
config.class and config.factory.class could be merged into
config.class.php.<br>
We still need defaults for everything though and I think it would be
better to set them in config.factory.class rather than store them in
a ini. If all the defaults are present and then the config variables
are loaded on top, there is no chance of missing parameters.<br>
<br>
Do you not like the object orientated alternative to an ini?:<br>
parent::$dbServer = 'localhost';<br>
<br>
<br>
This is quite similar to how the db credentials are currently saved
and is the similar to how all the major php apps that I know of save
their configuration data, i.e. wordpress, mantis, xoops, drupal.<br>
<br>
Regards<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 15/02/2011 17:28, Scott Miller wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Oh, I'm also thinking we should attempt to put as much
config stuff into associative arrays as we can, so, I was starting
to look at moving the DB credentials into a $self->DB['user']
$self->DB['passwd'] etc type structure, and the relativeRoot,
absoluteRoot stuff into $self->Roots['relative'] structure...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 5:22 PM, Scott
Miller <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hey Mark,<br>
<br>
I'm in Omaha, NE, in the heart of the US<br>
<br>
I've been wrestling with understanding enough of the 2.0 stuff
to be able to put the "new" db config code into it so I could
check it in, but the heart of what I've done was in the
email. The rest was just using the public variables, which we
don't want to do that way.<br>
My vision would be to load the DB config from an INI file
using parse_ini_file, then init the DB with that info, then
load the config from the DB similar to what I'd already done,
then create get functions for the various config items.<br>
I'm currently thinking all that config loading stuff may as
well be in a single config class...<br>
<font color="#888888"><br>
-Scott</font>
<div>
<div class="h5"><br>
<br>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 5:16 PM,
Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">Hi Scott,<br>
<br>
I thought I would drop you an email to ask what
position you were in regards to updating the config
database table?<br>
last night in my work to update the installer I had to
write a small amount of code along the lines of what
you are working on.<br>
<br>
I made the following additions to config.class.php<br>
<br>
<br>
One new function:<br>
<br>
public static function getDbConfig(){<br>
<br>
$q = "SELECT * FROM ".tbl::getNewConfigTable();<br>
<br>
$data = Site::getDatabase()->sql($q,true,
MySQLDB::TYPE_OBJECT);<br>
if($data == MySQLDB::SQL_EMPTY || $data ==
MySQLDB::SQL_ERROR)return;<br>
<br>
foreach($data as $obj){<br>
<br>
if($obj->name == 'version'){<br>
parent::$databaseVersion =
$obj->value;<br>
self::runVersionCheck();<br>
}<br>
<br>
//more config variables to be stored into
the<br>
//config class or config.factory.class<br>
<br>
<br>
}<br>
<br>
<br>
}<br>
<br>
<br>
and in /index.php<br>
<br>
Config::getDbConfig(); on the line after the database
has been instantiated. (self::$database = new
MySQLDB();)<br>
<br>
so:<br>
self::$database = new MySQLDB();<br>
Config::getDbConfig();<br>
<br>
I realised that the database stored can't be done when
config is initialised as the database hasn't been
connected at this point.<br>
There is then a reverse dependency that prevents the
database from connecting until config has been
initialised.<br>
<br>
Therefore the program flow had to be:<br>
1. init Config<br>
2. init Database<br>
3. get database stored config<br>
<br>
What I would like to do is align this with the updates
you are working on. I have populated my new temporary
config table with just ('version','1.5.3')<br>
<br>
Finally, what country are you based in scott? I'm in
the UK.<br>
<br>
Cheers<br>
Mark<br>
<font color="#888888">
<br>
-- <br>
_____________________________________________<br>
<br>
Mob: 07725 695178<br>
Email: <a moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a><br>
<br>
</font></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-15 17:13:24
|
Apparently there's a php function called "parse_ini_file", documentation link: http://php.net/manual/en/function.parse-ini-file.php It appears to do the "heavy lifting" for supporting ini files for us. Should/could we use this instead of including configuration files? -Scott On Tue, Feb 15, 2011 at 5:08 PM, Mark Wrightson <ma...@rw...>wrote: > I forgot to reply to the rest.... > > The vision for config is to replace database_credentials completely and > store it in include/config/config.php. > By including the database_credentials, as it currently is, they aren't > global variables as they are loaded inside a class. > By doing this the included variables are only available in the function in > which the file was originally included. > They are then written to the Config class and that is the only place in > which they reside. > > I'm working on improving the installer at the moment which will allow the > modification or removal of files such as database_credentials.inc > The only reason they are being kept at the moment is to ensure the software > can still be installed and function for other developers. > The other main inspiration for upgrading the installer is that it really > annoys me that you have to delete the install folder for the application to > work. Instead i'm adding in hooks to detect whether the system is or isnt > yet installed and whether an upgrade is required. Last time I attempted to > use the installer I had all sorts of trouble and error messages and I hope > to clean this up a bit as well as make it look more pretty. > > include/config/config.php is more or less an object orientated ini file: > > config.php: > > parent::$dbServer = 'localhost'; > parent::$dbUser = 'username'; > parent::$dbPass = 'password'; > parent::$dbName = 'tsng'; > > Regards > Mark Wrightson > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 15/02/2011 16:01, Scott Miller wrote: > > Ok, I've been attempting to do two things: 1) figure out where the new > configuration class and code belonged and 2) understand how the loading of > pages through index.php works > > If you can shed some light on #2, I haven't gotten very far into exploring > that. > > On #1, I'm finally understanding how the existing config class works. > Currently index.php includes the database_credentials file, and then it uses > the class set routines to store the global variables into the class > variables. > > What is the vision for what this should look like when we're done? Should > the class be responsible for reading/including the file? Should the file > become more of an ini type file? Or are we happy with just including the > file to create global variables? > > I'm thinking if we're going through the work to encapsulate stuff, we would > want the class to be responsible for reading the data, and I would think > making it more of an ini file than one that pollutes the global name space > should be what we strive for, but I also don't want to start working on that > if there's been some decision that says we don't want to do that. > > -Scott > > On Tue, Feb 15, 2011 at 3:14 AM, Scott Miller <sco...@gm...>wrote: > >> Thanks for the link for various reasons for OO encapsulation. The points >> that were particularly swaying to me were: >> >> 1. You've insulated your public interface from changes under the >> sheets. >> 2. You can hide the internal representation. getAddress() could >> actually be getting several fields for you. >> 3. Inheriting this class, you can override default functionality. >> >> having gone through several iterations of changing needs/ideologies in my >> career, the ability to change things under the sheets, yet allowing the >> original code to continue to work... that's good engineering. >> >> -Scott >> >> >> >> On Mon, Feb 14, 2011 at 6:03 PM, Mark Wrightson <ma...@rw... >> > wrote: >> >>> Hi Scott, >>> >>> Don't worry, i won't take things personally, it is for the good of the >>> project at the end of the day. I have been playing around with wordpress >>> recently and here is their config table: >>> >>> CREATE TABLE IF NOT EXISTS `wp_options` ( >>> `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, >>> `blog_id` int(11) NOT NULL DEFAULT '0', >>> `option_name` varchar(64) NOT NULL DEFAULT '', >>> `option_value` longtext NOT NULL, >>> `autoload` varchar(20) NOT NULL DEFAULT 'yes', >>> PRIMARY KEY (`option_id`), >>> UNIQUE KEY `option_name` (`option_name`) >>> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=376 ; >>> >>> Now the thing that i think is an improvement here over your proposed >>> design (the only thing actually) is >>> the option_value is of type longtext and there is only one column for >>> value whereas you have three different fields for int, float and text. >>> Ultimately an int and a float can be stored as text and it would make no >>> difference to the end result. php decides by itself the type of a variable >>> anyway. By changing your config to one field it would im guessing simplify >>> the php that has to load everything in? or... is there good reason to have >>> three different fields in the db? >>> >>> In the config stuff in the demo, there really only needs to be one >>> additional function (a getter), there is no real need for a setter as a >>> config item shouldn't be changed by the system. There were a few setter >>> functions which have now been removed when I consolidated all the config >>> into config.factory.php, config.class.php and config.php. >>> >>> With reference to why you should use getters and /or setters, I have >>> found a nice article on stackoverflow. It relates to python but the article >>> is still 98% valid. There is more to it than just sloppy code. >>> >>> http://stackoverflow.com/questions/1568091/why-use-getters-and-setters >>> >>> An example in the current tsng code where a getter is very useful is the >>> Config::getWebmasterEmail() function. The code originally just returned the >>> email address until I realised that it was much better practice (for spam >>> reasons) to encode the email first. The encoding makes no difference to the >>> programmer or end user and it meant only a single line change rather than >>> having to change every call to the variable in the project. >>> >>> I do understand where you are coming from in regards to needing to add >>> more code everytime a new config item is introduced, but it does make for a >>> more robust system at the end of the day. I guess there is one alternative >>> (albeit not my favourite idea), it is possible when doing an sql query to >>> return an object instead of an array. The object is of type stdClass and >>> the member variables are all public. It is an alternative, but personally I >>> would not recommend using it for data that needs to be passed around every >>> class file in the project. >>> >>> The place where I now use the sql return as object command is when >>> grabbing data (for example) to display tables of information. The file >>> database.class.php file demonstrates this quite neatly. MySQLDB::sql() >>> line 158 - mysql_fetch_object($result) >>> >>> >>> Regards >>> >>> Mark Wrightson >>> >>> >>> >>> >>> >>> _____________________________________________ >>> >>> Mob: 07725 695178 >>> Email: ma...@rw... >>> >>> >>> On 14/02/2011 23:00, Scott Miller wrote: >>> >>> Absolutely, please don't take anything personally, I just want it to work >>> and work well. >>> >>> The one line change to the CSS worked a treat. Much better :-) >>> >>> So, ok, I'm not totally convinced of the OO stuff, so, please bear with >>> me. With my class to read in and store the configuration information, it >>> doesn't matter what is added to the configuration table in the database >>> everything is read in, and the class doesn't need to be edited every time >>> something new is added. Only when and where that new thing is needed do we >>> need to change code. >>> >>> In the version being championed by Peter and Mark, every new config item >>> needs two more functions to be added to the class, on top of the additional >>> code surrounding that item. >>> >>> I guess I'm more of a minimalist, I don't feel the added layer of extra >>> code, and extra function call for each config data look up, is a good trade >>> off to ensure against sloppy code. >>> >>> -Scott >>> >>> On Sun, Feb 13, 2011 at 12:40 PM, David Thompson < >>> tom...@us...> wrote: >>> >>>> Guys, try to keep your exchanges on the developer-list (that means >>>> checking the addressing when you reply). >>>> That way there is a (searchable) record for everyone to see what is >>>> going on. >>>> >>>> Critisism should be nothing personal (hard on the product, but soft on >>>> the person), in that way it can only make the software better. >>>> Cheers >>>> >>>> ------------------------------ >>>> Date: Sat, 12 Feb 2011 19:45:43 +1100 >>>> From: pal...@gm... >>>> To: sco...@gm... >>>> CC: ma...@rw...; tom...@us... >>>> Subject: [SPAM] Re: 2.0 demo feedback >>>> >>>> >>>> Scott, >>>> I agree also with this issue. I think it can be solved by continuing in >>>> the direction we are going. That is, to have minimal html structures and >>>> minimal html tables, and to use css includes to do all the formatting. I am >>>> not a css expert. In fact I would rate my css skills at below beginner. >>>> However the book I am reading, "CSS The Definitive Guide" by Eric Meyer >>>> (O'Reilly) has numerous examples where the styles are set up to allow >>>> expansion and contraction of table cells etc. So I have confidence we can >>>> fix the problem you raise. >>>> >>>> The next phase of the presentation is now to devise and test css styles >>>> to consistently format the monthly, daily, weekly and simple time entry >>>> tables. But that will take some time to organise. >>>> >>>> I would also like to "modernise" the menu system into a set of tabs, or >>>> maybe a hierarchical directory tree on the left. >>>> >>>> Finally, I'm soon to take off on a trip to colder places late this month >>>> and next, returning around 17 March. >>>> >>>> Ciao >>>> Peter >>>> >>>> On 12/02/11 07:51, Scott Miller wrote: >>>> >>>> (finally changed the subject) >>>> >>>> Another complaint: We need the site to be able to (mostly) fill a >>>> browser window. I have a large screen, and it irritates the begeezers out >>>> of me when I have a site that can only fill a small portion of my available >>>> screen. This is especially important for the simple timesheet where you >>>> have a potentially lengthy description field that suddenly becomes nearly >>>> unusable because the space available is tiny. Configurations, user mgmt, >>>> reports, all these need the ability to expand horizontally when they can. >>>> This may not be as important for all areas, but I think it would be bad form >>>> to allow variable pages only in a few areas... >>>> >>>> -Scott >>>> >>>> >>>> On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <sco...@gm... >>>> > wrote: >>>> >>>> Hey guys, >>>> >>>> Ok, admittedly, I'm not an OO guru. But, could you please explain why >>>> the table name class has been created in the way that it has? In >>>> particular, I'm totally failing to see how the many tiny routines to set and >>>> return the private variables is a good idea. Why not declare the variables >>>> public, and allow the other routines to access the table class variables >>>> directly? And we could have the class itself, read an appropriate .ini file >>>> to load the variables in the first place, rather than just including it as a >>>> php file as is currently done. >>>> >>>> Now if there were reasons to protect the members of the class, perhaps >>>> some of this is needed for the authentication piece, but I honestly can't >>>> come up with a good reason that most of the classes' variables couldn't be >>>> public. >>>> >>>> -Scott >>>> >>>> >>>> On Fri, Feb 11, 2011 at 7:38 PM, Scott Miller <sco...@gm... >>>> > wrote: >>>> >>>> Hey Peter, Mark, >>>> >>>> I just downloaded (checked out via svn) the 2.0-demo branch. I haven't >>>> played with it a lot, but for the most part it looks good. >>>> >>>> I do have to complain about the new date navigation. It looks ok, but >>>> it's a pain to use. I now have between 5 and 10 clicks of the mouse to >>>> change the date. That is, in my opinion, way too many; so I think that whole >>>> piece needs to be rethought. >>>> >>>> I'm going to go check out some of the code changes now, and maybe see if >>>> I can't add the new configuration stuff into your 2.0-demo... >>>> >>>> -Scott >>>> >>>> >>>> >>> >> > |
|
From: Mark W. <ma...@rw...> - 2011-02-15 17:08:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
I forgot to reply to the rest....<br>
<br>
The vision for config is to replace database_credentials completely
and store it in include/config/config.php.<br>
By including the database_credentials, as it currently is, they
aren't global variables as they are loaded inside a class.<br>
By doing this the included variables are only available in the
function in which the file was originally included.<br>
They are then written to the Config class and that is the only place
in which they reside.<br>
<br>
I'm working on improving the installer at the moment which will
allow the modification or removal of files such as
database_credentials.inc<br>
The only reason they are being kept at the moment is to ensure the
software can still be installed and function for other developers.<br>
The other main inspiration for upgrading the installer is that it
really annoys me that you have to delete the install folder for the
application to work. Instead i'm adding in hooks to detect whether
the system is or isnt yet installed and whether an upgrade is
required. Last time I attempted to use the installer I had all
sorts of trouble and error messages and I hope to clean this up a
bit as well as make it look more pretty.<br>
<br>
include/config/config.php is more or less an object orientated ini
file:<br>
<br>
config.php:<br>
<br>
parent::$dbServer = 'localhost';<br>
parent::$dbUser = 'username';<br>
parent::$dbPass = 'password';<br>
parent::$dbName = 'tsng'; <br>
<br>
Regards<br>
Mark Wrightson<br>
<pre class="moz-signature" cols="72">
_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 15/02/2011 16:01, Scott Miller wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Ok, I've been attempting to do two things: 1) figure
out where the new configuration class and code belonged and 2)
understand how the loading of pages through index.php works<br>
<br>
If you can shed some light on #2, I haven't gotten very far into
exploring that.<br>
<br>
On #1, I'm finally understanding how the existing config class
works. Currently index.php includes the database_credentials file,
and then it uses the class set routines to store the global
variables into the class variables. <br>
<br>
What is the vision for what this should look like when we're
done? Should the class be responsible for reading/including the
file? Should the file become more of an ini type file? Or are we
happy with just including the file to create global variables? <br>
<br>
I'm thinking if we're going through the work to encapsulate stuff,
we would want the class to be responsible for reading the data,
and I would think making it more of an ini file than one that
pollutes the global name space should be what we strive for, but I
also don't want to start working on that if there's been some
decision that says we don't want to do that.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 3:14 AM, Scott
Miller <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Thanks for the link for various reasons for OO encapsulation.
The points that were particularly swaying to me were:<br>
<ol>
<li>You've insulated your public interface from changes
under the sheets.</li>
<li>You can hide the internal representation. getAddress()
could actually be getting several fields for you.</li>
<li>Inheriting this class, you can override default
functionality.</li>
</ol>
having gone through several iterations of changing
needs/ideologies in my career, the ability to change things
under the sheets, yet allowing the original code to continue
to work... that's good engineering.<br>
<font color="#888888">
<br>
-Scott</font>
<div>
<div class="h5"><br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 14, 2011 at 6:03 PM,
Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Hi Scott, <br>
<br>
Don't worry, i won't take things personally, it is
for the good of the project at the end of the day.
I have been playing around with wordpress recently
and here is their config table:<br>
<br>
CREATE TABLE IF NOT EXISTS `wp_options` (<br>
`option_id` bigint(20) unsigned NOT NULL
AUTO_INCREMENT,<br>
`blog_id` int(11) NOT NULL DEFAULT '0',<br>
`option_name` varchar(64) NOT NULL DEFAULT '',<br>
`option_value` longtext NOT NULL,<br>
`autoload` varchar(20) NOT NULL DEFAULT 'yes',<br>
PRIMARY KEY (`option_id`),<br>
UNIQUE KEY `option_name` (`option_name`)<br>
) ENGINE=InnoDB DEFAULT CHARSET=utf8
AUTO_INCREMENT=376 ;<br>
<br>
Now the thing that i think is an improvement here
over your proposed design (the only thing actually)
is<br>
the option_value is of type longtext and there is
only one column for value whereas you have three
different fields for int, float and text.
Ultimately an int and a float can be stored as text
and it would make no difference to the end result.
php decides by itself the type of a variable
anyway. By changing your config to one field it
would im guessing simplify the php that has to load
everything in? or... is there good reason to have
three different fields in the db?<br>
<br>
In the config stuff in the demo, there really only
needs to be one additional function (a getter),
there is no real need for a setter as a config item
shouldn't be changed by the system. There were a
few setter functions which have now been removed
when I consolidated all the config into
config.factory.php, config.class.php and config.php.<br>
<br>
With reference to why you should use getters and /or
setters, I have found a nice article on
stackoverflow. It relates to python but the article
is still 98% valid. There is more to it than just
sloppy code.<br>
<br>
<a moz-do-not-send="true"
href="http://stackoverflow.com/questions/1568091/why-use-getters-and-setters"
target="_blank">http://stackoverflow.com/questions/1568091/why-use-getters-and-setters</a><br>
<br>
An example in the current tsng code where a getter
is very useful is the Config::getWebmasterEmail()
function. The code originally just returned the
email address until I realised that it was much
better practice (for spam reasons) to encode the
email first. The encoding makes no difference to
the programmer or end user and it meant only a
single line change rather than having to change
every call to the variable in the project.<br>
<br>
I do understand where you are coming from in regards
to needing to add more code everytime a new config
item is introduced, but it does make for a more
robust system at the end of the day. I guess there
is one alternative (albeit not my favourite idea),
it is possible when doing an sql query to return an
object instead of an array. The object is of type
stdClass and the member variables are all public.
It is an alternative, but personally I would not
recommend using it for data that needs to be passed
around every class file in the project. <br>
<br>
The place where I now use the sql return as object
command is when grabbing data (for example) to
display tables of information. The file<br>
database.class.php file demonstrates this quite
neatly. MySQLDB::sql() line 158 -
mysql_fetch_object($result)<br>
<br>
<br>
Regards<br>
<br>
Mark Wrightson<br>
<br>
<br>
<br>
<br>
<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div> <br>
On 14/02/2011 23:00, Scott Miller wrote:
<blockquote type="cite">Absolutely, please don't
take anything personally, I just want it to
work and work well.<br>
<br>
The one line change to the CSS worked a
treat. Much better :-)<br>
<br>
So, ok, I'm not totally convinced of the OO
stuff, so, please bear with me. With my class
to read in and store the configuration
information, it doesn't matter what is added
to the configuration table in the database
everything is read in, and the class doesn't
need to be edited every time something new is
added. Only when and where that new thing is
needed do we need to change code.<br>
<br>
In the version being championed by Peter and
Mark, every new config item needs two more
functions to be added to the class, on top of
the additional code surrounding that item.<br>
<br>
I guess I'm more of a minimalist, I don't feel
the added layer of extra code, and extra
function call for each config data look up, is
a good trade off to ensure against sloppy
code.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Sun, Feb 13, 2011
at 12:40 PM, David Thompson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:tom...@us..."
target="_blank">tom...@us...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div> Guys, try to keep your exchanges on
the developer-list (that means checking
the addressing when you reply).<br>
That way there is a (searchable) record
for everyone to see what is going on.<br>
<br>
Critisism should be nothing personal
(hard on the product, but soft on the
person), in that way it can only make
the software better.<br>
Cheers <br>
<br>
<hr> Date: Sat, 12 Feb 2011 19:45:43
+1100<br>
From: <a moz-do-not-send="true"
href="mailto:pal...@gm..."
target="_blank">pal...@gm...</a><br>
To: <a moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a><br>
CC: <a moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>;
<a moz-do-not-send="true"
href="mailto:tom...@us..."
target="_blank">tom...@us...</a><br>
Subject: [SPAM] Re: 2.0 demo feedback
<div>
<div><br>
<br>
Scott,<br>
I agree also with this issue. I
think it can be solved by continuing
in the direction we are going. That
is, to have minimal html structures
and minimal html tables, and to use
css includes to do all the
formatting. I am not a css expert.
In fact I would rate my css skills
at below beginner. However the book
I am reading, "CSS The Definitive
Guide" by Eric Meyer (O'Reilly) has
numerous examples where the styles
are set up to allow expansion and
contraction of table cells etc. So I
have confidence we can fix the
problem you raise.<br>
<br>
The next phase of the presentation
is now to devise and test css styles
to consistently format the monthly,
daily, weekly and simple time entry
tables. But that will take some time
to organise. <br>
<br>
I would also like to "modernise" the
menu system into a set of tabs, or
maybe a hierarchical directory tree
on the left.<br>
<br>
Finally, I'm soon to take off on a
trip to colder places late this
month and next, returning around 17
March.<br>
<br>
Ciao<br>
Peter<br>
<br>
On 12/02/11 07:51, Scott Miller
wrote:
<blockquote>(finally changed the
subject)<br>
<br>
Another complaint: We need the
site to be able to (mostly) fill a
browser window. I have a large
screen, and it irritates the
begeezers out of me when I have a
site that can only fill a small
portion of my available screen.
This is especially important for
the simple timesheet where you
have a potentially lengthy
description field that suddenly
becomes nearly unusable because
the space available is tiny.
Configurations, user mgmt,
reports, all these need the
ability to expand horizontally
when they can. This may not be as
important for all areas, but I
think it would be bad form to
allow variable pages only in a few
areas...<br>
<br>
-Scott<br>
<br>
<br>
<div>On Fri, Feb 11, 2011 at 8:24
PM, Scott Miller <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote style="padding-left:
1ex;">Hey guys,<br>
<br>
Ok, admittedly, I'm not an OO
guru. But, could you please
explain why the table name
class has been created in the
way that it has? In
particular, I'm totally
failing to see how the many
tiny routines to set and
return the private variables
is a good idea. Why not
declare the variables public,
and allow the other routines
to access the table class
variables directly? And we
could have the class itself,
read an appropriate .ini file
to load the variables in the
first place, rather than just
including it as a php file as
is currently done.<br>
<br>
Now if there were reasons to
protect the members of the
class, perhaps some of this is
needed for the authentication
piece, but I honestly can't
come up with a good reason
that most of the classes'
variables couldn't be public.<br>
<font color="#888888"><br>
-Scott</font>
<div>
<div><br>
<br>
<div>On Fri, Feb 11, 2011
at 7:38 PM, Scott Miller
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..." target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote
style="padding-left:
1ex;">Hey Peter, Mark,<br>
<br>
I just downloaded
(checked out via svn)
the 2.0-demo branch.
I haven't played with
it a lot, but for the
most part it looks
good.<br>
<br>
I do have to complain
about the new date
navigation. It looks
ok, but it's a pain to
use. I now have
between 5 and 10
clicks of the mouse to
change the date. That
is, in my opinion, way
too many; so I think
that whole piece needs
to be rethought.<br>
<br>
I'm going to go check
out some of the code
changes now, and maybe
see if I can't add the
new configuration
stuff into your
2.0-demo...<br>
<font color="#888888"><br>
-Scott<br>
<br>
</font><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Mark W. <ma...@rw...> - 2011-02-15 16:56:08
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
1. Please run an svn update, the database credentials include has
moved into the include/config/config.php to tidy up the root
index.php file.<br>
I have an update to tidy up the tables.class.php too but i'm working
on an update to the installer so i don't want to commit anything
just yet.<br>
<br>
There are three config files.<br>
<br>
include/config.factory.class.php - contains most of the code
and all the default parameters<br>
include/config.class.php - extends config.factory and
loads the user specific config (include/config/config.php)<br>
include/config/config.php - overrides the default
config in config.factory.class.php<br>
<br>
database_credentials is currently loaded in
include/config/config.php and used to update the db parameters in
config.factory.<br>
<br>
<br>
2. a step by step guide to loading a page<br>
<br>
Everything loads through /index.php<br>
Initialise the Error Handler<br>
Initialise Config<br>
Start the Session and Connect to the Database<br>
instantiate the authentication manager and the command menu<br>
initialise the globals class (this class just contains some
parameters like date month year that are used in every tsng page)<br>
<br>
rewrite class does the clever bit and works out which page should
actually load.<br>
<br>
TemplateParser loads the default theme (themes/txsheet/template.php)<br>
<br>
$tp->getPageElements()->addFile('content',self::$rewrite->getContent());<br>
$tp->getPageElements()->addFile('menu','themes/txsheet/menu.php');<br>
$tp->getPageElements()->addFile('tsx_footer','themes/txsheet/footer.inc');<br>
$tp->getPageElements()->addFile('tsx_banner','themes/txsheet/banner.inc');<br>
<br>
the above lines tell the templateparser which files need to be
loaded and parsed to populate the template. If you look in the
template there are various tags like : {content}, {menu} etc.<br>
The template parser effectively does a find and replace and replaces
these tags with the content from the files set in the above lines of
code.<br>
<br>
That is a very short description on how it works.<br>
Something that may be useful is to have a look at
include/debug.class.php<br>
In there you can turn on the rewrite debug output, and the
templateparser debug output to see exactly what it is doing in a
verbose format.<br>
<br>
Finally the other really useful debug statement is the sqlStatement
parameter which makes all sql queries display the query in the
website.<br>
I have some code to upgrade debug such that all the debug output
will appear in a console rather than mixed in with the html output.<br>
I tend to find sometimes it is nice to have debug info embedded and
other times with the info separated.<br>
<br>
Once more thing. There is more functionality in the rewrite,
templateparser and index.php that enables the inclusion of extra
'modules' of code. TSNG doesn't (yet) have any need for this. When
we get to a more stable point, I hope to write some code to make use
of these features.<br>
<br>
Regards<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 15/02/2011 16:01, Scott Miller wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Ok, I've been attempting to do two things: 1) figure
out where the new configuration class and code belonged and 2)
understand how the loading of pages through index.php works<br>
<br>
If you can shed some light on #2, I haven't gotten very far into
exploring that.<br>
<br>
On #1, I'm finally understanding how the existing config class
works. Currently index.php includes the database_credentials file,
and then it uses the class set routines to store the global
variables into the class variables. <br>
<br>
What is the vision for what this should look like when we're
done? Should the class be responsible for reading/including the
file? Should the file become more of an ini type file? Or are we
happy with just including the file to create global variables? <br>
<br>
I'm thinking if we're going through the work to encapsulate stuff,
we would want the class to be responsible for reading the data,
and I would think making it more of an ini file than one that
pollutes the global name space should be what we strive for, but I
also don't want to start working on that if there's been some
decision that says we don't want to do that.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Feb 15, 2011 at 3:14 AM, Scott
Miller <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm...">sco...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Thanks for the link for various reasons for OO encapsulation.
The points that were particularly swaying to me were:<br>
<ol>
<li>You've insulated your public interface from changes
under the sheets.</li>
<li>You can hide the internal representation. getAddress()
could actually be getting several fields for you.</li>
<li>Inheriting this class, you can override default
functionality.</li>
</ol>
having gone through several iterations of changing
needs/ideologies in my career, the ability to change things
under the sheets, yet allowing the original code to continue
to work... that's good engineering.<br>
<font color="#888888">
<br>
-Scott</font>
<div>
<div class="h5"><br>
<br>
<br>
<div class="gmail_quote">On Mon, Feb 14, 2011 at 6:03 PM,
Mark Wrightson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div text="#000000" bgcolor="#ffffff"> Hi Scott, <br>
<br>
Don't worry, i won't take things personally, it is
for the good of the project at the end of the day.
I have been playing around with wordpress recently
and here is their config table:<br>
<br>
CREATE TABLE IF NOT EXISTS `wp_options` (<br>
`option_id` bigint(20) unsigned NOT NULL
AUTO_INCREMENT,<br>
`blog_id` int(11) NOT NULL DEFAULT '0',<br>
`option_name` varchar(64) NOT NULL DEFAULT '',<br>
`option_value` longtext NOT NULL,<br>
`autoload` varchar(20) NOT NULL DEFAULT 'yes',<br>
PRIMARY KEY (`option_id`),<br>
UNIQUE KEY `option_name` (`option_name`)<br>
) ENGINE=InnoDB DEFAULT CHARSET=utf8
AUTO_INCREMENT=376 ;<br>
<br>
Now the thing that i think is an improvement here
over your proposed design (the only thing actually)
is<br>
the option_value is of type longtext and there is
only one column for value whereas you have three
different fields for int, float and text.
Ultimately an int and a float can be stored as text
and it would make no difference to the end result.
php decides by itself the type of a variable
anyway. By changing your config to one field it
would im guessing simplify the php that has to load
everything in? or... is there good reason to have
three different fields in the db?<br>
<br>
In the config stuff in the demo, there really only
needs to be one additional function (a getter),
there is no real need for a setter as a config item
shouldn't be changed by the system. There were a
few setter functions which have now been removed
when I consolidated all the config into
config.factory.php, config.class.php and config.php.<br>
<br>
With reference to why you should use getters and /or
setters, I have found a nice article on
stackoverflow. It relates to python but the article
is still 98% valid. There is more to it than just
sloppy code.<br>
<br>
<a moz-do-not-send="true"
href="http://stackoverflow.com/questions/1568091/why-use-getters-and-setters"
target="_blank">http://stackoverflow.com/questions/1568091/why-use-getters-and-setters</a><br>
<br>
An example in the current tsng code where a getter
is very useful is the Config::getWebmasterEmail()
function. The code originally just returned the
email address until I realised that it was much
better practice (for spam reasons) to encode the
email first. The encoding makes no difference to
the programmer or end user and it meant only a
single line change rather than having to change
every call to the variable in the project.<br>
<br>
I do understand where you are coming from in regards
to needing to add more code everytime a new config
item is introduced, but it does make for a more
robust system at the end of the day. I guess there
is one alternative (albeit not my favourite idea),
it is possible when doing an sql query to return an
object instead of an array. The object is of type
stdClass and the member variables are all public.
It is an alternative, but personally I would not
recommend using it for data that needs to be passed
around every class file in the project. <br>
<br>
The place where I now use the sql return as object
command is when grabbing data (for example) to
display tables of information. The file<br>
database.class.php file demonstrates this quite
neatly. MySQLDB::sql() line 158 -
mysql_fetch_object($result)<br>
<br>
<br>
Regards<br>
<br>
Mark Wrightson<br>
<br>
<br>
<br>
<br>
<br>
<pre cols="72">_____________________________________________
Mob: 07725 695178
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div> <br>
On 14/02/2011 23:00, Scott Miller wrote:
<blockquote type="cite">Absolutely, please don't
take anything personally, I just want it to
work and work well.<br>
<br>
The one line change to the CSS worked a
treat. Much better :-)<br>
<br>
So, ok, I'm not totally convinced of the OO
stuff, so, please bear with me. With my class
to read in and store the configuration
information, it doesn't matter what is added
to the configuration table in the database
everything is read in, and the class doesn't
need to be edited every time something new is
added. Only when and where that new thing is
needed do we need to change code.<br>
<br>
In the version being championed by Peter and
Mark, every new config item needs two more
functions to be added to the class, on top of
the additional code surrounding that item.<br>
<br>
I guess I'm more of a minimalist, I don't feel
the added layer of extra code, and extra
function call for each config data look up, is
a good trade off to ensure against sloppy
code.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Sun, Feb 13, 2011
at 12:40 PM, David Thompson <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:tom...@us..."
target="_blank">tom...@us...</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div> Guys, try to keep your exchanges on
the developer-list (that means checking
the addressing when you reply).<br>
That way there is a (searchable) record
for everyone to see what is going on.<br>
<br>
Critisism should be nothing personal
(hard on the product, but soft on the
person), in that way it can only make
the software better.<br>
Cheers <br>
<br>
<hr> Date: Sat, 12 Feb 2011 19:45:43
+1100<br>
From: <a moz-do-not-send="true"
href="mailto:pal...@gm..."
target="_blank">pal...@gm...</a><br>
To: <a moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a><br>
CC: <a moz-do-not-send="true"
href="mailto:ma...@rw..."
target="_blank">ma...@rw...</a>;
<a moz-do-not-send="true"
href="mailto:tom...@us..."
target="_blank">tom...@us...</a><br>
Subject: [SPAM] Re: 2.0 demo feedback
<div>
<div><br>
<br>
Scott,<br>
I agree also with this issue. I
think it can be solved by continuing
in the direction we are going. That
is, to have minimal html structures
and minimal html tables, and to use
css includes to do all the
formatting. I am not a css expert.
In fact I would rate my css skills
at below beginner. However the book
I am reading, "CSS The Definitive
Guide" by Eric Meyer (O'Reilly) has
numerous examples where the styles
are set up to allow expansion and
contraction of table cells etc. So I
have confidence we can fix the
problem you raise.<br>
<br>
The next phase of the presentation
is now to devise and test css styles
to consistently format the monthly,
daily, weekly and simple time entry
tables. But that will take some time
to organise. <br>
<br>
I would also like to "modernise" the
menu system into a set of tabs, or
maybe a hierarchical directory tree
on the left.<br>
<br>
Finally, I'm soon to take off on a
trip to colder places late this
month and next, returning around 17
March.<br>
<br>
Ciao<br>
Peter<br>
<br>
On 12/02/11 07:51, Scott Miller
wrote:
<blockquote>(finally changed the
subject)<br>
<br>
Another complaint: We need the
site to be able to (mostly) fill a
browser window. I have a large
screen, and it irritates the
begeezers out of me when I have a
site that can only fill a small
portion of my available screen.
This is especially important for
the simple timesheet where you
have a potentially lengthy
description field that suddenly
becomes nearly unusable because
the space available is tiny.
Configurations, user mgmt,
reports, all these need the
ability to expand horizontally
when they can. This may not be as
important for all areas, but I
think it would be bad form to
allow variable pages only in a few
areas...<br>
<br>
-Scott<br>
<br>
<br>
<div>On Fri, Feb 11, 2011 at 8:24
PM, Scott Miller <span
dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote style="padding-left:
1ex;">Hey guys,<br>
<br>
Ok, admittedly, I'm not an OO
guru. But, could you please
explain why the table name
class has been created in the
way that it has? In
particular, I'm totally
failing to see how the many
tiny routines to set and
return the private variables
is a good idea. Why not
declare the variables public,
and allow the other routines
to access the table class
variables directly? And we
could have the class itself,
read an appropriate .ini file
to load the variables in the
first place, rather than just
including it as a php file as
is currently done.<br>
<br>
Now if there were reasons to
protect the members of the
class, perhaps some of this is
needed for the authentication
piece, but I honestly can't
come up with a good reason
that most of the classes'
variables couldn't be public.<br>
<font color="#888888"><br>
-Scott</font>
<div>
<div><br>
<br>
<div>On Fri, Feb 11, 2011
at 7:38 PM, Scott Miller
<span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..." target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote
style="padding-left:
1ex;">Hey Peter, Mark,<br>
<br>
I just downloaded
(checked out via svn)
the 2.0-demo branch.
I haven't played with
it a lot, but for the
most part it looks
good.<br>
<br>
I do have to complain
about the new date
navigation. It looks
ok, but it's a pain to
use. I now have
between 5 and 10
clicks of the mouse to
change the date. That
is, in my opinion, way
too many; so I think
that whole piece needs
to be rethought.<br>
<br>
I'm going to go check
out some of the code
changes now, and maybe
see if I can't add the
new configuration
stuff into your
2.0-demo...<br>
<font color="#888888"><br>
-Scott<br>
<br>
</font><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-15 16:53:10
|
Right, good, I just wanted to make sure we weren't going down the road of "all tables are bad". -Scott On Tue, Feb 15, 2011 at 4:35 PM, Mark Wrightson <ma...@rw...>wrote: > Hi Scott, > > What Peter meant is that when the time sheet face stuff was in there there > was tables within tables within tables to such an extent that nothing could > be changed. There is still place for tabular structures within tsng i.e. > google calendars uses tables. Why shouldn't we? Peter has been trimming > down the use of nested tables in an effort to updating the styling of the > system. > > Regards > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 15/02/2011 15:29, Scott Miller wrote: > > Hey all, > > In the list of work items for 2.0 was Peter had written: "TSNG uses html > tables to format the web pages. Unfortunately tables have been used to > excessive degree such that there are many nested tables. Some work has been > done to replace this table nesting. This cleanup of the html is necessary to > move to the next step of using css to do the formatting." > > So, again, I'm not a CSS expert, but I have worked with it enough, and read > enough to believe the following is true: there are some things that tables > can do that CSS can not. Specifically, CSS can not give you many equal > width columns for a tabular layout. So, while I think that removing the > over reliance on tables is a good thing, I think the movement to shun all > tables that seems to be rampant within the CSS community, is going a bit to > far. There are several places, the simple timesheet and reports to name just > two, that I believe are going to require tables. > > So, does this make sense, or am I mistaken? > > -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 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 > > |
|
From: Mark W. <ma...@rw...> - 2011-02-15 16:35:21
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
What Peter meant is that when the time sheet face stuff was in there
there was tables within tables within tables to such an extent that
nothing could be changed. There is still place for tabular
structures within tsng i.e. google calendars uses tables. Why
shouldn't we? Peter has been trimming down the use of nested tables
in an effort to updating the styling of the system.<br>
<br>
Regards<br>
Mark<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 15/02/2011 15:29, Scott Miller wrote:
<blockquote
cite="mid:AANLkTinucYE6Vz3mBuuroEO=1Uffyeu1y6_hr2=2F...@ma..."
type="cite">Hey all,<br>
<br>
In the list of work items for 2.0 was Peter had written: "TSNG
uses html tables to format the web pages. Unfortunately tables
have been used to excessive degree such that there are many nested
tables. Some work has been done to replace this table nesting.
This cleanup of the html is necessary to move to the next step of
using css to do the formatting."<br>
<br>
So, again, I'm not a CSS expert, but I have worked with it enough,
and read enough to believe the following is true: there are some
things that tables can do that CSS can not. Specifically, CSS can
not give you many equal width columns for a tabular layout. So,
while I think that removing the over reliance on tables is a good
thing, I think the movement to shun all tables that seems to be
rampant within the CSS community, is going a bit to far. There are
several places, the simple timesheet and reports to name just two,
that I believe are going to require tables.<br>
<br>
So, does this make sense, or am I mistaken?<br>
<br>
-Scott<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
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.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/intel-dev2devfeb">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Tsheetx-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Tsh...@li...">Tsh...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Scott M. <sco...@gm...> - 2011-02-15 16:01:51
|
Ok, I've been attempting to do two things: 1) figure out where the new configuration class and code belonged and 2) understand how the loading of pages through index.php works If you can shed some light on #2, I haven't gotten very far into exploring that. On #1, I'm finally understanding how the existing config class works. Currently index.php includes the database_credentials file, and then it uses the class set routines to store the global variables into the class variables. What is the vision for what this should look like when we're done? Should the class be responsible for reading/including the file? Should the file become more of an ini type file? Or are we happy with just including the file to create global variables? I'm thinking if we're going through the work to encapsulate stuff, we would want the class to be responsible for reading the data, and I would think making it more of an ini file than one that pollutes the global name space should be what we strive for, but I also don't want to start working on that if there's been some decision that says we don't want to do that. -Scott On Tue, Feb 15, 2011 at 3:14 AM, Scott Miller <sco...@gm...>wrote: > Thanks for the link for various reasons for OO encapsulation. The points > that were particularly swaying to me were: > > 1. You've insulated your public interface from changes under the > sheets. > 2. You can hide the internal representation. getAddress() could > actually be getting several fields for you. > 3. Inheriting this class, you can override default functionality. > > having gone through several iterations of changing needs/ideologies in my > career, the ability to change things under the sheets, yet allowing the > original code to continue to work... that's good engineering. > > -Scott > > > > On Mon, Feb 14, 2011 at 6:03 PM, Mark Wrightson <ma...@rw...>wrote: > >> Hi Scott, >> >> Don't worry, i won't take things personally, it is for the good of the >> project at the end of the day. I have been playing around with wordpress >> recently and here is their config table: >> >> CREATE TABLE IF NOT EXISTS `wp_options` ( >> `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, >> `blog_id` int(11) NOT NULL DEFAULT '0', >> `option_name` varchar(64) NOT NULL DEFAULT '', >> `option_value` longtext NOT NULL, >> `autoload` varchar(20) NOT NULL DEFAULT 'yes', >> PRIMARY KEY (`option_id`), >> UNIQUE KEY `option_name` (`option_name`) >> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=376 ; >> >> Now the thing that i think is an improvement here over your proposed >> design (the only thing actually) is >> the option_value is of type longtext and there is only one column for >> value whereas you have three different fields for int, float and text. >> Ultimately an int and a float can be stored as text and it would make no >> difference to the end result. php decides by itself the type of a variable >> anyway. By changing your config to one field it would im guessing simplify >> the php that has to load everything in? or... is there good reason to have >> three different fields in the db? >> >> In the config stuff in the demo, there really only needs to be one >> additional function (a getter), there is no real need for a setter as a >> config item shouldn't be changed by the system. There were a few setter >> functions which have now been removed when I consolidated all the config >> into config.factory.php, config.class.php and config.php. >> >> With reference to why you should use getters and /or setters, I have found >> a nice article on stackoverflow. It relates to python but the article is >> still 98% valid. There is more to it than just sloppy code. >> >> http://stackoverflow.com/questions/1568091/why-use-getters-and-setters >> >> An example in the current tsng code where a getter is very useful is the >> Config::getWebmasterEmail() function. The code originally just returned the >> email address until I realised that it was much better practice (for spam >> reasons) to encode the email first. The encoding makes no difference to the >> programmer or end user and it meant only a single line change rather than >> having to change every call to the variable in the project. >> >> I do understand where you are coming from in regards to needing to add >> more code everytime a new config item is introduced, but it does make for a >> more robust system at the end of the day. I guess there is one alternative >> (albeit not my favourite idea), it is possible when doing an sql query to >> return an object instead of an array. The object is of type stdClass and >> the member variables are all public. It is an alternative, but personally I >> would not recommend using it for data that needs to be passed around every >> class file in the project. >> >> The place where I now use the sql return as object command is when >> grabbing data (for example) to display tables of information. The file >> database.class.php file demonstrates this quite neatly. MySQLDB::sql() >> line 158 - mysql_fetch_object($result) >> >> >> Regards >> >> Mark Wrightson >> >> >> >> >> >> _____________________________________________ >> >> Mob: 07725 695178 >> Email: ma...@rw... >> >> >> On 14/02/2011 23:00, Scott Miller wrote: >> >> Absolutely, please don't take anything personally, I just want it to work >> and work well. >> >> The one line change to the CSS worked a treat. Much better :-) >> >> So, ok, I'm not totally convinced of the OO stuff, so, please bear with >> me. With my class to read in and store the configuration information, it >> doesn't matter what is added to the configuration table in the database >> everything is read in, and the class doesn't need to be edited every time >> something new is added. Only when and where that new thing is needed do we >> need to change code. >> >> In the version being championed by Peter and Mark, every new config item >> needs two more functions to be added to the class, on top of the additional >> code surrounding that item. >> >> I guess I'm more of a minimalist, I don't feel the added layer of extra >> code, and extra function call for each config data look up, is a good trade >> off to ensure against sloppy code. >> >> -Scott >> >> On Sun, Feb 13, 2011 at 12:40 PM, David Thompson < >> tom...@us...> wrote: >> >>> Guys, try to keep your exchanges on the developer-list (that means >>> checking the addressing when you reply). >>> That way there is a (searchable) record for everyone to see what is going >>> on. >>> >>> Critisism should be nothing personal (hard on the product, but soft on >>> the person), in that way it can only make the software better. >>> Cheers >>> >>> ------------------------------ >>> Date: Sat, 12 Feb 2011 19:45:43 +1100 >>> From: pal...@gm... >>> To: sco...@gm... >>> CC: ma...@rw...; tom...@us... >>> Subject: [SPAM] Re: 2.0 demo feedback >>> >>> >>> Scott, >>> I agree also with this issue. I think it can be solved by continuing in >>> the direction we are going. That is, to have minimal html structures and >>> minimal html tables, and to use css includes to do all the formatting. I am >>> not a css expert. In fact I would rate my css skills at below beginner. >>> However the book I am reading, "CSS The Definitive Guide" by Eric Meyer >>> (O'Reilly) has numerous examples where the styles are set up to allow >>> expansion and contraction of table cells etc. So I have confidence we can >>> fix the problem you raise. >>> >>> The next phase of the presentation is now to devise and test css styles >>> to consistently format the monthly, daily, weekly and simple time entry >>> tables. But that will take some time to organise. >>> >>> I would also like to "modernise" the menu system into a set of tabs, or >>> maybe a hierarchical directory tree on the left. >>> >>> Finally, I'm soon to take off on a trip to colder places late this month >>> and next, returning around 17 March. >>> >>> Ciao >>> Peter >>> >>> On 12/02/11 07:51, Scott Miller wrote: >>> >>> (finally changed the subject) >>> >>> Another complaint: We need the site to be able to (mostly) fill a >>> browser window. I have a large screen, and it irritates the begeezers out >>> of me when I have a site that can only fill a small portion of my available >>> screen. This is especially important for the simple timesheet where you >>> have a potentially lengthy description field that suddenly becomes nearly >>> unusable because the space available is tiny. Configurations, user mgmt, >>> reports, all these need the ability to expand horizontally when they can. >>> This may not be as important for all areas, but I think it would be bad form >>> to allow variable pages only in a few areas... >>> >>> -Scott >>> >>> >>> On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <sco...@gm...>wrote: >>> >>> Hey guys, >>> >>> Ok, admittedly, I'm not an OO guru. But, could you please explain why >>> the table name class has been created in the way that it has? In >>> particular, I'm totally failing to see how the many tiny routines to set and >>> return the private variables is a good idea. Why not declare the variables >>> public, and allow the other routines to access the table class variables >>> directly? And we could have the class itself, read an appropriate .ini file >>> to load the variables in the first place, rather than just including it as a >>> php file as is currently done. >>> >>> Now if there were reasons to protect the members of the class, perhaps >>> some of this is needed for the authentication piece, but I honestly can't >>> come up with a good reason that most of the classes' variables couldn't be >>> public. >>> >>> -Scott >>> >>> >>> On Fri, Feb 11, 2011 at 7:38 PM, Scott Miller <sco...@gm...>wrote: >>> >>> Hey Peter, Mark, >>> >>> I just downloaded (checked out via svn) the 2.0-demo branch. I haven't >>> played with it a lot, but for the most part it looks good. >>> >>> I do have to complain about the new date navigation. It looks ok, but >>> it's a pain to use. I now have between 5 and 10 clicks of the mouse to >>> change the date. That is, in my opinion, way too many; so I think that whole >>> piece needs to be rethought. >>> >>> I'm going to go check out some of the code changes now, and maybe see if >>> I can't add the new configuration stuff into your 2.0-demo... >>> >>> -Scott >>> >>> >>> >> > |
|
From: Scott M. <sco...@gm...> - 2011-02-15 15:29:41
|
Hey all, In the list of work items for 2.0 was Peter had written: "TSNG uses html tables to format the web pages. Unfortunately tables have been used to excessive degree such that there are many nested tables. Some work has been done to replace this table nesting. This cleanup of the html is necessary to move to the next step of using css to do the formatting." So, again, I'm not a CSS expert, but I have worked with it enough, and read enough to believe the following is true: there are some things that tables can do that CSS can not. Specifically, CSS can not give you many equal width columns for a tabular layout. So, while I think that removing the over reliance on tables is a good thing, I think the movement to shun all tables that seems to be rampant within the CSS community, is going a bit to far. There are several places, the simple timesheet and reports to name just two, that I believe are going to require tables. So, does this make sense, or am I mistaken? -Scott |
|
From: Scott M. <sco...@gm...> - 2011-02-15 03:14:56
|
Thanks for the link for various reasons for OO encapsulation. The points that were particularly swaying to me were: 1. You've insulated your public interface from changes under the sheets. 2. You can hide the internal representation. getAddress() could actually be getting several fields for you. 3. Inheriting this class, you can override default functionality. having gone through several iterations of changing needs/ideologies in my career, the ability to change things under the sheets, yet allowing the original code to continue to work... that's good engineering. -Scott On Mon, Feb 14, 2011 at 6:03 PM, Mark Wrightson <ma...@rw...>wrote: > Hi Scott, > > Don't worry, i won't take things personally, it is for the good of the > project at the end of the day. I have been playing around with wordpress > recently and here is their config table: > > CREATE TABLE IF NOT EXISTS `wp_options` ( > `option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, > `blog_id` int(11) NOT NULL DEFAULT '0', > `option_name` varchar(64) NOT NULL DEFAULT '', > `option_value` longtext NOT NULL, > `autoload` varchar(20) NOT NULL DEFAULT 'yes', > PRIMARY KEY (`option_id`), > UNIQUE KEY `option_name` (`option_name`) > ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=376 ; > > Now the thing that i think is an improvement here over your proposed design > (the only thing actually) is > the option_value is of type longtext and there is only one column for value > whereas you have three different fields for int, float and text. Ultimately > an int and a float can be stored as text and it would make no difference to > the end result. php decides by itself the type of a variable anyway. By > changing your config to one field it would im guessing simplify the php that > has to load everything in? or... is there good reason to have three > different fields in the db? > > In the config stuff in the demo, there really only needs to be one > additional function (a getter), there is no real need for a setter as a > config item shouldn't be changed by the system. There were a few setter > functions which have now been removed when I consolidated all the config > into config.factory.php, config.class.php and config.php. > > With reference to why you should use getters and /or setters, I have found > a nice article on stackoverflow. It relates to python but the article is > still 98% valid. There is more to it than just sloppy code. > > http://stackoverflow.com/questions/1568091/why-use-getters-and-setters > > An example in the current tsng code where a getter is very useful is the > Config::getWebmasterEmail() function. The code originally just returned the > email address until I realised that it was much better practice (for spam > reasons) to encode the email first. The encoding makes no difference to the > programmer or end user and it meant only a single line change rather than > having to change every call to the variable in the project. > > I do understand where you are coming from in regards to needing to add more > code everytime a new config item is introduced, but it does make for a more > robust system at the end of the day. I guess there is one alternative > (albeit not my favourite idea), it is possible when doing an sql query to > return an object instead of an array. The object is of type stdClass and > the member variables are all public. It is an alternative, but personally I > would not recommend using it for data that needs to be passed around every > class file in the project. > > The place where I now use the sql return as object command is when grabbing > data (for example) to display tables of information. The file > database.class.php file demonstrates this quite neatly. MySQLDB::sql() > line 158 - mysql_fetch_object($result) > > > Regards > > Mark Wrightson > > > > > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 14/02/2011 23:00, Scott Miller wrote: > > Absolutely, please don't take anything personally, I just want it to work > and work well. > > The one line change to the CSS worked a treat. Much better :-) > > So, ok, I'm not totally convinced of the OO stuff, so, please bear with > me. With my class to read in and store the configuration information, it > doesn't matter what is added to the configuration table in the database > everything is read in, and the class doesn't need to be edited every time > something new is added. Only when and where that new thing is needed do we > need to change code. > > In the version being championed by Peter and Mark, every new config item > needs two more functions to be added to the class, on top of the additional > code surrounding that item. > > I guess I'm more of a minimalist, I don't feel the added layer of extra > code, and extra function call for each config data look up, is a good trade > off to ensure against sloppy code. > > -Scott > > On Sun, Feb 13, 2011 at 12:40 PM, David Thompson < > tom...@us...> wrote: > >> Guys, try to keep your exchanges on the developer-list (that means >> checking the addressing when you reply). >> That way there is a (searchable) record for everyone to see what is going >> on. >> >> Critisism should be nothing personal (hard on the product, but soft on the >> person), in that way it can only make the software better. >> Cheers >> >> ------------------------------ >> Date: Sat, 12 Feb 2011 19:45:43 +1100 >> From: pal...@gm... >> To: sco...@gm... >> CC: ma...@rw...; tom...@us... >> Subject: [SPAM] Re: 2.0 demo feedback >> >> >> Scott, >> I agree also with this issue. I think it can be solved by continuing in >> the direction we are going. That is, to have minimal html structures and >> minimal html tables, and to use css includes to do all the formatting. I am >> not a css expert. In fact I would rate my css skills at below beginner. >> However the book I am reading, "CSS The Definitive Guide" by Eric Meyer >> (O'Reilly) has numerous examples where the styles are set up to allow >> expansion and contraction of table cells etc. So I have confidence we can >> fix the problem you raise. >> >> The next phase of the presentation is now to devise and test css styles to >> consistently format the monthly, daily, weekly and simple time entry tables. >> But that will take some time to organise. >> >> I would also like to "modernise" the menu system into a set of tabs, or >> maybe a hierarchical directory tree on the left. >> >> Finally, I'm soon to take off on a trip to colder places late this month >> and next, returning around 17 March. >> >> Ciao >> Peter >> >> On 12/02/11 07:51, Scott Miller wrote: >> >> (finally changed the subject) >> >> Another complaint: We need the site to be able to (mostly) fill a browser >> window. I have a large screen, and it irritates the begeezers out of me >> when I have a site that can only fill a small portion of my available >> screen. This is especially important for the simple timesheet where you >> have a potentially lengthy description field that suddenly becomes nearly >> unusable because the space available is tiny. Configurations, user mgmt, >> reports, all these need the ability to expand horizontally when they can. >> This may not be as important for all areas, but I think it would be bad form >> to allow variable pages only in a few areas... >> >> -Scott >> >> >> On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <sco...@gm...>wrote: >> >> Hey guys, >> >> Ok, admittedly, I'm not an OO guru. But, could you please explain why the >> table name class has been created in the way that it has? In particular, >> I'm totally failing to see how the many tiny routines to set and return the >> private variables is a good idea. Why not declare the variables public, and >> allow the other routines to access the table class variables directly? And >> we could have the class itself, read an appropriate .ini file to load the >> variables in the first place, rather than just including it as a php file as >> is currently done. >> >> Now if there were reasons to protect the members of the class, perhaps >> some of this is needed for the authentication piece, but I honestly can't >> come up with a good reason that most of the classes' variables couldn't be >> public. >> >> -Scott >> >> >> On Fri, Feb 11, 2011 at 7:38 PM, Scott Miller <sco...@gm...>wrote: >> >> Hey Peter, Mark, >> >> I just downloaded (checked out via svn) the 2.0-demo branch. I haven't >> played with it a lot, but for the most part it looks good. >> >> I do have to complain about the new date navigation. It looks ok, but >> it's a pain to use. I now have between 5 and 10 clicks of the mouse to >> change the date. That is, in my opinion, way too many; so I think that whole >> piece needs to be rethought. >> >> I'm going to go check out some of the code changes now, and maybe see if I >> can't add the new configuration stuff into your 2.0-demo... >> >> -Scott >> >> >> > |
|
From: Mark W. <ma...@rw...> - 2011-02-15 00:03:24
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Scott, <br>
<br>
Don't worry, i won't take things personally, it is for the good of
the project at the end of the day. I have been playing around with
wordpress recently and here is their config table:<br>
<br>
CREATE TABLE IF NOT EXISTS `wp_options` (<br>
`option_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,<br>
`blog_id` int(11) NOT NULL DEFAULT '0',<br>
`option_name` varchar(64) NOT NULL DEFAULT '',<br>
`option_value` longtext NOT NULL,<br>
`autoload` varchar(20) NOT NULL DEFAULT 'yes',<br>
PRIMARY KEY (`option_id`),<br>
UNIQUE KEY `option_name` (`option_name`)<br>
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=376 ;<br>
<br>
Now the thing that i think is an improvement here over your proposed
design (the only thing actually) is<br>
the option_value is of type longtext and there is only one column
for value whereas you have three different fields for int, float and
text. Ultimately an int and a float can be stored as text and it
would make no difference to the end result. php decides by itself
the type of a variable anyway. By changing your config to one field
it would im guessing simplify the php that has to load everything
in? or... is there good reason to have three different fields in
the db?<br>
<br>
In the config stuff in the demo, there really only needs to be one
additional function (a getter), there is no real need for a setter
as a config item shouldn't be changed by the system. There were a
few setter functions which have now been removed when I consolidated
all the config into config.factory.php, config.class.php and
config.php.<br>
<br>
With reference to why you should use getters and /or setters, I have
found a nice article on stackoverflow. It relates to python but the
article is still 98% valid. There is more to it than just sloppy
code.<br>
<br>
<a
href="http://stackoverflow.com/questions/1568091/why-use-getters-and-setters">http://stackoverflow.com/questions/1568091/why-use-getters-and-setters</a><br>
<br>
An example in the current tsng code where a getter is very useful is
the Config::getWebmasterEmail() function. The code originally just
returned the email address until I realised that it was much better
practice (for spam reasons) to encode the email first. The encoding
makes no difference to the programmer or end user and it meant only
a single line change rather than having to change every call to the
variable in the project.<br>
<br>
I do understand where you are coming from in regards to needing to
add more code everytime a new config item is introduced, but it does
make for a more robust system at the end of the day. I guess there
is one alternative (albeit not my favourite idea), it is possible
when doing an sql query to return an object instead of an array.
The object is of type stdClass and the member variables are all
public. It is an alternative, but personally I would not recommend
using it for data that needs to be passed around every class file in
the project. <br>
<br>
The place where I now use the sql return as object command is when
grabbing data (for example) to display tables of information. The
file<br>
database.class.php file demonstrates this quite neatly.
MySQLDB::sql() line 158 - mysql_fetch_object($result)<br>
<br>
<br>
Regards<br>
<br>
Mark Wrightson<br>
<br>
<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">_____________________________________________
Mob: 07725 695178
Email: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a></pre>
<br>
On 14/02/2011 23:00, Scott Miller wrote:
<blockquote
cite="mid:AANLkTimKR4siWMcYba57D1nnMf_KQ1cp9-kJUOvj=Wa...@ma..."
type="cite">Absolutely, please don't take anything personally, I
just want it to work and work well.<br>
<br>
The one line change to the CSS worked a treat. Much better :-)<br>
<br>
So, ok, I'm not totally convinced of the OO stuff, so, please bear
with me. With my class to read in and store the configuration
information, it doesn't matter what is added to the configuration
table in the database everything is read in, and the class doesn't
need to be edited every time something new is added. Only when
and where that new thing is needed do we need to change code.<br>
<br>
In the version being championed by Peter and Mark, every new
config item needs two more functions to be added to the class, on
top of the additional code surrounding that item.<br>
<br>
I guess I'm more of a minimalist, I don't feel the added layer of
extra code, and extra function call for each config data look up,
is a good trade off to ensure against sloppy code.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Sun, Feb 13, 2011 at 12:40 PM, David
Thompson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:tom...@us...">tom...@us...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div>
Guys, try to keep your exchanges on the developer-list (that
means checking the addressing when you reply).<br>
That way there is a (searchable) record for everyone to see
what is going on.<br>
<br>
Critisism should be nothing personal (hard on the product,
but soft on the person), in that way it can only make the
software better.<br>
Cheers <br>
<br>
<hr>
Date: Sat, 12 Feb 2011 19:45:43 +1100<br>
From: <a moz-do-not-send="true"
href="mailto:pal...@gm..." target="_blank">pal...@gm...</a><br>
To: <a moz-do-not-send="true"
href="mailto:sco...@gm..." target="_blank">sco...@gm...</a><br>
CC: <a moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>;
<a moz-do-not-send="true"
href="mailto:tom...@us..."
target="_blank">tom...@us...</a><br>
Subject: [SPAM] Re: 2.0 demo feedback
<div>
<div class="h5"><br>
<br>
Scott,<br>
I agree also with this issue. I think it can be solved
by continuing in the direction we are going. That is, to
have minimal html structures and minimal html tables,
and to use css includes to do all the formatting. I am
not a css expert. In fact I would rate my css skills at
below beginner. However the book I am reading, "CSS The
Definitive Guide" by Eric Meyer (O'Reilly) has numerous
examples where the styles are set up to allow expansion
and contraction of table cells etc. So I have confidence
we can fix the problem you raise.<br>
<br>
The next phase of the presentation is now to devise and
test css styles to consistently format the monthly,
daily, weekly and simple time entry tables. But that
will take some time to organise. <br>
<br>
I would also like to "modernise" the menu system into a
set of tabs, or maybe a hierarchical directory tree on
the left.<br>
<br>
Finally, I'm soon to take off on a trip to colder places
late this month and next, returning around 17 March.<br>
<br>
Ciao<br>
Peter<br>
<br>
On 12/02/11 07:51, Scott Miller wrote:
<blockquote>(finally changed the subject)<br>
<br>
Another complaint: We need the site to be able to
(mostly) fill a browser window. I have a large
screen, and it irritates the begeezers out of me when
I have a site that can only fill a small portion of my
available screen. This is especially important for
the simple timesheet where you have a potentially
lengthy description field that suddenly becomes nearly
unusable because the space available is tiny.
Configurations, user mgmt, reports, all these need the
ability to expand horizontally when they can. This
may not be as important for all areas, but I think it
would be bad form to allow variable pages only in a
few areas...<br>
<br>
-Scott<br>
<br>
<br>
<div>On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote style="padding-left: 1ex;">Hey guys,<br>
<br>
Ok, admittedly, I'm not an OO guru. But, could
you please explain why the table name class has
been created in the way that it has? In
particular, I'm totally failing to see how the
many tiny routines to set and return the private
variables is a good idea. Why not declare the
variables public, and allow the other routines to
access the table class variables directly? And we
could have the class itself, read an appropriate
.ini file to load the variables in the first
place, rather than just including it as a php file
as is currently done.<br>
<br>
Now if there were reasons to protect the members
of the class, perhaps some of this is needed for
the authentication piece, but I honestly can't
come up with a good reason that most of the
classes' variables couldn't be public.<br>
<font color="#888888"><br>
-Scott</font>
<div>
<div><br>
<br>
<div>On Fri, Feb 11, 2011 at 7:38 PM, Scott
Miller <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>></span>
wrote:<br>
<blockquote style="padding-left: 1ex;">Hey
Peter, Mark,<br>
<br>
I just downloaded (checked out via svn)
the 2.0-demo branch. I haven't played
with it a lot, but for the most part it
looks good.<br>
<br>
I do have to complain about the new date
navigation. It looks ok, but it's a pain
to use. I now have between 5 and 10
clicks of the mouse to change the date.
That is, in my opinion, way too many; so I
think that whole piece needs to be
rethought.<br>
<br>
I'm going to go check out some of the code
changes now, and maybe see if I can't add
the new configuration stuff into your
2.0-demo...<br>
<font color="#888888"><br>
-Scott<br>
<br>
</font><br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
29 messages has been excluded from this view by a project administrator.
