Re: Re: Pop-up message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Is there some reason you can't simply use a javascript alert on the page refresh?

if(isset($queue)){
   echo "
   <script type=\"text/javascript\">
   <!--
   alert(\"$queue\");
   -->
   </script>";
}

> 
> From: Lester Caine <lester@xxxxxxxxxxx>
> Date: 2005/03/01 Tue AM 03:18:58 EST
> To: php-general@xxxxxxxxxxxxx
> Subject: Re:  Pop-up message
> 
> Richard Lynch wrote:
> 
> > Lester Caine wrote:
> > 
> >>At the risk of being shouted at because *I* know it's not a PHP problem!
> > Actually, it's a client problem :-)
> Yep - but with so many different ways of doing it, which client method 
> would be best ;)
> 
> >>I have a page that is being refreshed every 30 seconds or so, and
> >>displays a list of 'tickets' waiting to be dealt with on a list from a
> >>database query. No problems there, but a couple of sites now want me to
> >>add a pop-up warning when a ticket is added that has a staff ID matching
> >>the logged in user.
> > 
> > Your first task is to convince the client what an incredibly stupid idea
> > this is.
> Actually it's not - which is part of the problem - these are all private 
> networks and this is to replace 'reception' trying to phone the member 
> of staff - who may already be on the phone - to tell them an appointment 
> has arrived. So I just ant to 'queue' something on the their machine.
> 
> > And that it won't work with all the popup blockers.
> Have a handle on that, and the customer knows the problem, they are even 
> willing to consider a switch to Firefox if that will help. Tabbed 
> browsing with queue's on different tabs makes a lot of sense :)
> 
> > And if it did work, it would just annoy the [bleep] out of their users.
> > 
> > I know I'm preaching to the choir, here, but I have to go on record with
> > this statement.
> I know all the arguments, but hopefully you can see the problem - how do 
> we tell the 'target' that there is someone waiting - and the clock is 
> running on performance figures :(
> 
> >>I can drive a sounder in the target browser, but need kicking in the
> > 
> > A sounder?  You mean like make my browser make noise?  ICK!!!
> Yep - and if they are on the phone they may not here it either.
> 
> >>right direction for a method of adding a pop-up window. Ideally it needs
> >>to be browser agnostic, which is where the problem comes given the
> >>pop-up blockers and other 'toys' that are being added to the browser end
> >>of things.
> > 
> > You're not going to defeat the popup blockers in the long run.
> As I said - we have control over machine configurations - to a certain 
> extent, and if a user decides they want to be clever it's their 
> performance figures that will be affected ;)
> 
> > You are better off using clean simple code in an onLoad in your body tag
> > to open the new window.  Something like:
> > <body onLoad="window.open(URL);">
> > where the URL loads in that user's recently added items.
> > 
> > Either the users will accept the popup and whitelist it in their popup
> > blocker, or they won't.
> That is probably where I am at, but I was looking to see if anybody had 
> any other ideas for passing messages. Probably should have explained 
> better what I was trying to do, but I often see 'Did you try so and so' 
> which provides another avenue to look at.
> 
> > And if a lot of them don't accept it, as they shouldn't, that tells you
> > right there what a dumb idea this was. :-)
> > 
> > But running around to find code to "defeat" the popup blockers will be a
> > total waste of time -- and you'll end up with something so hacked and so
> > un-maintainable that you'll have to fix it every six months, even if the
> > popup blockers don't find workarounds to block your workarounds that popup
> > the windows that they don't want popped up.
> Already covered that, but there *IS* a need for a controlled way of 
> passing messages from the server to the client ...
> 
> >>So can anybody point me in the right direction for a CURRENT method of
> >>achieving this, many of the bits I've found so far are somewhat
> >>antiquated, and fail in one way or another :(
> > 
> > Perhaps it would be better to segregate the tickets into those associated
> > with the User logged in, and those that are not.
> > 
> > Or to at least sort them that way, regardless of their other sorting options.
> > 
> > For that matter, don't even *BOTHER* to show me items that aren't mine,
> > unless I specifically ask for them.
> Other people in a department need to be able to see who is waiting on a 
> queue, only some callers are appointments, so a browser is left logged 
> in with that queue selected so people can monitor things. As soon as an 
> appointment is logged, the page changes to a staff ID specific page, and 
> as long as it is visible in the background, it can be seen, but 'other 
> systems' insist on being displayed full screen, which is what is being 
> the pain. If (actually probably WHEN) we can get the applications that 
> don't want to share to play nicely ...
> 
> > Build a system that detects tickets that sit un-assigned for too long, and
> > randomly assigns them, or, better yet, assigns them based on factors such
> > as:
> > Ticket features (IE, interface tickets to interface team members)
> > Productivity (IE, don't assign as many tickets to your slow team members
> > as your fast ones)
> > User Status (IE, if I'm on vacation, don't assign me anything)
> Already covered - we know the person is in the office - and that they 
> are waiting for a caller - They COULD be advised by a telephone call 
> (and in some offices I can actually dial the number via PHP), and in 
> some offices the telephone system has a voice mail, but the 30-60 
> seconds to navigate that when you have 5 - 10:30 appointments all 
> arriving at once is what we are trying to bypass. The receptionist has 
> the details on their screen, and should just be able to say - take a 
> seat and Mr X will see you shortly - and go on to the next caller.
> > 
> > That way, no tickets is left sitting there "too long" but nobody has to
> > deal with tickets that aren't assigned to them.
> > 
> > Just an idea.
> > 
> > In general, though, I only mean:
> > 
> > Come back at the client with more than just "That's a dumb idea" (which it
> > is)
> > 
> > Come back with a "Here's a MUCH better way to do this" proposal.
> Have you got one :(
> The problem is how to provide an indication they they need to check the 
> queue page - what ever is on it !
> 
> > "That's a dumb idea" just gets you more headaches.
> > A solution for a better solution makes you look real smart. :-)
> > Yes, this may turn out to be a waste of your time, because the client is
> > REALLY dead set on these popups, and you'll end up being miserable about
> > them not taking your proposal as well...  Time to start looking for a new
> > client. :-v
> Not necessarily pop-up, but something to flag the need to do something 
> as soon as practical. Pop-up is not right, but can at least be 
> controlled in the environment I am working in (government/LA private 
> networks). I am looking for some pointers to the 'smart' idea though :)
> 
> -- 
> Lester Caine
> -----------------------------
> L.S.Caine Electronic Services
> 
> -- 
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux