Re: [Pas-dev] Re: Install

[Justin B. <ju...@le...>]

Kaare Rasmussen wrote:
>> so I'm not sure why that isn't working.  If you could
>> somehow get $PAS_BASE/lib onto the PERL5LIB, then we might get a 
>> little further.
> 
> 
> I just tried 2.0 for fun, but I will look deeper into this when I have 
> time. Look for a mail with at new topic...

I was hoping 2.0 was available through apt-get but they're only up to 1.3.24 or 
something.

>> Great!  One of our developers is already working on session support 
>> for PostgreSQL, so we should have that soon.
> 
> What is the advantage of database based sesssion support as opposed to 
> file based, if any?

Distributed session.

>> If you're only showing 50 of the records at once, then you'll only 
>> have 50
>> record objects in memory at once, that's not very much, and unless you're
> 
> 
> I think that I'm not making myself clear. I will try to show an example.
> Typically, I have a table or (more likely) a view. I want to show a list 
> of all rows in this view, 50 rows at a time. If the view holds 10,000 
> rows, and I show 50 rows at a time, will there be 10,000 rows in my 
> object or 50?

It all depends on how you select it from the database.  I know with MySQL you 
can specify LIMIT in you SELECT stmts and pass it where to begin and the size 
block you want.  So if you wanted to view the first 50 records of that view 
you'd do:

   SELECT *
     FROM some_table
    LIMIT 0,50

I would then proceed to either save in the session or in a query parameter 
something to indicate where I'm at in that list of 10000 records.  So I can 
easily look at the next 50 records.  Or you can load all 10000 rows into an 
array in an object, stuff it in the session, keep track of your index and step 
through the records as you would like.

> can I update a view through a Perl module?

As long as the DB allows it, I don't see why not.

> Example: A customer is really a person or a company row joined with an 
> address table, joined again with a postal codes table, joined again with 
> a country table.
> If you call the set method call for this object, should there be 
> something prohibiting me from updating each table with their relevant data?
> Another point is, how do I make joins, aggregate functions and so on? Or 
> is that a no-no? Do I have to predefine each and every table combination 
> that I will ever use?

PAS provides an architecture to develop on.  You can pretty much do whatever you 
want on top of PAS.  It doesn't limit what you can do and hopefully it makes 
things easier and quicker to develop.  For complex queries you have to write 
them yourself.

We do have a database record generated.  What that does is generate an object 
that mirrors a database table.  I believe we've updated PAS so that the record 
generator will also provide simple insert, delete & update functions for that 
table.  If you want additional queries or need to optimize a query, our 
methodology for doing this is to subclass the database record object.

For you're example, you'd probably want to subclass the customer record object 
so that it contains an address record and has a method that would call the 
update() methods on both the customer record object & the address record object.

>>> For Freemoney (the Financial App), I need at least Menus (see demo) 
>>> and Login and Access handling.
>>
>> I'd think Pas could handle that :)
> 
> 
> Ah, but this is one of the points where I'm not satisfied with the 
> current solutions that I can find. Login and Access handling shoule 
> really be named Security. And security is not something that can be 
> bolted on at the end, if you want a good solution, and Apache's 
> .htpasswd is not fine grained enough.
> And a menu system should be integrated with the security.
> Scenario:
> A user logs in to the system. It's not a Linux-user, just a user stored 
> somewhere in this system.
> The user is presented with a menu. It is a multi-layer menu. Either like 
> Freemoney today, where choosing a main menu will display sub menus, or a 
> tree structure.
> The user is only presented with the menu options that are allowed for 
> this user.
> Maybe in another scenario, it will be a series of links. Again, of 
> course, only the links that this user is allowed to see.
> All this has to be mandatory for a site. Maybe meaning that it has to be 
> a setting in startup.pl or in httpd.conf.

You can do this with a properties table or addition columns in the user profile 
table that complements the standard user information.  When a user logs in, 
along with their standard information you load in their property information and 
stick it in the session.  Then at the beginning of each PSP page, you can check 
to see if the user has that specific property.  If they do, they can view the 
page.  If they don't, they get a page that says they have entered a restricted 
area.  You make these properties read-only for the users and only configurable 
by an administrator.  You can do this for a whole page or specfic links.

Or a more basic example, only certain users can view a page once they are logged 
in.  In the past, we've had our standard page object for displaying a page and 
then we'd have a LoggedInPage object (which was dervived from the standard page 
object)  for first checking if the user is logged in (by checking the session) 
and then displaying the page if they are.  This is a more cleaner way to check a 
user's properties instead of having the business logic (if stmts) inside the PSP 
pages.

Hope that answers your questions.

Justin