You may want to have a look at this:
http://www.dhtmlgoodies.com/scripts/drag-drop-custom/demo-drag-drop-3.html

Cheers....Fish


On Sun, Nov 23, 2008 at 6:12 AM, <[EMAIL PROTECTED]> wrote:

> Does it support interaction in terms of allowing user to click on
> individual part of the composite image and use that event to update the
> database? Other words does it support interactive graphics?
>
> > On Sat, Nov 22, 2008 at 4:33 PM, Micah Stevens
> > <[EMAIL PROTECTED]>wrote:
> >
> >> On 11/21/2008 07:55 AM, David Giragosian wrote:
> >> > On 11/21/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> >> I have a PHP application that accesses data from MySQL. There is
> >> table
> >> >> called "rooms", and table called "beds". There is another table
> >> called
> >> >> "patients". Patients are being placed into beds, and beds are in the
> >> >> rooms. PHP application currently displays all information in textual
> >> mode
> >> >> via regular HTML tags. But I would like to have that information
> >> displayed
> >> >> in graphical mode instead of textual mode.
> >> >>
> >> >> Is there a way to display this information from the database
> >> graphically.
> >> >> Graphic would represent a room, and it would contain beds inside. You
> >> >> would be able to see visually which beds are occupied and which are
> >> free
> >> >> by looking at the graphics.
> >> >>
> >> >> User of the system wants pictures instead of text displayed via HTML
> >> >> tables as a list of entries.
> >> >>
> >> >> Anyone knows anything like this?
> >> >> Thanks,
> >> >> Dzenan
> >> >>
> >> >
> >> >
> >> > PHP has the GD library with a fairly extensive set of functions for
> >> creating
> >> > images <http://us2.php.net/gd>>.
> >> >
> >> > You can grab data from MySQL and then use the GD functions to create
> >> images
> >> > dynamically. It can be tedious, as you create the image pixel by
> >> pixel,
> >> but
> >> > the results are very good.
> >> >
> >> > David
> >> >
> >> >
> >> Or for reduced CPU overhead, just make some images for beds and rooms
> >> and use tables or positioned DIV tags to place them in the appropriate
> >> place based on the database information.
> >>
> > To the OP:
> >
> > The graphical capabilities of PHP are covered in, for example, "Beginning
> > PHP4", by Choi, Kent, Lea, Prasad, and Ullman, Chapter 15.  The nature of
> > it
> > is that PHP has built in libraries, and you create a logical sandbox,
> draw
> > on it and manipulate it (at which point it is buffered internally in some
> > convenient form), then emit it in one of the supported graphical file
> > formats.  It is a very easy process.
> >
> > I would guess that there are online tutorials as well.
> >
> > http://www.php.net/manual/en/function.imagecreate.php
> >
> > You have to, of course, be careful about browser image buffering and so
> > on,
> > but there are standard ways to handle that by making sure the browser is
> > aware it may not cache.
> >
> > The approach is very powerful because (if I'm remembering correctly), the
> > underlying graphics library provides primitives for polygon shading,
> > printing text, and so on.
> >
> > The approach involving selecting essentially which graphics to include in
> > a
> > tabular grid is also a good approach.  IMHO the argument about CPU
> > efficiency of this approach is very weak -- when you get down to making
> > probably < 200 calls to manipulate the graphical sandbox, each of these
> > calls is going to be tight code in the library that does memory
> > manipulations.  The approach follows the standard design rule that
> > low-frequency interactions (draw object 1, draw object 2) etc. may be
> done
> > relatively inefficiently in a scripting language, but the high-frequency
> > interactions (turn on pixel x,y; turn on pixel x+1, y, ...) are done in
> > compiled C or assembly-language.  I don't believe this will be much of a
> > CPU
> > burden on a server.  It would be more concerned if PHP were manipulating
> > pixels or segments one-by-one, but the library isn't designed to make
> this
> > necessary.
> >
> > Summary:  (a) Both approaches are quite good, and (b) the CPU efficiency
> > argument for stuffing prepared images into a table or similar may be
> weak.
> >
> > The Lizard
> >
>
>
>
> --
> MySQL General Mailing List
> For list archives: http://lists.mysql.com/mysql
> To unsubscribe:
> http://lists.mysql.com/[EMAIL PROTECTED]
>
>

Reply via email to