Re: [Tsheetx-developers] How does the template stuff work?

[Scott M. <sco...@gm...>]

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 &euro;
>>>>>>
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>