Thread: [Pas-dev] Re: your mail

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> Hi 
> 
> I'm the project owner of Freemoney (Demo: http://www.web-counting.com), an 
> effort to make an Open Source Financial Application. Freemoney is based on 
> Perl. 
> 
> I've tried several models. Amongst them is Embperl, but for now I've settled 
> for Interchange (http://developer.akopia.com) as a development platform for 
> my project. Do you know Interchange? 

I've had some less than positive experiences with Embperl and most of
the other standard HTML templating languages that are available for Perl
for that matter.  Embperl works as a templating language, it just leaves
alot to be desired in my opinion.

I did not know about Interchange until your email.  I will take a more
detailed look at it at some point.

> In my search for a Perl Application Server, I found pas through freshmeat. 
> 
> One thing I really like about Interchange is that it's really an application 
> server, using a separate process. Do you have any plans to make pas do the 
> same. I can see that you compare it with jsp. To my knowledge, jsp requires 
> jboss or another (separate) server. 

We do not currently have plans to make Pas a stand-alone server.  Because
it is built into Apache via mod_perl, we can still use a 3 teir design
to keep the data, logic and presentation layers architectularly seperated,
while having them in the same process which gives it good performance.

There is no reason why you could not set up a seperate instance of Apache
running Pas and then either have your front end web server forward requests
to the secondary server, or use a remote api (such as xml-rpc, or soap) to
access the secondary server.

We made use of Apache precisely because it is a stable, high performance
server architecture.  One way to think about Apache/mod_perl with Pas is
that it is an application server at it's core.  It accepts requests and
produces responses.  The normal mode of operation for it is to use HTTP
as the transport and HTML as the presentation.

As far as I know, JSP only requries a servlet engine, such as Tomcat
from the Jakarta project:

  http://jakarta.apache.org/

JBoss is only necessary (appropriate) if you are giong to use Enterprise 
Java Beans [EJB].

> Pas seems rather new in the current implementation - how many real world 
> projects do you think is using it? Do you know of any building blocks made 
> for pas - like menus, calendar, content management, searching, report writer 
> or the like? 

Pas in it's current implementation is about a year old.  I am not currently
aware of any public websites that make use of it.  Pas grew out of my 
experiences building Vwr Scientific Product's ewcommerce site:

 http://www.vwrsp.com/

That site produces over 150000 dynamic page generations a day.  That is
the count of pages produced by the software, the actual number of requests
to the site is higher than that number.  When I left that project, the site
was generating about 8 million US in sales per month.

Pas has a cleaner more efficient internal design than what we did for
that site.

I have been using Pas for projects at my current employer, so I know that
there are two real world projects using it.  Unfortuantly they are internal
applications, so they are not avaialble to the outside world.

As far as I know, there are no building blocks of the kind you mention 
currently available for Pas, though I'm sure the developers are willing
to help with those kinds of things.

> is the database interface well suited for a classic application like a 
> financial system? Most of it consists of overview and detail pages. 
> Interchange i OK for that, but it's not perfect, and it really can't 
> separate the business logic from the page layout. 

The database interface is the standard Perl pacakge DBI.  It is a general
database interface layer.  

For projects where I've used Pas, we general break the database layer
out away from everything else by generating a Perl object to represent
a record from a single table from the database.  These objects know how 
to insert, update, select and delete records from the respective tables.

We then implement the bulk of the business logic in Page objects.  We
then use the PSP pages for the displaying of the data processed/gathered
by the Page objects.

An inbound request is targeted at a page object, the page object interacts
with the data layer to perform the requested functionality, summarizes
the results and forwards the request on to the PSP page for display back
to the web browser.

I hope this has been helpful.  I would be happy to continue the 
discussion.  I have CC'd my response to the pas-devel mailing list, and
with your permission would like to continue to CC our discussion to
that list.

Best Regards,
Kyle R. Burton

-- 

------------------------------------------------------------------------------
Wisdom and Compassion are inseparable.
        -- Christmas Humphreys
mo...@vo...                            http://www.voicenet.com/~mortis
------------------------------------------------------------------------------