Re: Is mod_perl the right solution for my GUI dev?
From: Fran Fabrizio [EMAIL PROTECTED] You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. You can avoid most of the grunge work here by using one or more of the high-level modules like Embperl, Apache::ASP, Mason, etc. that handle sessions and a lot more for you. One thing that I don't think anyone has mentioned so far that is an inherent advantage to a web interface is that unless you really go out of your way to break it, you automatically end up with a well-defined client-server network interface. Thus as you or your users discover parts of the application that can be completely automated later, someone can easily whip out some scripts with LWP to get/post anything without human intervention where with a traditional GUI it takes a massive effort to ever go beyond pointing and clicking. Making an interface easy to use is often at odds with making it easy to automate, and in the long run anything you can make 'full-auto' is going to save time and money (unless the object of the site is to make the user view a lot of banner ads...). Les Mikesell [EMAIL PROTECTED]
Re: Is mod_perl the right solution for my GUI dev?
Ron Savage wrote: On Tue, 25 Jun 2002 12:22:15 -0400, Fran Fabrizio wrote: Fran [snip] from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated Did you consider using my module CGI::Explorer? I wasn't aware of it's existence. I just now downloaded it and played with the demo. Unfortunately, it looks like it might not have helped in my case. It appears that it is doing a round trip to the server and back on every open/close of a node. That's exactly what I had to avoid. Our tree has 1000 elements (and growing) pulled dynamically out of a database. In a multi-user environment we don't want to be hitting the server that hard just for a navigational menu for every click of every user. We serve up the entire tree when the user logs in, and all of the state maintenance is handled client-side in terms of what's been opened, etc... we never go back to the server unless the user has requested a refresh of the tree. I could be wrong in how your module operates, that's just from a 3 minute session with the demo. It's good that you've made this available though, most people will have more reasonably sized and constructed trees than we do and should find that module useful. :-) -Fran PS - May want to take a look at it on Mozilla. There seemed to be slight table layout issues on my Mozilla 1.0 (yeah, I need to upgrade :-) that caused the graphics to slightly misalign.
Re: Is mod_perl the right solution for my GUI dev?
On Wed, 26 Jun 2002 09:37:58 -0400, Fran Fabrizio wrote:
Fran
Ron Savage wrote:
On Tue, 25 Jun 2002 12:22:15 -0400, Fran Fabrizio wrote:
Fran
[snip]
from first-hand experience, hell my current project has both of
these
things in a web interface, and neither were trivial. I crafted an
expandable-tree menu (think Windows Explorer style menu) from
HTML,
CSS,
JavaScript and HTML::Template. I have graphs dynamically
generated
Did you consider using my module CGI::Explorer?
I wasn't aware of it's existence. I just now downloaded it and
played
with the demo. Unfortunately, it looks like it might not have
helped in
my case. It appears that it is doing a round trip to the server and
back on every open/close of a node. That's exactly what I had to
avoid.
Yes, it does a round trip. Such is life.
Our tree has 1000 elements (and growing) pulled dynamically out of
a
database. In a multi-user environment we don't want to be hitting
the
server that hard just for a navigational menu for every click of
every
user. We serve up the entire tree when the user logs in, and all of
the
state maintenance is handled client-side in terms of what's been
opened,
etc... we never go back to the server unless the user has requested
a
refresh of the tree. I could be wrong in how your module operates,
that's just from a 3 minute session with the demo. It's good that
you've made this available though, most people will have more
reasonably
sized and constructed trees than we do and should find that module
useful. :-)
Thanx.
-Fran
PS - May want to take a look at it on Mozilla. There seemed to be
slight table layout issues on my Mozilla 1.0 (yeah, I need to
upgrade
:-) that caused the graphics to slightly misalign.
That may be due to me using some non-standard (Netscape-specific)
HTML. Eg 'absmiddle' as in
$q - img({src = $image, align = 'absmiddle', width = 17, height
= 17})
And when Mozilla has stabilized, in a year or so, I'll consider
installing it. Reports of its stability today are not going to sway
me :-). Such, too, is life.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 27/06/2002
http://savage.net.au/index.html
Is mod_perl the right solution for my GUI dev?
Hello list, Please pardon me if it is not related to the list. We have a C application which runs on both SCO open server and Red Hat Linux with Oracle/Informix database. It is a text based application originally developed for CRDS box with UNOS. Now management needs a GUI for the text application.I have developed some report screens using Apache/Mod_perl/GD. They kind of liked it. Now they want to do a full fledged GUI. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. Any suggestions on this will be really appreciated. Thanks, Ganesh.
Re: Is mod_perl the right solution for my GUI dev?
At 16:09 25.06.2002, Ganesan M wrote: Hello list, Please pardon me if it is not related to the list. We have a C application which runs on both SCO open server and Red Hat Linux with Oracle/Informix database. It is a text based application originally developed for CRDS box with UNOS. Now management needs a GUI for the text application.I have developed some report screens using Apache/Mod_perl/GD. They kind of liked it. Now they want to do a full fledged GUI. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. My answer: it depends :) -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Is mod_perl the right solution for my GUI dev?
At 16:09 25.06.2002, Ganesan M wrote: My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? Ganesan.
FW: Is mod_perl the right solution for my GUI dev?
-Original Message- From: Prakash Chatterjee [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 16:00 To: Ganesan M Subject: RE: Is mod_perl the right solution for my GUI dev? Actually, no you can't. At least not without masses of Javascript and god knows what else. And of course you'll have no guarantee that it won't fall over on the client's browser. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? -Original Message- From: Ganesan M [mailto:[EMAIL PROTECTED]] Sent: 25 June 2002 15:54 To: [EMAIL PROTECTED] Subject: Re: Is mod_perl the right solution for my GUI dev? At 16:09 25.06.2002, Ganesan M wrote: My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI. The problem you're looking at is rather different: should you try and create a *web frontend* or should you create a normal GUI? Largely depending on the nature of your application, the answers will be different. I can't say much more without knowing more about what you're trying to do: but to me it seems like if you need GD to do the job, you should probably be looking at a standard GUI instead. This needn't be done in Java or VC++, you could use any programming language with a windowing library, like Perl with Tk (or Gtk or Qt bindings, but I don't know much about any of those) or anything else. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? Ganesan.
Re: Is mod_perl the right solution for my GUI dev?
Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? No, not at all. The web is bound by HTTP and HTML. This comes with many ramifications. There are three main areas where I have and you will run into problems: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. This is just the tip of the iceberg. -Fran
Re: Is mod_perl the right solution for my GUI dev?
Thanks for the info. What I am looking for here is: just a front-end GUI which will interact with the existing C programs. The base application is written in C. That is not going to change(That is one heck of the job to re-write the C application). Perl programs will be used to get the data from C programs and display it in a Graph and some fancy menus will be used to drive the C applicaiton. For graph I will be using GD and for menus CGI/Javascript/DHTML/CSS and of course, Apache is my web interface. How good is this solution? Ganesan. Please correct me if this is wrong. What is the big difference between web frontend and a normal GUI? Can't you do everything in the web frontnend that you do in normal GUI? No, not at all. The web is bound by HTTP and HTML. This comes with many ramifications. There are three main areas where I have and you will run into problems: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. This is just the tip of the iceberg. -Fran
Re: Is mod_perl the right solution for my GUI dev?
Fran Fabrizio writes: - Real-time data updates. HTTP is stateless: it serves up the page then closes the connection. Any updating involves a round-trip back to the server. In traditional GUI, you just hold a db connection and repaint the areas that are updated. Solved with refresh? JavaScript and Java can also help here. For interactivity, check out: http://www.cs.brown.edu/people/dla/polytope/tetra.html - State maintenance. Since it is stateless, you have to jump through a lot of hoops to realize that two requests are coming from the same person, since they could be handled by two different child processes or even two different servers. This has all sorts of ramifications on user login, user preferences, where the user was in the application, etc... you have to do a lot of work on the server side to realize that it's the same client that keeps talking to you. Cookies work fine. - Fancy interface widgets/layouts. HTML/CSS/JavaScript/DHTML can only get you so far. If you need fancy menu types, forms, layouts, etc... it quickly becomes tedious/impossible on the web. Tedious is questionable. Impossible, I seriously doubt. Remember, you can always delegate part of your screen to a Java applet, although I strongly recommend you avoid this. This is just the tip of the iceberg. Let's talk about the positives: + You update the server and instantly all clients are up-to-date. + You can detect incorrect usage, bugs, etc. by parsing a single log file, in real-time + The system is immune to operate system upgrades. And DLL hell on Windows boxes. + You access the system from anywhere reliably and securely. You don't have to open up a database connection to anybody but the Web server(s). + There is only one version of the software. + Support people can view the output sent to the client exactly as the client received it. Including following a series of actions. + The use of a Web browser is familiar to most users. + The user can keep multiple views of the pages she wants, not what the application decides to offer. + Bookmarks allow users to structure their view of the application. Advanced users can create new organizations (short cut pages) for themselves and their co-users. + Users can share information easily (send page by email, mail bookmarks, print page, save to disk, save picture, etc.) I'm sure others will add to the list. Rob
Re: Is mod_perl the right solution for my GUI dev?
[snip] The problem with all of the above is that it takes a VERY VERY complex analysis, planning, deployment, and long term environmental support infrastructure that most companies just don't have. So while J2EE all sounds great on paper, implementation of any reasonable J2EE system actually can create MORE man hours of work than a more straightforward procedural style implementation. It a matter of where you want to put the work, on the development side or on the implementation/support side. People forget or (don't want to remember?) that perl can utilize OOP, Design Patterns, and just good old polymorphism in a more straight forward procedural style implementation. It's especially important to think in these way in those spots you can guess they are going to scope creep on you down the road. [snip]. People can archetect the most elegant system in the world but if you don't have the people to make it all happen, then you have nothing after months and months of development work. -Zac Zac is absolutely 100% right. That was one heck of the answer. This will be very useful when I talk to the management. I hope zac doesn't mind if I quote his e-mail in the meeting ;-). Ganesan. My suggestions are: 1. Get rid of screen driver codes from the existing C programs 2. Use Inline C in the mod_perl programs and run it through apache webserver as a web page. But, some of my colleagues are suggesting to write a Java/VC++ Interface for the GUI.
Re: Is mod_perl the right solution for my GUI dev?
Rob Nagler wrote: Solved with refresh? JavaScript and Java can also help here. Yes, solved with refresh. Of the entire page. Which may be quite complex and have some hefty SQL queries, etc...not to mention other issues such as network latency, the re-rendering of the page, etc...all distract from the user experience, which may or may not be an issue for the particular application. For example, I once coded an HTML-based game where you guessed movie quotes and if you got it right, you replaced it with one of your own. Two of the issues were 1. I wanted a list of who was currently playing but it quickly got out of date and to update it would mean to refresh the entire page, go to frames, or put the list in a separate window, all messy. 2. When one user correctly guessed a quote, I would have liked to have all the other users' screens update with that new info, but that's impossible without having something like a java applet embedded in the page checking for new data and forcing a refresh of the page. Yes it works, but it's messy once again. These are real issues, and issues which I have solved as best as possible on the web but that are easier in other systems. Cookies work fine. You oversimplify. Cookies do work fine. What creates, reads, modifies, validates the cookies? What ties the cookies to useful state information that is stored server-side? There's a lot of coding potentially involved. Yes, perl modules exist. Yes, they'll most likely need customization (in my case, I've customized AuthCookie, and tied it to Apache::Session. It wasn't the end of the world, but it wasn't trivia. A cookie by itself is of rather limited usefulness. Tedious is questionable. Impossible, I seriously doubt. Remember, you can always delegate part of your screen to a Java applet, although I strongly recommend you avoid this. Reinventing common widgets by coding up in HTML, CSS, JavaScript something that's a one-liner in a typical GUI environment is not tedious? I think you're oversimplifying again. As for a Java applet, a java applet ceases to be a web frontend. It's a GUI front end using the web as a communication/distribution layer. Once it's launched, you use stateful sockets to talk back to the server, etc... If you find yourself doing a majority of your interface via java applet (which is not something you want to try if cross-browser implementation is a desired feature, by the way), then you might as well make it a standalone java app, especially since you're apt to hit the applet security sandbox on any sort of robust app. There are a TON of positives to web frontends. I'm not arguing. I have made my living for the past 8 years building these things, I'm a friend of the web front end. =) You've captured the positives quite well, so I don't need to reiterate. But let's not fall into the trap of saying the web is the best tool for every front end usage imaginable. The user has said fancy menus and graphs are to be the mainstay of the app. I speak from first-hand experience, hell my current project has both of these things in a web interface, and neither were trivial. I crafted an expandable-tree menu (think Windows Explorer style menu) from HTML, CSS, JavaScript and HTML::Template. I have graphs dynamically generated using GD::Graph. Both took time, lots of trial and error, and lots of hair-pulling. Massaging the data for GD::Graph was just one chore I remember being harder than expected. These tools worked and are great tools that enable things on the web that aren't otherwise possible, but it was hard -because- it was a web app with all the inherent limitations - these things are much more native to traditional GUIs. In my case, we have a -need- to be a web app and so I'm willing to jump through hoops to make the interface richer where we need it to be, but if I was choosing between web and traditional, and I didn't -need- web, and I knew that graphs and fancy widgets were the mainstay of my app, I'd think twice before trying web. Fancy widgets especially are not that much fun to code on the web when a very robust library of them already exist for most GUI systems. Yes, it can be done (though there are still some things which I found impossible, some widgets which I don't think can be duplicated acceptably on the web. I like clicking on column headers and have them resort without doing a round-trip, for instance) but it's not much fun sometimes. That's my only point. -Fran
Re: Is mod_perl the right solution for my GUI dev?
Thank you all for all your input on this. Here are the reasons why I chose web interface using Apache/CGI/Mod_perl/GD for our front-end reports. * Quick solution. Our management needed the report screens in a very short period. * Our C application runs on two different OS and two different DB. SCO openserver and Linux, Informix and Oracle. Our front-end needed multi-platform support. * Perl can go with any major language. AFAIK, perl interaact very well with any language. * Re-designing the look and feel (appearance) is very easy with web interface. * GD generates graphs on the fly. I don't know which other softwares do the same. * With Apache/perl web interface you do not need to install anything at the client side. (No dll/library installation problems). * As Zac Morris said, we did not have time and resources to go through a complex J2EE deployment. I would like to continue in the same web front-end path for more interactive forms. May be I will have to fight with Javascript more. I just want to know is this the right path? Someone suggested perl/TK. Again, you have to write 4 different codes for 4 different platforms. More suggestions on this are welcome. Once agin, thanks for all your input. Ganesan.
Re: Is mod_perl the right solution for my GUI dev?
Well it sounds like most of your design goals are pointing you towards the web interface. These same goals are what made me choose web even though I knew that I'd have to make some sacrifices on the interface. You'll be able to do it fine on the web, just be prepared to be flexible with the interface and learn to accept/work around the web's inherent limitations. Some thoughts: * GD generates graphs on the fly. I don't know which other softwares do the same. GD sits on top of C's gd library. I would like to continue in the same web front-end path for more interactive forms. May be I will have to fight with Javascript more. Yes, much more. But a book I found helpful was 'DHTML and CSS for the WWW'. It has helpful examples of various menus and widgets that can be accomplished on the web to make an interface richer. And with that, I think we've officially left the topicality of a mod_perl list. :-) Enjoy, Fran
RE: Is mod_perl the right solution for my GUI dev?
:I would like to continue in the same web front-end : path for more : interactive forms. May be I will have to fight with : Javascript more. : : Yes, much more. But a book I found helpful was 'DHTML : and CSS for the : WWW'. It has helpful examples of various menus and : widgets that can be : accomplished on the web to make an interface richer. While not germane to mod_perl, I did want to add my two cents to this. I did not follow the rest of the thread, so I am not sure in what context you want to deploy a web-site, but be careful with JS and other client-side technologies. IMO, they should be used when they are value-added, but do not become mission critical. In that, they might add some functionality that is useful but not vital for the user to complete the forms or navigate the site. Even in an intranet setting, unless you can positively ensure what browsers are used, you will encounter situations where things just do not work for a certain set of users. When using these technologies, do not be tempted to use browser-specific functions or plug-ins unless you are willing to accept that people will have to use your choice of browser. Follow open standards and rely of server-side solutions as in the end they will save you a lot of headaches and enable you to support the greatest variety of users with the least amount of effort. Good luck! Cheers, Ward
