I have gone through all the post related to LAMP... I feel, I should give more details regarding nature of automated system required... So that I can get some specific pointers...
System Requirement: 1. It will be mainly a small 3000 to 5000 record database with student details 2. As of now, main application of it is to generate exam grade reports... 3. And it should be able to give concise & well formatted reports, which could be printed on ordinary printers 4. The periodic backup of records, if it can be integrated in automation system, rather than relying on OS level backup.
According to me, there are three main parts of the system,
1) Data Entry of records 2) Algorithm to generate reports based on schools grading logic 3) Report Generation & Printing
My View * 1st & 3rd part functions should be extremely user friendly. * Business logic should be isolated into module of its own, and tightly secured. (I don't know how?) * Report generation will be multilingual (English, Gujarati), so better printing support.
Now,
1) If at all LAMP is feasible? If yes, how can LAMP setup be utilized? 2) Application should be Desktop based or web based?
Regards, Kamlesh Parmar
On 28/08/03 13:29 +0530, Kamlesh Parmar wrote: <snip>
System Requirement:
- It will be mainly a small 3000 to 5000 record database with student details
What details? Does your data need foreign keys? Do you need to validate entered data? Do you need stored procedures? Views?
- As of now, main application of it is to generate exam grade reports...
- And it should be able to give concise & well formatted reports, which
could be printed on ordinary printers
Sounds like a call for TeX, and possibly Perl. A single batch job can do this automatically. Pull the data out of the database, format it in TeX, convert to PDF, send to printer.
- The periodic backup of records, if it can be integrated in automation
system, rather than relying on OS level backup.
mysqldump, pg_dump
According to me, there are three main parts of the system,
- Data Entry of records
- Algorithm to generate reports based on schools grading logic
- Report Generation & Printing
My View
- 1st & 3rd part functions should be extremely user friendly.
Depends on the users :). Have a few simple forms for data entry. Single button job to generate and batch print all the reports in a single shot. Optional preview of a report?
- Business logic should be isolated into module of its own, and tightly
secured. (I don't know how?)
Yikes! Do as much data integrity stuff as you can in the backend. Business logic is in a server which sits between the database and the frontend user application.
- Report generation will be multilingual (English, Gujarati), so better
printing support.
I don't know if TeX has Gujarati fonts, but I guess it does.
Now,
- If at all LAMP is feasible? If yes, how can LAMP setup be utilized?
Personally, Linux, Perl, PostgreSQL, Tk and perhaps TCl/Python.
- Application should be Desktop based or web based?
Three tier, desktop clients.
Devdas Bhagat
On Sat, Aug 30, 2003 at 12:26:05AM +0530, Devdas Bhagat wrote:
- As of now, main application of it is to generate exam grade reports...
- And it should be able to give concise & well formatted reports, which
could be printed on ordinary printers
Sounds like a call for TeX, and possibly Perl. A single batch job can do this automatically. Pull the data out of the database, format it in TeX, convert to PDF, send to printer.
Would it be necessary to get into TeX? Perl is too powerful to not be able to generate PDF or postscript directly ... at least PHP is known to be able to do that! Dunno about handling Gujarati fonts, depends on whether and how far Indian localisation is affecting Perl.
Sameer.
On Mon, 1 Sep 2003, Sameer D. Sahasrabuddhe wrote:
Would it be necessary to get into TeX? Perl is too powerful to not be able to generate PDF or postscript directly ... at least PHP is known
The PDF modules available for perl are decent, but require some work. Colours and stuff aren't easily handled.
On Mon, 1 Sep 2003, Sameer D. Sahasrabuddhe wrote:
Would it be necessary to get into TeX? Perl is too powerful to not be able to generate PDF or postscript directly ... at least PHP is known
The PDF modules available for perl are decent, but require some work. Colours and stuff aren't easily handled.
I also feel more comfortable with that intermediate stage of TeX, because it allows me to debug Perl code which generates the report, by just looking at the generated TeX.
If I use a Perl module which generates direct PDF, I'd feel helpless if the PDF doesn't display right; PDF is all bits-and-bytes. If the module generates PostScript (and if I know PostScript), then I can always look at the generated Postscript _source_ if it doesn't display right in the viewer. Same's the case with TeX. Therefore, from the debugging point of view, I'd feel much more comfortable if something generates TeX/ HTML/ Postscript instead of PDF.
(An aside: how many times have we had to ask "cc" to generate assembly, and then look through the assembly code, to debug illogical behaviour in our code? I have, more than once. This thing about TeX versus PDF is from that can't-trust-the-compiler mindset.)
One more reason to prefer text-based formatted output file types is because I can write my code to use text-files containing templates. When I generate HTML screens from my Perl/CGI programs, for instance, I keep the entire HTML page layout in text files, with placeholders, like this:
<HTML> <HEAD> <TITLE>__FULLNAME__ is not getting any younger</TITLE> </HEAD> <BODY> <BLOCKQUOTE> <H1>Age of __FULLNAME__</H1> <HR> <P>The current age of __FULLNAME__ as per our records is __AGEYEARS__ years. Have a nice day!</P> <HR> </BLOCKQUOTE> </BODY> </HTML>
When I need to show the page, I read the template file, replace the tags (between the "__" strings) with actual values and then send the page to the user. We have an ancient, simple Perl function which takes a hashmap of attribute-value pairs and patches a template. This is possible with TeX and HTML, and if I use ultra-simple Postscript (e.g. the kind generated using XFig and transfig) is possible with Postscript too. But I don't know how to do this using any binary format like PDF. Taking this template-based approach allows me to make small changes to the screen appearance using just a _text_editor_ without editing code, thus making the code more robust. (I believe this template-patching under programmatic control can be done on Windows with MS Word documents, if I work with VBA. Can anyone confirm or deny this?)
In our company, share certificates are generated by printing Postscript files generated by a Perl program. :) This Perl program takes a table with one line per share certificate, and patches a Postscript template which was created using XFig. All certificates issued till date have been done this way. More recently, every Form 16 or Form 16A issued by our Accounts Dept is done through a Perl program which patches an XFig-generated Postscript template.
And talking about enterprise class applications being doable or not doable in Perl, I feel Perl's quite okay even for scaling up. J2EE gives facilities (particularly the application management facilities in the high-end commercial application servers) which I don't think any Perl execution environment provides. That apart, there are lots of cases of really large Perl applications which form the core bread-and-butter of an entire company's business. When it comes to performance for Web apps, I feel that an array of web application servers running Apache and mod_perl, all talking to a common (set of?) database server(s) at the back-end, can scale up as much as practically any other technology.
One place where J2EE wins is if you need long-running classes, e.g. daemons holding object instances with frequently-changing state, running for a long time (e.g. hours), servicing requests from other components. This sort of thing is done very naturally in J2EE but seems difficult in mod_perl. Any pointers to Perl-based long-running "object servers"? I'd like to know... If I had to do this in mod_perl with my current knowledge, I guess I'd just write the data for each object instance to a database table every time, incurring a performance hit.
I know of one company which is in the business of gathering, analysing and publishing data reports, which uses Unix/Linux, Perl, and TeX to automatically generate thousands of pages of formatted text every month. This setup has been working for years, and has taken the continuous modifications and extensions that are a part of life with critical business applications.
Without commenting on J2EE, I just wanted to say that I believe Perl delivers on large enterprise-class applications excellently. Even if I keep aside the seven-year track record of mission-critical work in Perl done by Starcom (where I work), just this company's case would be testimonial enough for me. Incidentally, this company evaluated Java carefully over a period of time for some GUI apps they have developed on MS Windows, and decided that MS VC++ and MFC was much better than Java. I don't know the details.
Shuvam
On Wed, 10 Sep 2003, Shuvam Misra wrote:
because I can write my code to use text-files containing templates. When I generate HTML screens from my Perl/CGI programs, for instance, I keep the entire HTML page layout in text files, with placeholders,
You should probably look at HTML::Template for your HTML Templates, and PDF::Template for your PDF Templates.
Philip
because I can write my code to use text-files containing templates. When I generate HTML screens from my Perl/CGI programs, for instance, I keep the entire HTML page layout in text files, with placeholders,
You should probably look at HTML::Template for your HTML Templates, and PDF::Template for your PDF Templates.
Cool. Will do about the PDF::Template bit. Regarding HTML templates, we didn't see any need to look at any modules, because what we needed was so simple that we built it ourselves with practically zero effort.
Thanks.
Shuvam
On Wed, 10 Sep 2003, Shuvam Misra wrote:
Cool. Will do about the PDF::Template bit. Regarding HTML templates, we didn't see any need to look at any modules, because what we needed was so simple that we built it ourselves with practically zero effort.
That's what everyone says. The advantage with using a standard module is portability. HTML::Template syntax is supported in Perl, Java, Python, PHP, Lisp, C++ and Ruby.
The syntax is extremely easy, while also being powerful. Once you start using mod_perl, you'll notice huge improvements in performance with HTML::Template's caching.
Philip
we didn't see any need to look at any modules, because what we needed was so simple that we built it ourselves with practically zero effort.
That's what everyone says. The advantage with using a standard module is portability. HTML::Template syntax is supported in Perl, Java, Python, PHP, Lisp, C++ and Ruby.
I guess we never looked at inter-language portability of function calls; we just treated this as a Perl function. When we shifted to Java, we just used a Perl utils class under Java, and wrote a Template class in Java using the Perl regex features.
For a group working across many languages, I can see that this similarity of syntax will be a blessing.
The syntax is extremely easy, while also being powerful. Once you start using mod_perl, you'll notice huge improvements in performance with HTML::Template's caching.
The trivial module we developed has so small an API (I think there's just a "load-template" and a "patch-template") that we didn't think we needed any further ease in the syntax. And the cacheing is totally a cool feature. We added cacheing too, in our code, when we did mod_perl and also when we did Java. That bit is also very simple to add, and didn't need any API change.
Shuvam
On Wed, Sep 10, 2003 at 12:47:56PM +0530, Philip S Tellis wrote:
On Wed, 10 Sep 2003, Shuvam Misra wrote:
because I can write my code to use text-files containing templates. When I generate HTML screens from my Perl/CGI programs, for instance, I keep the entire HTML page layout in text files, with placeholders,
You should probably look at HTML::Template for your HTML Templates, and PDF::Template for your PDF Templates.
I can't help but mention XML combined with XSL to produce HTML wherever necessary and follow the path along FO to PS/PDF wherever that is needed. Have often used that to create presentations and printed handouts using the DocBook "Slides" DTD for example.
Again, a rather ill-researched suggestion, but I think this is worth thinking about if you want to have information independent of multiple styles of representation.
Sameer.
You should probably look at HTML::Template for your HTML Templates, and PDF::Template for your PDF Templates.
I can't help but mention XML combined with XSL to produce HTML wherever necessary and follow the path along FO to PS/PDF wherever that is needed. Have often used that to create presentations and printed handouts using the DocBook "Slides" DTD for example.
I have hesitated to do this simply because I have always felt that anything to do with processing XML will need the XML parser and its DTD checking, grammar checking, etc, which will add a lot of CPU load. Our template patching for Web applications often needs to patch five to ten templates to arrive at just one screen, i.e. in response to one "submit" button click. Therefore, this is executed so frequently, for such small templates, that any CPU overhead here would kill the system throughput.
However, for generating large documents (e.g. hand-written reports, or MIS reports presented online but infrequently), I guess XML would be great. We maintain a Linux HOWTO; we use the DocBook structure for that.
Again, a rather ill-researched suggestion, but I think this is worth thinking about if you want to have information independent of multiple styles of representation.
I think most people will agree on XML for such situations.
Shuvam
On 01/09/03 11:04 +0530, Sameer D. Sahasrabuddhe wrote:
Would it be necessary to get into TeX? Perl is too powerful to not be able to generate PDF or postscript directly ... at least PHP is known
Perl can generate PostScript directly, as well as PDF (CPAN is useful for such searches http://search.cpan.org/).
to be able to do that! Dunno about handling Gujarati fonts, depends on whether and how far Indian localisation is affecting Perl.
TeX has support for those fonts, IIRC. dunno about Perl suport for those fonts.
Devdas Bhagat
-
Devdas Bhagat -
Kamlesh Parmar -
Philip S Tellis -
Sameer D. Sahasrabuddhe -
Shuvam Misra