28 Aug
2003
28 Aug
'03
7:59 a.m.
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
29 Aug
29 Aug
6:56 p.m.
On 28/08/03 13:29 +0530, Kamlesh Parmar wrote:
<snip>
System Requirement:
1. 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?
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
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.
4. 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,
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.
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,
1) If at all LAMP is feasible? If yes, how can LAMP setup be utilized?
Personally,
Linux, Perl, PostgreSQL, Tk and perhaps TCl/Python.
2) Application should be Desktop based or web based?
Three tier, desktop clients.
Devdas Bhagat
1 Sep
1 Sep
5:34 a.m.
On Sat, Aug 30, 2003 at 12:26:05AM +0530, Devdas Bhagat 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
to be able to do that! Dunno about handling Gujarati fonts, depends on
whether and how far Indian localisation is affecting Perl.
Sameer.
--
Research Scholar, KReSIT, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/
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
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. 
6:02 a.m.
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.
--
"Hello," he lied.
-- Don Carpenter, quoting a Hollywood agent
10 Sep
10 Sep
6:59 a.m.
On Mon, 1 Sep 2003, Sameer D. Sahasrabuddhe wrote:
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
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.
7:17 a.m.
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
--
Blutarsky's Axiom:
Nothing is impossible for the man who will not listen to reason.
-----BEGIN GEEK CODE BLOCK-----
GCS/ED/MU/TW d- s+: a- C+++ UL+++ P++++ L+++>$ E--- W+++ N- o-- K- w---
PS+ PE Y+ PGP+ t* X- R* tv b+ DI+++ D+ G++ e+++>$ h* r y
------END GEEK CODE BLOCK------
9:20 a.m.
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.
9:33 a.m.
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
--
Isn't it strange that the same people that laugh at gypsy fortune
tellers take economists seriously?
-----BEGIN GEEK CODE BLOCK-----
GCS/ED/MU/TW d- s+: a- C+++ UL+++ P++++ L+++>$ E--- W+++ N- o-- K- w---
PS+ PE Y+ PGP+ t* X- R* tv b+ DI+++ D+ G++ e+++>$ h* r y
------END GEEK CODE BLOCK------
2:32 p.m.
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.
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
10:01 a.m.
On Wed, Sep 10, 2003 at 12:47:56PM +0530, Philip S Tellis wrote:
On Wed, 10 Sep 2003, Shuvam Misra wrote:
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.
--
Research Scholar, KReSIT, IIT Bombay
http://www.it.iitb.ac.in/~sameerds/
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.
2:36 p.m.
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.
I think most people will agree on XML for such situations.
Shuvam
1 Sep
1 Sep
12:14 p.m.
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
7329
days inactive
7342
days old
11 comments
5 participants
participants (5)
-
Devdas Bhagat -
Kamlesh Parmar -
Philip S Tellis -
Sameer D. Sahasrabuddhe -
Shuvam Misra