tsheetx-developers Mailing List for Timesheet Next Gen (Page 11)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Absolutely, please don't take anything personally, I just want it to work
and work well.

The one line change to the CSS worked a treat.  Much better :-)

So, ok, I'm not totally convinced of the OO stuff, so, please bear with me.
With my class to read in and store the configuration information, it doesn't
matter what is added to the configuration table in the database everything
is read in, and the class doesn't need to be edited every time something new
is added.  Only when and where that new thing is needed do we need to change
code.

In the version being championed by Peter and Mark, every new config item
needs two more functions to be added to the class, on top of the additional
code surrounding that item.

I guess I'm more of a minimalist, I don't feel the added layer of extra
code, and extra function call for each config data look up, is a good trade
off to ensure against sloppy code.

-Scott

On Sun, Feb 13, 2011 at 12:40 PM, David Thompson <
tom...@us...> wrote:

>  Guys, try to keep your exchanges on the developer-list (that means
> checking the addressing when you reply).
> That way there is a (searchable) record for everyone to see what is going
> on.
>
> Critisism should be nothing personal (hard on the product, but soft on the
> person), in that way it can only make the software better.
> Cheers
>
> ------------------------------
> Date: Sat, 12 Feb 2011 19:45:43 +1100
> From: pal...@gm...
> To: sco...@gm...
> CC: ma...@rw...; tom...@us...
> Subject: [SPAM] Re: 2.0 demo feedback
>
>
> Scott,
> I agree also with this issue. I think it can be solved by continuing in the
> direction we are going. That is, to have minimal html structures and minimal
> html tables, and to use css includes to do all the formatting. I am not a
> css expert. In fact I would rate my css skills at below beginner. However
> the book I am reading, "CSS The Definitive Guide" by Eric Meyer (O'Reilly)
> has numerous examples where the styles are set up to allow expansion and
> contraction of table cells etc. So I have confidence we can fix the problem
> you raise.
>
> The next phase of the presentation is now to devise and test css styles to
> consistently format the monthly, daily, weekly and simple time entry tables.
> But that will take some time to organise.
>
> I would also like to "modernise" the menu system into a set of tabs, or
> maybe a hierarchical directory tree on the left.
>
> Finally, I'm soon to take off on a trip to colder places late this month
> and next, returning around 17 March.
>
> Ciao
> Peter
>
> On 12/02/11 07:51, Scott Miller wrote:
>
> (finally changed the subject)
>
> Another complaint:  We need the site to be able to (mostly) fill a browser
> window.  I have a large screen, and it irritates the begeezers out of me
> when I have a site that can only fill a small portion of my available
> screen.  This is especially important for the simple timesheet where you
> have a potentially lengthy description field that suddenly becomes nearly
> unusable because the space available is tiny.  Configurations, user mgmt,
> reports, all these need the ability to expand horizontally when they can.
> This may not be as important for all areas, but I think it would be bad form
> to allow variable pages only in a few areas...
>
> -Scott
>
>
> On Fri, Feb 11, 2011 at 8:24 PM, Scott Miller <sco...@gm...>wrote:
>
> Hey guys,
>
> Ok, admittedly, I'm not an OO guru.  But, could you please explain why the
> table name class has been created in the way that it has?  In particular,
> I'm totally failing to see how the many tiny routines to set and return the
> private variables is a good idea.  Why not declare the variables public, and
> allow the other routines to access the table class variables directly?  And
> we could have the class itself, read an appropriate .ini file to load the
> variables in the first place, rather than just including it as a php file as
> is currently done.
>
> Now if there were reasons to protect the members of the class, perhaps some
> of this is needed for the authentication piece, but I honestly can't come up
> with a good reason that most of the classes' variables couldn't be public.
>
> -Scott
>
>
> On Fri, Feb 11, 2011 at 7:38 PM, Scott Miller <sco...@gm...>wrote:
>
> Hey Peter, Mark,
>
> I just downloaded (checked out via svn) the 2.0-demo branch.  I haven't
> played with it a lot, but for the most part it looks good.
>
> I do have to complain about the new date navigation.  It looks ok, but it's
> a pain to use.  I now have between 5 and 10 clicks of the mouse to change
> the date. That is, in my opinion, way too many; so I think that whole piece
> needs to be rethought.
>
> I'm going to go check out some of the code changes now, and maybe see if I
> can't add the new configuration stuff into your 2.0-demo...
>
> -Scott
>
>
>

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)

tsheetx-developers Mailing List for Timesheet Next Gen (Page 11)

tsheetx-developers — Timesheet Next Gen - Developer's mailing list