|
From: Mark W. <ma...@rw...> - 2011-04-15 21:51:45
|
<!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">
I think we should really start making more use of mantis. Mantis is
a fantastic tool and its functionality is designed to aid project
development i.e. roadmaps. If items are added to mantis then they
cannot be forgotten about. Yes the mailing list is archived but i
bet noone ever goes searching through the mailing list for forgotten
ideas, whereas if it was added as a new feature on mantis, assigned
to a member and given a target version such that it appears on the
roadmap, everyone then has a comprehensive todo list to get the next
version out of the door.<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/04/2011 22:39, Scott Miller wrote:
<blockquote
cite="mid:BAN...@ma..."
type="cite">Absolutely, take the time you need to finish your
school project, this will still be here after that.<br>
<br>
I would agree that session objects seem to be the thing we should
be using to keep track of these items. Since there's no real
"bug" yet, and I've been pondering it off and on for months, and
it's now in the mail list archives, I don't think we'll forget,
there's really no need to add this to mantis at this time...<br>
<br>
-Scott<br>
<br>
<div class="gmail_quote">On Fri, Apr 15, 2011 at 9:10 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"> Hi Scott, <br>
<br>
I was thinking a little bit about this yesterday as I spent
a substantial amount of time fixing the $post variables. As
it currently stands, the $post variable is now in the
gbl.class.php and is accessed via gbl::getPost() and
gbl::setPost(). Please let me know if a particular page
doesn't work as it should. <br>
<br>
If you want to maintain state between page refreshes then
the best way to achieve this is through the use of the
$_SESSION object or serialised classes embedded in the
$_SESSION object. I will update this at somepoint but at
the moment I am still trying to work my way through the
codebase to make things just work. The move to the OO
format is a huge undertaking and it is not really my top
priority at the moment as I have a project dissertation that
needs my attention for the next couple of months. Scott
could you add this item into mantis and assign it to me?<br>
<br>
Cheers<br>
Mark<br>
<pre cols="72">_____________________________________________
Mob: <a moz-do-not-send="true" href="tel:07725%20695178" value="+17725695178" target="_blank">07725 695178</a>
Email: <a moz-do-not-send="true" href="mailto:ma...@rw..." target="_blank">ma...@rw...</a></pre>
<div>
<div class="h5"> <br>
On 15/04/2011 21:04, Scott Miller wrote:
<blockquote type="cite">In the previous versions of
TSNG, I'd attempted to better keep track of what
"context" the user was in. I'd accomplished this by
making use of a variable I'd called $post, and used
that whenever forms were submitted. This was much
better than it was previously, but it was not flawless
by any stretch of the imagination.<br>
<br>
So, to help make sure everyone understands what I'm
talking about, allow me to expound on what the word
"context" means herein. Context is sort of the "state
of mind" the user is in when trying to accomplish
something. As a normal user, if I go back in time to
look at something lets say in the weekly form, and
then decide I want to look at that with a different
form, say the monthly form, in previous versions, by
switching forms, the application totally forgot the
user had gone back in time, and presented the current
month again. By keeping track of context, the user is
now presented with the month the user had gone back to
look at. This is one very basic and important item of
context that I think we need to keep track of, what
date is the user currently interested in?<br>
<br>
Another example is if I'm now an administrator, and a
user has some problem with their previously entered
time, I can "become" the user by changing the "context
user" and from there, I can act as if I was the user
and I can even modify the user's time entries if I
need to do so. (Note: this option is only available to
the "administrator" accounts, and to guard against
unscrupulous managers, who might be tempted to
fraudulently modify an underling's times, never make a
manager an administrator. It is quite amazing in a
tiny office how often we as administrators had to
legitimately help fix someone's time entries).<br>
<br>
So far we have <br>
<ul>
<li>Context</li>
<ul>
<li>user id</li>
<li>date user is interested in</li>
</ul>
</ul>
We can add other items; if we're looking at a report
and we are interested in a range of dates for a
report, we need to keep track of the beginning and
ending date of interest. With new options just
created, another item might be if we want page areas
shown or hidden.<br>
<br>
So, with all this, my main question to the group is
how do we effectively keep track of all this potential
context? With Mark as the OO guy, I'm hoping you have
some good ideas for helping us keep track of it all,
and I'm hoping that option is better than the hugely
long set of post variables currently passed back and
forth. This is particularly important when we move to
using the java pop up calendar for navigation...<br>
<br>
-Scott<br>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</blockquote>
</body>
</html>
|