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: Scott M. <sco...@gm...> - 2011-03-20 21:34:34
|
Excellent to hear you're actively working on the 2.0 demo branch, and thanks
for the answer about htmlspecialchars.
Honestly, the localise.php file is currently simply copied from Joomla, and
I'm nearly certain that it isn't yet being used, but it is still early in
our move to using the internationalization for me to say we won't use it.
>From memory, there are some routines to help "pluralize" things, and outside
that, I'm not sure what other potential it has.
-Scott
On Sat, Mar 19, 2011 at 11:20 AM, Isabelle Vergely <ver...@fr...
> wrote:
> Hello,
>
> Sorry to answer only now but I didn't have time before.
>
> About encapsulating the JText calls within htmlspecialchars,
> I think it's not necessary: a quick search in Joomla does not
> show such usage...
>
> I'm pleased to join the Timesheet Next Gen project.
> On my working copy of txsheet-2.0-demo, first, I begin this
> weekend to work on the creation and the content of the
> "include/language/fr-FR" directory.
>
> About the file "/include/language/en-GB/en-GB.localise.php":
> can you tell me the purpose of this file?
>
> Bye.
>
> Isabelle
>
> ----- Mail Original -----
> De: "Scott Miller" <sco...@gm...>
> À: "Isabelle Vergely" <ver...@fr...>
> Cc: "tsheetx" <tsh...@li...>
> Envoyé: Jeudi 17 Mars 2011 18:20:32 GMT +01:00 Amsterdam / Berlin / Berne /
> Rome / Stockholm / Vienne
> Objet: Should we use htmlspecialchars for the internationalization stuff?
>
>
> Isabelle,
>
> Should we be encapsulating the JText calls within htmlspecialchars like
> this:
> echo htmlspecialchars(JText::_('EXAMPLE'));
>
> Or should I assume the translators will do the html encoding within the
> language files?
>
> -Scott
>
|
|
From: Scott M. <sco...@gm...> - 2011-03-20 21:26:48
|
Either and both of those would be excellent places to continue; and if you want you can help convert output to use the new JText calls in the files you hit. On Sat, Mar 19, 2011 at 4:43 AM, Peter Lazarus <pal...@gm...> wrote: > Greetings Fellow Developers, > I'm now back from my trip and have updated my tsheet code copy to the > latest you've created. So I am wondering where I should resume my > contribution to the development? My two ideas for development are: a) to try > and clean up the css in the forms so that all formatting is done via css and > none by any local bits of html formatting; b) review the state of the time > submission and approval process, and develop it more fully. > > Any suggestions welcomed. > Peter > |
|
From: Isabelle V. <ver...@fr...> - 2011-03-19 16:20:31
|
Hello,
Sorry to answer only now but I didn't have time before.
About encapsulating the JText calls within htmlspecialchars,
I think it's not necessary: a quick search in Joomla does not
show such usage...
I'm pleased to join the Timesheet Next Gen project.
On my working copy of txsheet-2.0-demo, first, I begin this
weekend to work on the creation and the content of the
"include/language/fr-FR" directory.
About the file "/include/language/en-GB/en-GB.localise.php":
can you tell me the purpose of this file?
Bye.
Isabelle
----- Mail Original -----
De: "Scott Miller" <sco...@gm...>
À: "Isabelle Vergely" <ver...@fr...>
Cc: "tsheetx" <tsh...@li...>
Envoyé: Jeudi 17 Mars 2011 18:20:32 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne
Objet: Should we use htmlspecialchars for the internationalization stuff?
Isabelle,
Should we be encapsulating the JText calls within htmlspecialchars like this:
echo htmlspecialchars(JText::_('EXAMPLE'));
Or should I assume the translators will do the html encoding within the language files?
-Scott
|
|
From: Peter L. <pal...@gm...> - 2011-03-19 09:43:11
|
Greetings Fellow Developers, I'm now back from my trip and have updated my tsheet code copy to the latest you've created. So I am wondering where I should resume my contribution to the development? My two ideas for development are: a) to try and clean up the css in the forms so that all formatting is done via css and none by any local bits of html formatting; b) review the state of the time submission and approval process, and develop it more fully. Any suggestions welcomed. Peter |
|
From: Scott M. <sco...@gm...> - 2011-03-17 22:14:18
|
Another set of files checked in just now; working on fixing up the client maintenance area, getting internationalization in those files. In order to help me ensure that I'm fixing all the text on the pages via the JText calls, currently all JText calls prepend a 'j' in front of every string. Consider that as a type of debugging output :-) -Scott |
|
From: Scott M. <sco...@gm...> - 2011-03-17 19:49:07
|
Ah, good, I was fixing up the client/project maintenance stuff and since that stuff has been a bit neglected lately, that wasn't in there yet. -Scott On Thu, Mar 17, 2011 at 6:34 PM, Mark Wrightson <ma...@rw...>wrote: > Hi Scott, > > I agree and this is why there is the config item: Config::getMainTitle() ; > > Regards > > Mark > > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > On 17/03/2011 15:39, Scott Miller wrote: > > Hi all, > > Throwing this out there. I would like to see a more consistent "brand" > within our title tags for the various pages. These strings show up within > the page "tabs" on the two browsers I use. > > I'm thinking maybe a format like this would be good: TSX v<Version> - > <specific page string> > So, for example "TSX v2.0 - Monthly" might be an example for the monthly > view. > > Anyone have any thoughts on this proposal? > > -Scott > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future.http://p.sf.net/sfu/internap-sfd2d > > > _______________________________________________ > Tsheetx-developers mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > > |
|
From: Mark W. <ma...@rw...> - 2011-03-17 18:34:04
|
<!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 bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
I agree and this is why there is the config item:
Config::getMainTitle() ;<br>
<br>
Regards<br>
<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/03/2011 15:39, Scott Miller wrote:
<blockquote
cite="mid:AANLkTi=8UK...@ma..."
type="cite">Hi all,<br>
<br>
Throwing this out there. I would like to see a more consistent
"brand" within our title tags for the various pages. These strings
show up within the page "tabs" on the two browsers I use.<br>
<br>
I'm thinking maybe a format like this would be good: TSX
v<Version> - <specific page string><br>
So, for example "TSX v2.0 - Monthly" might be an example for the
monthly view.<br>
<br>
Anyone have any thoughts on this proposal?<br>
<br>
-Scott<br>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/internap-sfd2d">http://p.sf.net/sfu/internap-sfd2d</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-03-17 17:20:43
|
Isabelle,
Should we be encapsulating the JText calls within htmlspecialchars like
this:
echo htmlspecialchars(JText::_('EXAMPLE'));
Or should I assume the translators will do the html encoding within the
language files?
-Scott
|
|
From: Scott M. <sco...@gm...> - 2011-03-17 15:40:04
|
Hi all, Throwing this out there. I would like to see a more consistent "brand" within our title tags for the various pages. These strings show up within the page "tabs" on the two browsers I use. I'm thinking maybe a format like this would be good: TSX v<Version> - <specific page string> So, for example "TSX v2.0 - Monthly" might be an example for the monthly view. Anyone have any thoughts on this proposal? -Scott |
|
From: Scott M. <sco...@gm...> - 2011-03-15 21:47:12
|
I've made another check in (3 actually): simple sheet, menu and banner items now using JText, small fix to monthly sheet. Also, I've created a new, better in my opinion, way to create the menus, but we need to add some additional ACL entries before I can uncomment that block of code. Except for throwing lots of errors about not finding the missing ACL's, it works pretty well. -Scott |
|
From: Mark W. <ma...@rw...> - 2011-03-15 16:53:56
|
<!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 bgcolor="#ffffff" text="#000000">
body onload="..." template tag fixed and committed. Clock on/off
javascript functionality now works again<br>
<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/03/2011 16:07, Scott Miller wrote:
<blockquote
cite="mid:AANLkTi=Sg8Tz7zonNN-RjcLLzLSjhB==L_4ov81cz=Z+...@ma..."
type="cite">2.0 Monthly page and error stuff fixed up and checked
into subversion.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon, Mar 14, 2011 at 10:58 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 bgcolor="#ffffff" text="#000000"> There is a nice and
easy way to achieve this:<br>
<br>
In error.php add the following lines of code:<br>
<br>
PageElements::addFile('tsx_banner','themes/'.PageElements::getTheme().'/error-banner.inc');<br>
Site::getCommandMenu()->add(new TextCommand("Back", true,
<a moz-do-not-send="true">"javascript:back()"</a>));<br>
<br>
This will give the desired effect you are looking for. The
addFile() command checks if tsx_banner already exists as a
FileTag. if it does, it then just replaces the filename.
If it finds a tag that is of a different type, then it
throws an error.
<div class="im"><br>
<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div class="h5"> On 14/03/2011 20:05, Scott Miller wrote:
<blockquote type="cite">Yes, I was talking about those
sections of code that either do something the new OO
way or the old way, I've begun to remove that stuff as
I come across them.<br>
<br>
Ok, yet another related topic, I've modified the
error.php file, but the template it is using includes
the entire menu. In the original version, a very
limited menu consisting of a link to go back to the
previous page was displayed. Can we, and more to the
point, how do we load a different template for this
error.php file?<br>
<br>
I'll check this stuff in here within the hour
(provided I remember in time before I have to jet out
to get the kids)<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon, Mar 14, 2011 at 6:47
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 bgcolor="#ffffff" text="#000000"> Erm
depends.<br>
<br>
If it is something along the lines of:<br>
<br>
if(!class_exists('Site'))die('Restricted
Access');<br>
<br>
then it would be best to leave it in. There
isn't a great deal of error handling in the tsng
files. The above will just stop any form of
rogue user actions should the file be attempted
to be loaded outside the core framework.<br>
<br>
There are plenty of scenarios where this can be
removed:<br>
<br>
i.e. authentication manager:<br>
<br>
//create the instance so its availiable by just
including this file<br>
if(!class_exists('Site')) {<br>
$authenticationManager = new
AuthenticationManager();<br>
$authenticationManager->getLDAPcfgInfo();<br>
}<br>
<br>
authentication manager will never ever be loaded
ever again outside the core framework. many of
the class exists checks were there during the
conversion process. <br>
<br>
Saying that, there are still some pages that
haven't been converted to the new OO system.
i.e. supervisor_action.php I think all
unconverted files have:<br>
<br>
die('NOT CONVERTED TO OO YET');<br>
<br>
as the first line of the file. :)
<div><br>
<br>
Mark<br>
<br>
<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<br>
</div>
<div>
<div> On 14/03/2011 17:55, Scott Miller wrote:
<blockquote type="cite">Excellent, I think
that will point me to what I needed.<br>
<br>
Another question: Are we at a place where
we can start removing the
"if(!class_exists('Site')){" stuff for the
content files (those under tsx for
instance)?<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Mon, Mar 14,
2011 at 5:19 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 bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
There are a few files to look at:<br>
<br>
1. themes/txsheet/config.php<br>
This file maps the required files
i.e. banner.inc to {tsx_banner}<br>
Having this in a config file means
that if a different theme is used,
then a different set of required
files can be loaded.<br>
<br>
2. the
templateparser.datastructure.class.php
stores all the information about the
what tags need to be loaded.<br>
<br>
3. The tags folder contain the three
different types of tags that can be
used:<br>
<br>
a) filetag - loads a physical file.<br>
b)functiontag - executes a function
(either global, static, or object
instance)<br>
c) stringtag - just a simple string<br>
<br>
4. (Finally) There are some tags
defined in site.class.php (line
145++). These are defined here as
they should be independent of the
currently used theme.<br>
<br>
1 and 4 are where the tags are
created. tags can also be added
inside other files i.e. monthly.php
if needed. The only thing i should
point out is that there isn't yet
anyway to control the order in which
the tags are parsed - (the order is
in the order they were added/created
ish).<br>
<br>
There is two priority levels that
is:<br>
1. FileTags are parsed before
FunctionTags. and FunctionTags are
parsed before StringTags<br>
2. The content tag is always parsed
first.<br>
<br>
Finally, enable the
Debug::$templateTags flag it will
spit out a load of debug information
that will help to show the inner
workings of the templating. <br>
<br>
N.B. Debug::$sendToScreen = 1 should
be set and Debug::$hideDebugData = 0
should also be cleared to ensure the
output appears onscreen.<br>
<br>
If you would like to find the exact
location the debug statements are
being printed:<br>
set Debug::$pprTrace =1.<br>
<br>
I realise this email isn't all that
clear but hopefully, just enabling
the debug output will allow you to
see exactly what is happening. <br>
<br>
I've also just realised that the
Debug::$sendToConsole isn't
functioning yet. But
Debug::$sendToScreen works just
fine.<br>
<br>
Regards<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div> <br>
On 14/03/2011 15:14, Scott
Miller wrote:
<blockquote type="cite">Hey
Mark,<br>
<br>
I want to start working on
actually using the language
stuff, but I thought it might
be important to understand how
the template stuff works. I
found where things get
converted from tags into other
output
(include/templateparser/templateparser.class.php
and
include/templateparser/tags/*),
but I've thus far this morning
been unable to discover where
and how the tags are defined.
I think there is some magic
going on in the
template.datastructure.class.php,
but I'm unable to tie that
stuff to anything concrete.<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On
Fri, Mar 11, 2011 at 9:53
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;"> Hi
all,<br>
<br>
The language stuff is now
loaded by the site class.
I've also made several
minor layout (ie. style)
changes to several of the
class files, but made no
material changes to most
of them.<br>
<br>
test-language-stuff is
still the only page using
the language stuff at this
point.<br>
<font color="#888888"> <br>
-Scott</font>
<div>
<div><br>
<br>
<div
class="gmail_quote">On
Thu, Mar 10, 2011 at
8:37 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;"> I'm
unfamiliar with
the term "config
points". I am
certainly
championing the
change to a more
fluid (ie
changable)
configuration
table within the
database such that
it is much easier
to add new
configuration
items. If that
style of storing
configuration data
is called "config
points", then yes
I am :-)<br>
<font
color="#888888">
<br>
-Scott</font>
<div>
<div><br>
<br>
<div
class="gmail_quote">On
Thu, Mar 10,
2011 at 4:46
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> Yes,
Scott using
setlocale
solves most
date/time
representation
issues (though
I am not sure
about the
comma instead
of point one
though...).<br>
<br>
And Isabelle,
I would love
to see the
config points
that you
mention (lang,
holidays,
working times,
etc.) - even
if they are
not used in
2.0, we could
add them as a
guide for the
future. Scott,
you're adding
config points
right now,
aren't you?<br>
<br>
Isabelle, if
you would like
commit access,
just tell me
your <a
moz-do-not-send="true"
href="http://sourceforge.net" target="_blank">sourceforge.net</a> id,
and I will add
you.<br>
<br>
Cheers<br>
<br>
<hr> Date:
Thu, 10 Mar
2011 15:19:45
+0100<br>
From: <a
moz-do-not-send="true"
href="mailto:ver...@fr..." target="_blank">ver...@fr...</a><br>
To: <a
moz-do-not-send="true"
href="mailto:tsh...@li..." target="_blank">tsh...@li...</a>;
<a
moz-do-not-send="true"
href="mailto:sco...@gm..." target="_blank">sco...@gm...</a>;
<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: Re:
language and
jclasses
discussion
<div>
<div><br>
<br>
<div
style="font-family:
Arial; color:
rgb(0, 0, 0);
font-size:
10pt;">Hello,<br>
<br>
For
internationalization
of dates, I
don't think
that routines
are necessary<br>
as the
language files
like"/language/en-GB/en
-GB.ini" allow
to specify<br>
the values of
the months, of
the days of
the week and
of the date
formats<br>
(eg
DATE_FORMAT_LC).<br>
<br>
In France, we
often also use
the week
number for our
schedules. I
added<br>
this number on
relevant pages
in "my
timesheet
1.5.2". As the
parameter<br>
"%V" of the
strftime
function
didn't work on
my computer, I
used the
function<br>
"week_isonumber"
posted by
Anonymous
12-Oct-2010
07:04 here:<br>
<a
moz-do-not-send="true"
href="http://php.net/manual/fr/function.strftime.php" target="_blank">http://php.net/manual/fr/function.strftime.php</a><br>
<br>
For the time
format in
French, just
replace the
occurrences of
colon as<br>
in this
example:<br>
- English:
10:30:56<br>
- French: 10h
30m 56s<br>
<br>
As I said
earlier, to
have the
correct dates
in French, you
must specify<br>
the language
'fra' for the
locale:
setlocale(LC_ALL,'fr_FR','fra');<br>
<br>
For numbers in
French, the
decimal
separator is a
comma instead
of the<br>
point. This is
important for
excel export.<br>
<br>
For billing
and currency:<br>
The euro is
the official
currency of
the Eurozone
in the
European
Union.<br>
The html
entity for the
euro sign is
&euro;<br>
<br>
For the
translation of
the different
status for
projects and
for tasks<br>
as well as of
the different
types of
users, would
it be possible
to add<br>
the values in
the language
files if it's
allow to not
modify "enum"
in<br>
the database?<br>
<br>
Do you want me
to contribute
at this stage
to the project
by making an<br>
fr-FR.ini file
for
translation of
the current
en-GB.ini file
in <br>
"/branches/txsheet-2.0-demo/"?<br>
If yes, how to
join the
project?<br>
<br>
I was also
thinking about
that: on the
configuration
page of the
future<br>
Timesheet 2.0,
would it be
possible to
define the
following data
<br>
depending on
each country:<br>
- dates of the
days being
public
holidays<br>
- the legal
duration of
work per day
and/or per
week<br>
- the legal
number of days
for holidays
per year<br>
<br>
Sincerely.<br>
<br>
Isabelle.<br>
<br>
----- Mail
Original -----<br>
De: "Scott
Miller" <<a
moz-do-not-send="true" href="mailto:sco...@gm..."
target="_blank">sco...@gm...</a>><br>
À: "tsheetx"
<<a
moz-do-not-send="true"
href="mailto:tsh...@li..." target="_blank">tsh...@li...</a>>,
"Mark
Wrightson"
<<a
moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>>,
"David
Thompson" <<a
moz-do-not-send="true" href="mailto:tom...@us..."
target="_blank">tom...@us...</a>>,
"Isabelle
Vergely" <<a
moz-do-not-send="true" href="mailto:ver...@fr..."
target="_blank">ver...@fr...</a>><br>
Envoyé:
Mercredi 9
Mars 2011
00:16:34 GMT
+01:00
Amsterdam /
Berlin / Berne
/ Rome /
Stockholm /
Vienne<br>
Objet:
language and
jclasses
discussion<br>
<br>
Hi all,<br>
<br>
I've checked
in a few more
changes,
mainly focused
on further
trimming down
of un-needed
stuff from the
various
classes, and
the removal of
un-needed
classes.<br>
<br>
I'm still
waiting for a
discussion on
whether we
want to
continue using
J* class names
(JLanguage,
JText, JFile,
JFolder, etc)
or if we want
to use
something
different, and
if so, what.<br>
<br>
Also still
waiting to
hear about how
the error
classes work,
and how to
replace the
commented out
error stuff in
the jclasses
with error
stuff that
will actually
work for us.<br>
<br>
I'm beginning
to think about
how to go
about
integrating
the JLanguage
stuff into our
existing
classes.
Should the
JLanguage
stuff be part
of the master
site class?
I'm currently
thinking it
should.<br>
<br>
Isabelle, I
think it will
be useful to
have language
specific
routines that
deal with how
to correctly
format times,
dates, and
numbers in
general. Can
you point us
in the right
direction as
to how to go
about doing
this?<br>
<br>
-Scott<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</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>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
<a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/internap-sfd2d">http://p.sf.net/sfu/internap-sfd2d</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-03-15 16:08:02
|
2.0 Monthly page and error stuff fixed up and checked into subversion.
-Scott
On Mon, Mar 14, 2011 at 10:58 PM, Mark Wrightson
<ma...@rw...>wrote:
> There is a nice and easy way to achieve this:
>
> In error.php add the following lines of code:
>
>
> PageElements::addFile('tsx_banner','themes/'.PageElements::getTheme().'/error-banner.inc');
> Site::getCommandMenu()->add(new TextCommand("Back", true,
> "javascript:back()"));
>
> This will give the desired effect you are looking for. The addFile()
> command checks if tsx_banner already exists as a FileTag. if it does, it
> then just replaces the filename. If it finds a tag that is of a different
> type, then it throws an error.
>
>
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
> On 14/03/2011 20:05, Scott Miller wrote:
>
> Yes, I was talking about those sections of code that either do something
> the new OO way or the old way, I've begun to remove that stuff as I come
> across them.
>
> Ok, yet another related topic, I've modified the error.php file, but the
> template it is using includes the entire menu. In the original version, a
> very limited menu consisting of a link to go back to the previous page was
> displayed. Can we, and more to the point, how do we load a different
> template for this error.php file?
>
> I'll check this stuff in here within the hour (provided I remember in time
> before I have to jet out to get the kids)
>
> -Scott
>
> On Mon, Mar 14, 2011 at 6:47 PM, Mark Wrightson <ma...@rw...>wrote:
>
>> Erm depends.
>>
>> If it is something along the lines of:
>>
>> if(!class_exists('Site'))die('Restricted Access');
>>
>> then it would be best to leave it in. There isn't a great deal of error
>> handling in the tsng files. The above will just stop any form of rogue user
>> actions should the file be attempted to be loaded outside the core
>> framework.
>>
>> There are plenty of scenarios where this can be removed:
>>
>> i.e. authentication manager:
>>
>> //create the instance so its availiable by just including this file
>> if(!class_exists('Site')) {
>> $authenticationManager = new AuthenticationManager();
>> $authenticationManager->getLDAPcfgInfo();
>> }
>>
>> authentication manager will never ever be loaded ever again outside the
>> core framework. many of the class exists checks were there during the
>> conversion process.
>>
>> Saying that, there are still some pages that haven't been converted to the
>> new OO system. i.e. supervisor_action.php I think all unconverted files
>> have:
>>
>> die('NOT CONVERTED TO OO YET');
>>
>> as the first line of the file. :)
>>
>>
>> Mark
>>
>>
>> _____________________________________________
>>
>> Mob: <07725%20695178>07725 695178
>> Email: ma...@rw...
>>
>>
>> On 14/03/2011 17:55, Scott Miller wrote:
>>
>> Excellent, I think that will point me to what I needed.
>>
>> Another question: Are we at a place where we can start removing the
>> "if(!class_exists('Site')){" stuff for the content files (those under tsx
>> for instance)?
>>
>> -Scott
>>
>> On Mon, Mar 14, 2011 at 5:19 PM, Mark Wrightson <ma...@rw...
>> > wrote:
>>
>>> Hi Scott,
>>>
>>> There are a few files to look at:
>>>
>>> 1. themes/txsheet/config.php
>>> This file maps the required files i.e. banner.inc to {tsx_banner}
>>> Having this in a config file means that if a different theme is used,
>>> then a different set of required files can be loaded.
>>>
>>> 2. the templateparser.datastructure.class.php stores all the information
>>> about the what tags need to be loaded.
>>>
>>> 3. The tags folder contain the three different types of tags that can be
>>> used:
>>>
>>> a) filetag - loads a physical file.
>>> b)functiontag - executes a function (either global, static, or object
>>> instance)
>>> c) stringtag - just a simple string
>>>
>>> 4. (Finally) There are some tags defined in site.class.php (line 145++).
>>> These are defined here as they should be independent of the currently used
>>> theme.
>>>
>>> 1 and 4 are where the tags are created. tags can also be added inside
>>> other files i.e. monthly.php if needed. The only thing i should point out
>>> is that there isn't yet anyway to control the order in which the tags are
>>> parsed - (the order is in the order they were added/created ish).
>>>
>>> There is two priority levels that is:
>>> 1. FileTags are parsed before FunctionTags. and FunctionTags are parsed
>>> before StringTags
>>> 2. The content tag is always parsed first.
>>>
>>> Finally, enable the Debug::$templateTags flag it will spit out a load of
>>> debug information that will help to show the inner workings of the
>>> templating.
>>>
>>> N.B. Debug::$sendToScreen = 1 should be set and Debug::$hideDebugData = 0
>>> should also be cleared to ensure the output appears onscreen.
>>>
>>> If you would like to find the exact location the debug statements are
>>> being printed:
>>> set Debug::$pprTrace =1.
>>>
>>> I realise this email isn't all that clear but hopefully, just enabling
>>> the debug output will allow you to see exactly what is happening.
>>>
>>> I've also just realised that the Debug::$sendToConsole isn't functioning
>>> yet. But Debug::$sendToScreen works just fine.
>>>
>>> Regards
>>> Mark
>>>
>>> _____________________________________________
>>>
>>> Mob: <07725%20695178>07725 695178
>>> Email: ma...@rw...
>>>
>>>
>>> On 14/03/2011 15:14, Scott Miller wrote:
>>>
>>> Hey Mark,
>>>
>>> I want to start working on actually using the language stuff, but I
>>> thought it might be important to understand how the template stuff works. I
>>> found where things get converted from tags into other output
>>> (include/templateparser/templateparser.class.php and
>>> include/templateparser/tags/*), but I've thus far this morning been unable
>>> to discover where and how the tags are defined. I think there is some magic
>>> going on in the template.datastructure.class.php, but I'm unable to tie that
>>> stuff to anything concrete.
>>>
>>> -Scott
>>>
>>> On Fri, Mar 11, 2011 at 9:53 PM, Scott Miller <sco...@gm...>wrote:
>>>
>>>> Hi all,
>>>>
>>>> The language stuff is now loaded by the site class. I've also made
>>>> several minor layout (ie. style) changes to several of the class files, but
>>>> made no material changes to most of them.
>>>>
>>>> test-language-stuff is still the only page using the language stuff at
>>>> this point.
>>>>
>>>> -Scott
>>>>
>>>>
>>>> On Thu, Mar 10, 2011 at 8:37 PM, Scott Miller <sco...@gm...
>>>> > wrote:
>>>>
>>>>> I'm unfamiliar with the term "config points". I am certainly
>>>>> championing the change to a more fluid (ie changable) configuration table
>>>>> within the database such that it is much easier to add new configuration
>>>>> items. If that style of storing configuration data is called "config
>>>>> points", then yes I am :-)
>>>>>
>>>>> -Scott
>>>>>
>>>>>
>>>>> On Thu, Mar 10, 2011 at 4:46 PM, David Thompson <
>>>>> tom...@us...> wrote:
>>>>>
>>>>>> Yes, Scott using setlocale solves most date/time representation
>>>>>> issues (though I am not sure about the comma instead of point one
>>>>>> though...).
>>>>>>
>>>>>> And Isabelle, I would love to see the config points that you mention
>>>>>> (lang, holidays, working times, etc.) - even if they are not used in 2.0, we
>>>>>> could add them as a guide for the future. Scott, you're adding config points
>>>>>> right now, aren't you?
>>>>>>
>>>>>> Isabelle, if you would like commit access, just tell me your
>>>>>> sourceforge.net id, and I will add you.
>>>>>>
>>>>>> Cheers
>>>>>>
>>>>>> ------------------------------
>>>>>> Date: Thu, 10 Mar 2011 15:19:45 +0100
>>>>>> From: ver...@fr...
>>>>>> To: tsh...@li...;
>>>>>> sco...@gm...; ma...@rw...;
>>>>>> tom...@us...
>>>>>> Subject: Re: language and jclasses discussion
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> For internationalization of dates, I don't think that routines are
>>>>>> necessary
>>>>>> as the language files like"/language/en-GB/en -GB.ini" allow to
>>>>>> specify
>>>>>> the values of the months, of the days of the week and of the date
>>>>>> formats
>>>>>> (eg DATE_FORMAT_LC).
>>>>>>
>>>>>> In France, we often also use the week number for our schedules. I
>>>>>> added
>>>>>> this number on relevant pages in "my timesheet 1.5.2". As the
>>>>>> parameter
>>>>>> "%V" of the strftime function didn't work on my computer, I used the
>>>>>> function
>>>>>> "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here:
>>>>>> http://php.net/manual/fr/function.strftime.php
>>>>>>
>>>>>> For the time format in French, just replace the occurrences of colon
>>>>>> as
>>>>>> in this example:
>>>>>> - English: 10:30:56
>>>>>> - French: 10h 30m 56s
>>>>>>
>>>>>> As I said earlier, to have the correct dates in French, you must
>>>>>> specify
>>>>>> the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra');
>>>>>>
>>>>>> For numbers in French, the decimal separator is a comma instead of the
>>>>>> point. This is important for excel export.
>>>>>>
>>>>>> For billing and currency:
>>>>>> The euro is the official currency of the Eurozone in the European
>>>>>> Union.
>>>>>> The html entity for the euro sign is €
>>>>>>
>>>>>> For the translation of the different status for projects and for tasks
>>>>>> as well as of the different types of users, would it be possible to
>>>>>> add
>>>>>> the values in the language files if it's allow to not modify "enum" in
>>>>>> the database?
>>>>>>
>>>>>> Do you want me to contribute at this stage to the project by making an
>>>>>> fr-FR.ini file for translation of the current en-GB.ini file in
>>>>>> "/branches/txsheet-2.0-demo/"?
>>>>>> If yes, how to join the project?
>>>>>>
>>>>>> I was also thinking about that: on the configuration page of the
>>>>>> future
>>>>>> Timesheet 2.0, would it be possible to define the following data
>>>>>> depending on each country:
>>>>>> - dates of the days being public holidays
>>>>>> - the legal duration of work per day and/or per week
>>>>>> - the legal number of days for holidays per year
>>>>>>
>>>>>> Sincerely.
>>>>>>
>>>>>> Isabelle.
>>>>>>
>>>>>> ----- Mail Original -----
>>>>>> De: "Scott Miller" <sco...@gm...>
>>>>>> À: "tsheetx" <tsh...@li...>, "Mark
>>>>>> Wrightson" <ma...@rw...>, "David Thompson" <
>>>>>> tom...@us...>, "Isabelle Vergely" <
>>>>>> ver...@fr...>
>>>>>> Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin /
>>>>>> Berne / Rome / Stockholm / Vienne
>>>>>> Objet: language and jclasses discussion
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I've checked in a few more changes, mainly focused on further trimming
>>>>>> down of un-needed stuff from the various classes, and the removal of
>>>>>> un-needed classes.
>>>>>>
>>>>>> I'm still waiting for a discussion on whether we want to continue
>>>>>> using J* class names (JLanguage, JText, JFile, JFolder, etc) or if we want
>>>>>> to use something different, and if so, what.
>>>>>>
>>>>>> Also still waiting to hear about how the error classes work, and how
>>>>>> to replace the commented out error stuff in the jclasses with error stuff
>>>>>> that will actually work for us.
>>>>>>
>>>>>> I'm beginning to think about how to go about integrating the JLanguage
>>>>>> stuff into our existing classes. Should the JLanguage stuff be part of the
>>>>>> master site class? I'm currently thinking it should.
>>>>>>
>>>>>> Isabelle, I think it will be useful to have language specific routines
>>>>>> that deal with how to correctly format times, dates, and numbers in
>>>>>> general. Can you point us in the right direction as to how to go about
>>>>>> doing this?
>>>>>>
>>>>>> -Scott
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
|
|
From: Scott M. <sco...@gm...> - 2011-03-14 15:14:09
|
Hey Mark, I want to start working on actually using the language stuff, but I thought it might be important to understand how the template stuff works. I found where things get converted from tags into other output (include/templateparser/templateparser.class.php and include/templateparser/tags/*), but I've thus far this morning been unable to discover where and how the tags are defined. I think there is some magic going on in the template.datastructure.class.php, but I'm unable to tie that stuff to anything concrete. -Scott On Fri, Mar 11, 2011 at 9:53 PM, Scott Miller <sco...@gm...>wrote: > Hi all, > > The language stuff is now loaded by the site class. I've also made several > minor layout (ie. style) changes to several of the class files, but made no > material changes to most of them. > > test-language-stuff is still the only page using the language stuff at this > point. > > -Scott > > > On Thu, Mar 10, 2011 at 8:37 PM, Scott Miller <sco...@gm...>wrote: > >> I'm unfamiliar with the term "config points". I am certainly championing >> the change to a more fluid (ie changable) configuration table within the >> database such that it is much easier to add new configuration items. If >> that style of storing configuration data is called "config points", then yes >> I am :-) >> >> -Scott >> >> >> On Thu, Mar 10, 2011 at 4:46 PM, David Thompson < >> tom...@us...> wrote: >> >>> Yes, Scott using setlocale solves most date/time representation issues >>> (though I am not sure about the comma instead of point one though...). >>> >>> And Isabelle, I would love to see the config points that you mention >>> (lang, holidays, working times, etc.) - even if they are not used in 2.0, we >>> could add them as a guide for the future. Scott, you're adding config points >>> right now, aren't you? >>> >>> Isabelle, if you would like commit access, just tell me your >>> sourceforge.net id, and I will add you. >>> >>> Cheers >>> >>> ------------------------------ >>> Date: Thu, 10 Mar 2011 15:19:45 +0100 >>> From: ver...@fr... >>> To: tsh...@li...; sco...@gm...; >>> ma...@rw...; tom...@us... >>> Subject: Re: language and jclasses discussion >>> >>> >>> Hello, >>> >>> For internationalization of dates, I don't think that routines are >>> necessary >>> as the language files like"/language/en-GB/en -GB.ini" allow to specify >>> the values of the months, of the days of the week and of the date formats >>> (eg DATE_FORMAT_LC). >>> >>> In France, we often also use the week number for our schedules. I added >>> this number on relevant pages in "my timesheet 1.5.2". As the parameter >>> "%V" of the strftime function didn't work on my computer, I used the >>> function >>> "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here: >>> http://php.net/manual/fr/function.strftime.php >>> >>> For the time format in French, just replace the occurrences of colon as >>> in this example: >>> - English: 10:30:56 >>> - French: 10h 30m 56s >>> >>> As I said earlier, to have the correct dates in French, you must specify >>> the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra'); >>> >>> For numbers in French, the decimal separator is a comma instead of the >>> point. This is important for excel export. >>> >>> For billing and currency: >>> The euro is the official currency of the Eurozone in the European Union. >>> The html entity for the euro sign is € >>> >>> For the translation of the different status for projects and for tasks >>> as well as of the different types of users, would it be possible to add >>> the values in the language files if it's allow to not modify "enum" in >>> the database? >>> >>> Do you want me to contribute at this stage to the project by making an >>> fr-FR.ini file for translation of the current en-GB.ini file in >>> "/branches/txsheet-2.0-demo/"? >>> If yes, how to join the project? >>> >>> I was also thinking about that: on the configuration page of the future >>> Timesheet 2.0, would it be possible to define the following data >>> depending on each country: >>> - dates of the days being public holidays >>> - the legal duration of work per day and/or per week >>> - the legal number of days for holidays per year >>> >>> Sincerely. >>> >>> Isabelle. >>> >>> ----- Mail Original ----- >>> De: "Scott Miller" <sco...@gm...> >>> À: "tsheetx" <tsh...@li...>, "Mark >>> Wrightson" <ma...@rw...>, "David Thompson" < >>> tom...@us...>, "Isabelle Vergely" < >>> ver...@fr...> >>> Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin / >>> Berne / Rome / Stockholm / Vienne >>> Objet: language and jclasses discussion >>> >>> Hi all, >>> >>> I've checked in a few more changes, mainly focused on further trimming >>> down of un-needed stuff from the various classes, and the removal of >>> un-needed classes. >>> >>> I'm still waiting for a discussion on whether we want to continue using >>> J* class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use >>> something different, and if so, what. >>> >>> Also still waiting to hear about how the error classes work, and how to >>> replace the commented out error stuff in the jclasses with error stuff that >>> will actually work for us. >>> >>> I'm beginning to think about how to go about integrating the JLanguage >>> stuff into our existing classes. Should the JLanguage stuff be part of the >>> master site class? I'm currently thinking it should. >>> >>> Isabelle, I think it will be useful to have language specific routines >>> that deal with how to correctly format times, dates, and numbers in >>> general. Can you point us in the right direction as to how to go about >>> doing this? >>> >>> -Scott >>> >> >> > |
|
From: Scott M. <sco...@gm...> - 2011-03-11 21:53:44
|
Hi all, The language stuff is now loaded by the site class. I've also made several minor layout (ie. style) changes to several of the class files, but made no material changes to most of them. test-language-stuff is still the only page using the language stuff at this point. -Scott On Thu, Mar 10, 2011 at 8:37 PM, Scott Miller <sco...@gm...>wrote: > I'm unfamiliar with the term "config points". I am certainly championing > the change to a more fluid (ie changable) configuration table within the > database such that it is much easier to add new configuration items. If > that style of storing configuration data is called "config points", then yes > I am :-) > > -Scott > > > On Thu, Mar 10, 2011 at 4:46 PM, David Thompson < > tom...@us...> wrote: > >> Yes, Scott using setlocale solves most date/time representation issues >> (though I am not sure about the comma instead of point one though...). >> >> And Isabelle, I would love to see the config points that you mention >> (lang, holidays, working times, etc.) - even if they are not used in 2.0, we >> could add them as a guide for the future. Scott, you're adding config points >> right now, aren't you? >> >> Isabelle, if you would like commit access, just tell me your >> sourceforge.net id, and I will add you. >> >> Cheers >> >> ------------------------------ >> Date: Thu, 10 Mar 2011 15:19:45 +0100 >> From: ver...@fr... >> To: tsh...@li...; sco...@gm...; >> ma...@rw...; tom...@us... >> Subject: Re: language and jclasses discussion >> >> >> Hello, >> >> For internationalization of dates, I don't think that routines are >> necessary >> as the language files like"/language/en-GB/en -GB.ini" allow to specify >> the values of the months, of the days of the week and of the date formats >> (eg DATE_FORMAT_LC). >> >> In France, we often also use the week number for our schedules. I added >> this number on relevant pages in "my timesheet 1.5.2". As the parameter >> "%V" of the strftime function didn't work on my computer, I used the >> function >> "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here: >> http://php.net/manual/fr/function.strftime.php >> >> For the time format in French, just replace the occurrences of colon as >> in this example: >> - English: 10:30:56 >> - French: 10h 30m 56s >> >> As I said earlier, to have the correct dates in French, you must specify >> the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra'); >> >> For numbers in French, the decimal separator is a comma instead of the >> point. This is important for excel export. >> >> For billing and currency: >> The euro is the official currency of the Eurozone in the European Union. >> The html entity for the euro sign is € >> >> For the translation of the different status for projects and for tasks >> as well as of the different types of users, would it be possible to add >> the values in the language files if it's allow to not modify "enum" in >> the database? >> >> Do you want me to contribute at this stage to the project by making an >> fr-FR.ini file for translation of the current en-GB.ini file in >> "/branches/txsheet-2.0-demo/"? >> If yes, how to join the project? >> >> I was also thinking about that: on the configuration page of the future >> Timesheet 2.0, would it be possible to define the following data >> depending on each country: >> - dates of the days being public holidays >> - the legal duration of work per day and/or per week >> - the legal number of days for holidays per year >> >> Sincerely. >> >> Isabelle. >> >> ----- Mail Original ----- >> De: "Scott Miller" <sco...@gm...> >> À: "tsheetx" <tsh...@li...>, "Mark Wrightson" >> <ma...@rw...>, "David Thompson" < >> tom...@us...>, "Isabelle Vergely" < >> ver...@fr...> >> Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin / >> Berne / Rome / Stockholm / Vienne >> Objet: language and jclasses discussion >> >> Hi all, >> >> I've checked in a few more changes, mainly focused on further trimming >> down of un-needed stuff from the various classes, and the removal of >> un-needed classes. >> >> I'm still waiting for a discussion on whether we want to continue using J* >> class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use >> something different, and if so, what. >> >> Also still waiting to hear about how the error classes work, and how to >> replace the commented out error stuff in the jclasses with error stuff that >> will actually work for us. >> >> I'm beginning to think about how to go about integrating the JLanguage >> stuff into our existing classes. Should the JLanguage stuff be part of the >> master site class? I'm currently thinking it should. >> >> Isabelle, I think it will be useful to have language specific routines >> that deal with how to correctly format times, dates, and numbers in >> general. Can you point us in the right direction as to how to go about >> doing this? >> >> -Scott >> > > |
|
From: Scott M. <sco...@gm...> - 2011-03-10 20:37:16
|
I'm unfamiliar with the term "config points". I am certainly championing the change to a more fluid (ie changable) configuration table within the database such that it is much easier to add new configuration items. If that style of storing configuration data is called "config points", then yes I am :-) -Scott On Thu, Mar 10, 2011 at 4:46 PM, David Thompson < tom...@us...> wrote: > Yes, Scott using setlocale solves most date/time representation issues > (though I am not sure about the comma instead of point one though...). > > And Isabelle, I would love to see the config points that you mention (lang, > holidays, working times, etc.) - even if they are not used in 2.0, we could > add them as a guide for the future. Scott, you're adding config points right > now, aren't you? > > Isabelle, if you would like commit access, just tell me your > sourceforge.net id, and I will add you. > > Cheers > > ------------------------------ > Date: Thu, 10 Mar 2011 15:19:45 +0100 > From: ver...@fr... > To: tsh...@li...; sco...@gm...; > ma...@rw...; tom...@us... > Subject: Re: language and jclasses discussion > > > Hello, > > For internationalization of dates, I don't think that routines are > necessary > as the language files like"/language/en-GB/en -GB.ini" allow to specify > the values of the months, of the days of the week and of the date formats > (eg DATE_FORMAT_LC). > > In France, we often also use the week number for our schedules. I added > this number on relevant pages in "my timesheet 1.5.2". As the parameter > "%V" of the strftime function didn't work on my computer, I used the > function > "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here: > http://php.net/manual/fr/function.strftime.php > > For the time format in French, just replace the occurrences of colon as > in this example: > - English: 10:30:56 > - French: 10h 30m 56s > > As I said earlier, to have the correct dates in French, you must specify > the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra'); > > For numbers in French, the decimal separator is a comma instead of the > point. This is important for excel export. > > For billing and currency: > The euro is the official currency of the Eurozone in the European Union. > The html entity for the euro sign is € > > For the translation of the different status for projects and for tasks > as well as of the different types of users, would it be possible to add > the values in the language files if it's allow to not modify "enum" in > the database? > > Do you want me to contribute at this stage to the project by making an > fr-FR.ini file for translation of the current en-GB.ini file in > "/branches/txsheet-2.0-demo/"? > If yes, how to join the project? > > I was also thinking about that: on the configuration page of the future > Timesheet 2.0, would it be possible to define the following data > depending on each country: > - dates of the days being public holidays > - the legal duration of work per day and/or per week > - the legal number of days for holidays per year > > Sincerely. > > Isabelle. > > ----- Mail Original ----- > De: "Scott Miller" <sco...@gm...> > À: "tsheetx" <tsh...@li...>, "Mark Wrightson" > <ma...@rw...>, "David Thompson" < > tom...@us...>, "Isabelle Vergely" < > ver...@fr...> > Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin / Berne > / Rome / Stockholm / Vienne > Objet: language and jclasses discussion > > Hi all, > > I've checked in a few more changes, mainly focused on further trimming down > of un-needed stuff from the various classes, and the removal of un-needed > classes. > > I'm still waiting for a discussion on whether we want to continue using J* > class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use > something different, and if so, what. > > Also still waiting to hear about how the error classes work, and how to > replace the commented out error stuff in the jclasses with error stuff that > will actually work for us. > > I'm beginning to think about how to go about integrating the JLanguage > stuff into our existing classes. Should the JLanguage stuff be part of the > master site class? I'm currently thinking it should. > > Isabelle, I think it will be useful to have language specific routines that > deal with how to correctly format times, dates, and numbers in general. Can > you point us in the right direction as to how to go about doing this? > > -Scott > |
|
From: David T. <tom...@us...> - 2011-03-10 16:46:20
|
Yes, Scott using setlocale solves most date/time representation issues (though I am not sure about the comma instead of point one though...). And Isabelle, I would love to see the config points that you mention (lang, holidays, working times, etc.) - even if they are not used in 2.0, we could add them as a guide for the future. Scott, you're adding config points right now, aren't you? Isabelle, if you would like commit access, just tell me your sourceforge.net id, and I will add you. Cheers Date: Thu, 10 Mar 2011 15:19:45 +0100 From: ver...@fr... To: tsh...@li...; sco...@gm...; ma...@rw...; tom...@us... Subject: Re: language and jclasses discussion Hello, For internationalization of dates, I don't think that routines are necessary as the language files like"/language/en-GB/en -GB.ini" allow to specify the values of the months, of the days of the week and of the date formats (eg DATE_FORMAT_LC). In France, we often also use the week number for our schedules. I added this number on relevant pages in "my timesheet 1.5.2". As the parameter "%V" of the strftime function didn't work on my computer, I used the function "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here: http://php.net/manual/fr/function.strftime.php For the time format in French, just replace the occurrences of colon as in this example: - English: 10:30:56 - French: 10h 30m 56s As I said earlier, to have the correct dates in French, you must specify the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra'); For numbers in French, the decimal separator is a comma instead of the point. This is important for excel export. For billing and currency: The euro is the official currency of the Eurozone in the European Union. The html entity for the euro sign is € For the translation of the different status for projects and for tasks as well as of the different types of users, would it be possible to add the values in the language files if it's allow to not modify "enum" in the database? Do you want me to contribute at this stage to the project by making an fr-FR.ini file for translation of the current en-GB.ini file in "/branches/txsheet-2.0-demo/"? If yes, how to join the project? I was also thinking about that: on the configuration page of the future Timesheet 2.0, would it be possible to define the following data depending on each country: - dates of the days being public holidays - the legal duration of work per day and/or per week - the legal number of days for holidays per year Sincerely. Isabelle. ----- Mail Original ----- De: "Scott Miller" <sco...@gm...> À: "tsheetx" <tsh...@li...>, "Mark Wrightson" <ma...@rw...>, "David Thompson" <tom...@us...>, "Isabelle Vergely" <ver...@fr...> Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: language and jclasses discussion Hi all, I've checked in a few more changes, mainly focused on further trimming down of un-needed stuff from the various classes, and the removal of un-needed classes. I'm still waiting for a discussion on whether we want to continue using J* class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use something different, and if so, what. Also still waiting to hear about how the error classes work, and how to replace the commented out error stuff in the jclasses with error stuff that will actually work for us. I'm beginning to think about how to go about integrating the JLanguage stuff into our existing classes. Should the JLanguage stuff be part of the master site class? I'm currently thinking it should. Isabelle, I think it will be useful to have language specific routines that deal with how to correctly format times, dates, and numbers in general. Can you point us in the right direction as to how to go about doing this? -Scott |
|
From: Isabelle V. <ver...@fr...> - 2011-03-10 14:20:01
|
Hello, For internationalization of dates, I don't think that routines are necessary as the language files like"/language/en-GB/en -GB.ini" allow to specify the values of the months, of the days of the week and of the date formats (eg DATE_FORMAT_LC). In France, we often also use the week number for our schedules. I added this number on relevant pages in "my timesheet 1.5.2". As the parameter "%V" of the strftime function didn't work on my computer, I used the function "week_isonumber" posted by Anonymous 12-Oct-2010 07:04 here: http://php.net/manual/fr/function.strftime.php For the time format in French, just replace the occurrences of colon as in this example: - English: 10:30:56 - French: 10h 30m 56s As I said earlier, to have the correct dates in French, you must specify the language 'fra' for the locale: setlocale(LC_ALL,'fr_FR','fra'); For numbers in French, the decimal separator is a comma instead of the point. This is important for excel export. For billing and currency: The euro is the official currency of the Eurozone in the European Union. The html entity for the euro sign is € For the translation of the different status for projects and for tasks as well as of the different types of users, would it be possible to add the values in the language files if it's allow to not modify "enum" in the database? Do you want me to contribute at this stage to the project by making an fr-FR.ini file for translation of the current en-GB.ini file in " /branches/txsheet-2.0-demo/"? If yes, how to join the project? I was also thinking about that: on the configuration page of the future Timesheet 2.0, would it be possible to define the following data depending on each country: - dates of the days being public holidays - the legal duration of work per day and/or per week - the legal number of days for holidays per year Sincerely. Isabelle. ----- Mail Original ----- De: "Scott Miller" <sco...@gm...> À: "tsheetx" <tsh...@li...>, "Mark Wrightson" <ma...@rw...>, "David Thompson" <tom...@us...>, "Isabelle Vergely" <ver...@fr...> Envoyé: Mercredi 9 Mars 2011 00:16:34 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: language and jclasses discussion Hi all, I've checked in a few more changes, mainly focused on further trimming down of un-needed stuff from the various classes, and the removal of un-needed classes. I'm still waiting for a discussion on whether we want to continue using J* class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use something different, and if so, what. Also still waiting to hear about how the error classes work, and how to replace the commented out error stuff in the jclasses with error stuff that will actually work for us. I'm beginning to think about how to go about integrating the JLanguage stuff into our existing classes. Should the JLanguage stuff be part of the master site class? I'm currently thinking it should. Isabelle, I think it will be useful to have language specific routines that deal with how to correctly format times, dates, and numbers in general. Can you point us in the right direction as to how to go about doing this? -Scott |
|
From: Mark W. <ma...@rw...> - 2011-03-10 02:08:54
|
<!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 bgcolor="#ffffff" text="#000000">
Hi Scott, <br>
<br>
Your understanding is spot on. At the moment our error handling
does option 3.3 - display an error message. When a fatal error
occurs, the php parser calls the registered shutdown function and
then we display a big error message, call stacks and source code
(whilst debugging is enabled). In the error handling class there is
a database logging function which would work if the database table
was created. There is also a setting in the errorhandler class that
when an error occurs, it can take it, convert it into a Exception
and then throw it so that the user code then deals with the error.<br>
<br>
There are many more comments in the errorhandler class file now and
I also tidied it up, so it may be worth taking a look.<br>
<br>
The final thing that is in there is the exceptionHandler. If an
exception is thrown and not caught this function will pick it up and
display a fatal error message.<br>
<br>
If you visit: <a class="moz-txt-link-freetext" href="http://localhost/timesheet/error-test">http://localhost/timesheet/error-test</a> there are a few
different errors in that file that can be commented in / out to see
how the error handler currently responds. The file resides in
/content/error-test.php<br>
<br>
I'm sure you will be able to take some inspiration from the joomla
error classes to improve ours.<br>
<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 09/03/2011 15:22, Scott Miller wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">I say go ahead and check things in. J* classes it
is. And I'll start trying to move some things into the site class
after you check your stuff in.<br>
<br>
Error handling is probably my biggest blind spot. I haven't been
in the "application development for pay" world since the early
1990's; what I typically write are administration scripts that
make my life easier, so I have very little need for advanced error
handling. So, I'm asking for the following:<br>
<ul>
<li>How do I go about using the error handling class(es)
correctly?</li>
<li>What's the big picture, or theory about how it is supposed
to work?</li>
<li>What does the user see when an arbitrary error occurs? <br>
</li>
<li>What functions are called for that output to be produced?</li>
</ul>
So, asking for that doesn't give you a good launching pad to start
with, so, I'll help you out here. And I understand it's in flux
yet, so just answer as best you can.<br>
<br>
My understanding about error handling:<br>
<ol>
<li>PHP program loads</li>
<li>an error handling function is registered so that when errors
occur, this function is called instead of whatever default
action would normally be taken</li>
<li>the function needs to check what the severity level of the
error is and then does something (one launching area, what
does ours do?)</li>
<ol>
<li>It could, as I gather what Joomla does, put all the errors
on a stack, which it later, presumably, deals with them
appropriately<br>
</li>
<li>it could stuff the error message(s) into a usually ignored
log file</li>
<li>it could immediately create a pop-up displaying the error
to the user<br>
</li>
<li>it could email the administrator(s)</li>
<li>I'm sure there are other possibilities I'm not mentioning</li>
<li>It could do multiple combination's of these actions</li>
</ol>
<li>(another launching point) Somehow, for some errors, the user
must be notified, how does ours go about that?</li>
</ol>
So, I've avoided looking at the current error handling classes up
to now 'cause I assume it will take a lot of effort to be able to
wrap my brain around enough of the code to tease out the "theory"
of how our error handling class(es) is(are) supposed to work. So,
at this point I don't yet know the function or method names of our
error handling class(es).<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Tue, Mar 8, 2011 at 11:48 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;">
Hello,<br>
<br>
I have got quite a few updates to make to the site loading
aspects of the site aswell as a neat way to tidy up the root
directory, but it will mean quite a few files will change or
even move. Therefore, before I am asking whether anyone has
any outstanding changes before I do anything?<br>
<br>
Main updates include:<br>
<br>
a) Updated the error handler code to give trace stacks, show
the actual line of code at fault and just generally more debug
information.<br>
<br>
b)Updated site class, integrated the installation handling
stuff into site class thus removing install.site.class and
other install related files that were effectively nasty
duplication hacks.<br>
<br>
c) tidied up the template parser code.<br>
d) implemented template parser tags that allow functions as
well as files to be called.<br>
<br>
e)a method to tidy up the root directory.<br>
<br>
f) implemented a method to log errors to a database (optional)<br>
<br>
Now in reference to Scotts email:<br>
<br>
Certainly for now we may aswell leave the class names as J*.
It is only a find a replace if we want to change them later.<br>
<br>
What do you need to know about the error handler class? - the
code is still not very mature and lots can be done with it to
tidy it up and improve its functionality.<br>
<br>
I agree, most of the code (the initialisation stuff) in
test-lang-stuff.php could go into the site class.<br>
<br>
Thanks<br>
<br>
Mark<br>
<br>
_____________________________________________<br>
<br>
Mob: 07725 695178<br>
Email: <a moz-do-not-send="true"
href="mailto:ma...@rw..." target="_blank">ma...@rw...</a>
<div>
<div class="h5"><br>
<br>
<br>
On 08/03/2011 23:16, Scott Miller 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 all,<br>
<br>
I've checked in a few more changes, mainly focused on
further trimming down of un-needed stuff from the
various classes, and the removal of un-needed classes.<br>
<br>
I'm still waiting for a discussion on whether we want to
continue using J* class names (JLanguage, JText, JFile,
JFolder, etc) or if we want to use something different,
and if so, what.<br>
<br>
Also still waiting to hear about how the error classes
work, and how to replace the commented out error stuff
in the jclasses with error stuff that will actually work
for us.<br>
<br>
I'm beginning to think about how to go about integrating
the JLanguage stuff into our existing classes. Should
the JLanguage stuff be part of the master site class?
I'm currently thinking it should.<br>
<br>
Isabelle, I think it will be useful to have language
specific routines that deal with how to correctly format
times, dates, and numbers in general. Can you point us
in the right direction as to how to go about doing this?<br>
<br>
-Scott<br>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|
|
From: Mark W. <ma...@rw...> - 2011-03-09 23:01:42
|
<!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 bgcolor="#ffffff" text="#000000">
That is fair enough. As Dave points out, 'never touch a running
system'. This point does hold true as there would be someone
somewhere where a key constraint would fail which would mean a huge
amount of work to make any database compliant with the new
constraints.<br>
<br>
Maybe we could write in some PHP based dependancy stuff however, as
for instance (with reference to txhseet v1.2 ish) if a task is
deleted from the system the total hours worked on a project is then
affected even though the clockings still exist in the db tables. I
think we should update the code such that when something is
'deleted' it is just marked as deleted and then not shown up, to
prevent this sort of issue from occurring.<br>
<br>
So far the only constraints I have played with is the RESTRICT
versions by which you can't do anything to break the system and the
database doesn't delete or modify anything for you.<br>
<br>
No foreign key constraints then.<br>
<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 09/03/2011 16: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>
Scott, basically you're right, we would need to specify mySQL and
InnoDB engine for all TSNG installations, and what is the gain in
our case? We are like 90% of all LAMP projects, in that we use a
DB just for persistency and not for transactional safety or
integrity.<br>
<br>
The main relation we have is like a dependancy tree -
client<-project<-task<-entry - and restrictions will just
make it harder to delete something higher in that tree (clients
with projects cannot be deleted). An alternative to restrictions
is sensible defaults, when a client is deleted then his projects
get assigned to No_client(0). But since deletion is not a common
use case, we haven't <br>
<br>
The other main set of relations are to do with the users, and
admittedly this is not clean yet (user_id is defined but not
really used). Here there is the problem of deleting users, for
which, when we discussed it before, it seems that the best answer
is to not delete users, but set them as inactive.<br>
<br>
So my vote would be -1, never touch a running system.<br>
Sorry <br>
<hr id="stopSpelling">
Date: Wed, 9 Mar 2011 15:34:34 +0000<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:sco...@gm...">sco...@gm...</a><br>
To: <a class="moz-txt-link-abbreviated" href="mailto:ma...@rw...">ma...@rw...</a><br>
CC: <a class="moz-txt-link-abbreviated" href="mailto:tsh...@li...">tsh...@li...</a><br>
Subject: Re: [Tsheetx-developers] Relational Database<br>
<br>
I know just enough DB theory to be dangerous here, so please
correct me where needed.<br>
<br>
My understanding is that for the Foreign key constraints to work,
we would need to write "triggers" so the database knows what do do
when certain events happen (deletion, addition, change of
records). I believe these "triggers" aren't exactly perfectly
portable between different databases, so we would have the need to
have different triggers written for whatever databases we decide
to support. <br>
<br>
Really our system is pretty darned simple from a database
perspective, so, my question would be, is it worth the development
time to tackle making the system truly relational? I'm currently
on the fence, but I'm leaning toward no :-) But, if you think
it's worth it, and want to do the heavy lifting, I'll certainly
support that decision.<br>
<br>
-Scott<br>
<br>
<div class="ecxgmail_quote">On Tue, Mar 8, 2011 at 11:57 PM, Mark
Wrightson <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a>></span>
wrote:<br>
<blockquote style="padding-left: 1ex;" class="ecxgmail_quote">Hi
All<br>
<br>
I have recently started looking into InnoDB Foreign key
constraints to<br>
create truely relational databases. Has anyone considered
doing this<br>
for tsheetx? Is there a reason why we cannot or should not?<br>
<br>
I have recently found a tool in PHPMyAdmin called 'Designer'
that looks<br>
pretty cool, and shows the links between tables much like an
OO class<br>
diagram does.<br>
<br>
Thanks<br>
Mark Wrightson<br>
<br>
--<br>
_____________________________________________<br>
<br>
Mob: 07725 695178<br>
Email: <a moz-do-not-send="true"
href="mailto:ma...@rw...">ma...@rw...</a><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Colocation vs. Managed Hosting<br>
A question and answer guide to determining the best fit<br>
for your organization - today and in the future.<br>
<a moz-do-not-send="true"
href="http://p.sf.net/sfu/internap-sfd2d" target="_blank">http://p.sf.net/sfu/internap-sfd2d</a><br>
_______________________________________________<br>
Tsheetx-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Tsh...@li...">Tsh...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/tsheetx-developers"
target="_blank">https://lists.sourceforge.net/lists/listinfo/tsheetx-developers</a><br>
</blockquote>
</div>
<br>
<br>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting A question and answer guide to
determining the best fit for your organization - today and in the
future. <a class="moz-txt-link-freetext" href="http://p.sf.net/sfu/internap-sfd2d">http://p.sf.net/sfu/internap-sfd2d</a><br>
_______________________________________________ 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> </blockquote>
</body>
</html>
|
|
From: David T. <tom...@us...> - 2011-03-09 16:00:56
|
Scott, basically you're right, we would need to specify mySQL and InnoDB engine for all TSNG installations, and what is the gain in our case? We are like 90% of all LAMP projects, in that we use a DB just for persistency and not for transactional safety or integrity. The main relation we have is like a dependancy tree - client<-project<-task<-entry - and restrictions will just make it harder to delete something higher in that tree (clients with projects cannot be deleted). An alternative to restrictions is sensible defaults, when a client is deleted then his projects get assigned to No_client(0). But since deletion is not a common use case, we haven't The other main set of relations are to do with the users, and admittedly this is not clean yet (user_id is defined but not really used). Here there is the problem of deleting users, for which, when we discussed it before, it seems that the best answer is to not delete users, but set them as inactive. So my vote would be -1, never touch a running system. Sorry Date: Wed, 9 Mar 2011 15:34:34 +0000 From: sco...@gm... To: ma...@rw... CC: tsh...@li... Subject: Re: [Tsheetx-developers] Relational Database I know just enough DB theory to be dangerous here, so please correct me where needed. My understanding is that for the Foreign key constraints to work, we would need to write "triggers" so the database knows what do do when certain events happen (deletion, addition, change of records). I believe these "triggers" aren't exactly perfectly portable between different databases, so we would have the need to have different triggers written for whatever databases we decide to support. Really our system is pretty darned simple from a database perspective, so, my question would be, is it worth the development time to tackle making the system truly relational? I'm currently on the fence, but I'm leaning toward no :-) But, if you think it's worth it, and want to do the heavy lifting, I'll certainly support that decision. -Scott On Tue, Mar 8, 2011 at 11:57 PM, Mark Wrightson <ma...@rw...> wrote: Hi All I have recently started looking into InnoDB Foreign key constraints to create truely relational databases. Has anyone considered doing this for tsheetx? Is there a reason why we cannot or should not? I have recently found a tool in PHPMyAdmin called 'Designer' that looks pretty cool, and shows the links between tables much like an OO class diagram does. Thanks Mark Wrightson -- _____________________________________________ Mob: 07725 695178 Email: ma...@rw... ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Tsheetx-developers mailing list Tsh...@li... https://lists.sourceforge.net/lists/listinfo/tsheetx-developers |
|
From: Scott M. <sco...@gm...> - 2011-03-09 15:35:03
|
I know just enough DB theory to be dangerous here, so please correct me where needed. My understanding is that for the Foreign key constraints to work, we would need to write "triggers" so the database knows what do do when certain events happen (deletion, addition, change of records). I believe these "triggers" aren't exactly perfectly portable between different databases, so we would have the need to have different triggers written for whatever databases we decide to support. Really our system is pretty darned simple from a database perspective, so, my question would be, is it worth the development time to tackle making the system truly relational? I'm currently on the fence, but I'm leaning toward no :-) But, if you think it's worth it, and want to do the heavy lifting, I'll certainly support that decision. -Scott On Tue, Mar 8, 2011 at 11:57 PM, Mark Wrightson <ma...@rw...>wrote: > Hi All > > I have recently started looking into InnoDB Foreign key constraints to > create truely relational databases. Has anyone considered doing this > for tsheetx? Is there a reason why we cannot or should not? > > I have recently found a tool in PHPMyAdmin called 'Designer' that looks > pretty cool, and shows the links between tables much like an OO class > diagram does. > > Thanks > Mark Wrightson > > -- > _____________________________________________ > > Mob: 07725 695178 > Email: ma...@rw... > > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Tsheetx-developers mailing list > Tsh...@li... > https://lists.sourceforge.net/lists/listinfo/tsheetx-developers > |
|
From: Scott M. <sco...@gm...> - 2011-03-09 15:23:08
|
I say go ahead and check things in. J* classes it is. And I'll start
trying to move some things into the site class after you check your stuff
in.
Error handling is probably my biggest blind spot. I haven't been in the
"application development for pay" world since the early 1990's; what I
typically write are administration scripts that make my life easier, so I
have very little need for advanced error handling. So, I'm asking for the
following:
- How do I go about using the error handling class(es) correctly?
- What's the big picture, or theory about how it is supposed to work?
- What does the user see when an arbitrary error occurs?
- What functions are called for that output to be produced?
So, asking for that doesn't give you a good launching pad to start with, so,
I'll help you out here. And I understand it's in flux yet, so just answer
as best you can.
My understanding about error handling:
1. PHP program loads
2. an error handling function is registered so that when errors occur,
this function is called instead of whatever default action would normally be
taken
3. the function needs to check what the severity level of the error is
and then does something (one launching area, what does ours do?)
1. It could, as I gather what Joomla does, put all the errors on a
stack, which it later, presumably, deals with them appropriately
2. it could stuff the error message(s) into a usually ignored log file
3. it could immediately create a pop-up displaying the error to the
user
4. it could email the administrator(s)
5. I'm sure there are other possibilities I'm not mentioning
6. It could do multiple combination's of these actions
4. (another launching point) Somehow, for some errors, the user must be
notified, how does ours go about that?
So, I've avoided looking at the current error handling classes up to now
'cause I assume it will take a lot of effort to be able to wrap my brain
around enough of the code to tease out the "theory" of how our error
handling class(es) is(are) supposed to work. So, at this point I don't yet
know the function or method names of our error handling class(es).
-Scott
On Tue, Mar 8, 2011 at 11:48 PM, Mark Wrightson <ma...@rw...>wrote:
> Hello,
>
> I have got quite a few updates to make to the site loading aspects of the
> site aswell as a neat way to tidy up the root directory, but it will mean
> quite a few files will change or even move. Therefore, before I am asking
> whether anyone has any outstanding changes before I do anything?
>
> Main updates include:
>
> a) Updated the error handler code to give trace stacks, show the actual
> line of code at fault and just generally more debug information.
>
> b)Updated site class, integrated the installation handling stuff into site
> class thus removing install.site.class and other install related files that
> were effectively nasty duplication hacks.
>
> c) tidied up the template parser code.
> d) implemented template parser tags that allow functions as well as files
> to be called.
>
> e)a method to tidy up the root directory.
>
> f) implemented a method to log errors to a database (optional)
>
> Now in reference to Scotts email:
>
> Certainly for now we may aswell leave the class names as J*. It is only a
> find a replace if we want to change them later.
>
> What do you need to know about the error handler class? - the code is still
> not very mature and lots can be done with it to tidy it up and improve its
> functionality.
>
> I agree, most of the code (the initialisation stuff) in test-lang-stuff.php
> could go into the site class.
>
> Thanks
>
> Mark
>
> _____________________________________________
>
> Mob: 07725 695178
> Email: ma...@rw...
>
>
>
> On 08/03/2011 23:16, Scott Miller wrote:
>
>> Hi all,
>>
>> I've checked in a few more changes, mainly focused on further trimming
>> down of un-needed stuff from the various classes, and the removal of
>> un-needed classes.
>>
>> I'm still waiting for a discussion on whether we want to continue using J*
>> class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use
>> something different, and if so, what.
>>
>> Also still waiting to hear about how the error classes work, and how to
>> replace the commented out error stuff in the jclasses with error stuff that
>> will actually work for us.
>>
>> I'm beginning to think about how to go about integrating the JLanguage
>> stuff into our existing classes. Should the JLanguage stuff be part of the
>> master site class? I'm currently thinking it should.
>>
>> Isabelle, I think it will be useful to have language specific routines
>> that deal with how to correctly format times, dates, and numbers in general.
>> Can you point us in the right direction as to how to go about doing this?
>>
>> -Scott
>>
>
|
|
From: Mark W. <ma...@rw...> - 2011-03-08 23:57:42
|
Hi All I have recently started looking into InnoDB Foreign key constraints to create truely relational databases. Has anyone considered doing this for tsheetx? Is there a reason why we cannot or should not? I have recently found a tool in PHPMyAdmin called 'Designer' that looks pretty cool, and shows the links between tables much like an OO class diagram does. Thanks Mark Wrightson -- _____________________________________________ Mob: 07725 695178 Email: ma...@rw... |
|
From: Mark W. <ma...@rw...> - 2011-03-08 23:48:39
|
Hello, I have got quite a few updates to make to the site loading aspects of the site aswell as a neat way to tidy up the root directory, but it will mean quite a few files will change or even move. Therefore, before I am asking whether anyone has any outstanding changes before I do anything? Main updates include: a) Updated the error handler code to give trace stacks, show the actual line of code at fault and just generally more debug information. b)Updated site class, integrated the installation handling stuff into site class thus removing install.site.class and other install related files that were effectively nasty duplication hacks. c) tidied up the template parser code. d) implemented template parser tags that allow functions as well as files to be called. e)a method to tidy up the root directory. f) implemented a method to log errors to a database (optional) Now in reference to Scotts email: Certainly for now we may aswell leave the class names as J*. It is only a find a replace if we want to change them later. What do you need to know about the error handler class? - the code is still not very mature and lots can be done with it to tidy it up and improve its functionality. I agree, most of the code (the initialisation stuff) in test-lang-stuff.php could go into the site class. Thanks Mark _____________________________________________ Mob: 07725 695178 Email: ma...@rw... On 08/03/2011 23:16, Scott Miller wrote: > Hi all, > > I've checked in a few more changes, mainly focused on further trimming > down of un-needed stuff from the various classes, and the removal of > un-needed classes. > > I'm still waiting for a discussion on whether we want to continue > using J* class names (JLanguage, JText, JFile, JFolder, etc) or if we > want to use something different, and if so, what. > > Also still waiting to hear about how the error classes work, and how > to replace the commented out error stuff in the jclasses with error > stuff that will actually work for us. > > I'm beginning to think about how to go about integrating the JLanguage > stuff into our existing classes. Should the JLanguage stuff be part > of the master site class? I'm currently thinking it should. > > Isabelle, I think it will be useful to have language specific routines > that deal with how to correctly format times, dates, and numbers in > general. Can you point us in the right direction as to how to go > about doing this? > > -Scott |
|
From: Scott M. <sco...@gm...> - 2011-03-08 23:16:43
|
Hi all, I've checked in a few more changes, mainly focused on further trimming down of un-needed stuff from the various classes, and the removal of un-needed classes. I'm still waiting for a discussion on whether we want to continue using J* class names (JLanguage, JText, JFile, JFolder, etc) or if we want to use something different, and if so, what. Also still waiting to hear about how the error classes work, and how to replace the commented out error stuff in the jclasses with error stuff that will actually work for us. I'm beginning to think about how to go about integrating the JLanguage stuff into our existing classes. Should the JLanguage stuff be part of the master site class? I'm currently thinking it should. Isabelle, I think it will be useful to have language specific routines that deal with how to correctly format times, dates, and numbers in general. Can you point us in the right direction as to how to go about doing this? -Scott |
29 messages has been excluded from this view by a project administrator.
