Re: templating system opinions (axkit?)

[Jeff AA]

> - Original Message - 
> From: "Jean-Michel Hiver" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, July 24, 2003 1:46 PM


> First of all, it is an implementation of TAL. TAL is a very clever open
> specification for WYSIWYG-friendly templates written by the Zope people.

Do you have a URL for further reading on TAL?


> Petal has an active community and a mailing list, 

Ditto - a URL would be interesting!


Regards
Jeff

Re: Server side programming PHP Vs CGI Vs modPerl

[Jeff AA]

> DM> Hello All,
> DM> We have a server running in a Linux machine, now we would like
to
> DM> present the data in a browser using HTML interface. Can anyone suggest
me
> DM> which is the best one (CGI or PHP or modperl) to develop for web
> DM> programming and also their advantages and differences to choose them
as
> DM> the best

Depends on your requirements, which are not very clearly stated.

Here's my head-up:

  CGI - simple, slow, I wouldn't recommend under any circumstances

  PHP4 - simple, fast, easy to learn, not as fully featured language as
Perl.
 easy to install, cookies, sessions etc all easy out-of-the box.
 only for dynamic web pages - dont use it for data processing.
 easy to share one Apache server, multiple developers

  MOD_PERL - complex, fast, difficult to master for non-Perl programmers.
 lots of folks have problems installing /building - try yourself.
 Perl is a more fully-featured language, more general purpose
 can share web / data-processing classes and code

We use PHP for complex interactive websites. We use Perl for
data-processing. We plan on building our next generation ASP websites using
mod_perl so that we can share code/classes between data-processing and the
interactive sites. We have build a suite of system admin tools using
mod_perl - this was much harder than the PHP development, but we are pleased
with the results.

You should join the PHP lists and compare the questions with those asked
here - gives you an idea about some of the differences in the communities.
Also consider the number of PHP4 v MOD_PERL development resources available.

> From: "Lee Goddard"
>
> mod_perl, obviously: you posted to a mod_perl users' list.
> You might wish to have a look at the case-studies pages of
> http://perl.apache.org, as well as http://www.perl.org.
> As for PHP, it's not perl, so forget it :)

Sometimes you just need a toothpick, rather than a swiss-army chainsaw! 8-)

my $0.02

Regards
Jeff

RE: When perl is not quite fast enough

[Jeff AA]

> -Original Message-
> From: Stas Bekman [mailto:[EMAIL PROTECTED]] 
> Sent: 16 December 2002 13:22
> To: [EMAIL PROTECTED]
> Subject: When perl is not quite fast enough
> 
> 
> While reading Mark Fowler excelent Perl Advent Calendar 
> (http://www.perladvent.org/2002/) 6th entry: 
> http://www.perladvent.org/2002/6th/, in the references 
> section I've noticed a 
> link to Nicolas Clark's notes from his YAPC::EU::2002 
> presentation, on how to 
> make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/

Dear ModPerl Lister,

I have two questions:

1) In this list, I have seen folks asking general Perlish questions 
   told to take their discussions elsewhere, along with the useless 
   recommendation that they browse lists.perl.org - I have done this 
   several times and joined a few of the lists, but only ever found 
   lists that were rather beginner. I have also lurked in some of the 
   groups.yahoo.com pearly lists without finding the right level.

   - can folks name any specific useful intermediate/advanced
 Perl lists? i.e. Perl 4+ years in a commercial env
  

2) I have one common approach to speed improvement that is not
   mentioned at all, to do with symbol table manipulation for
   functions, that I would like to polish via a list discussion

   - is this list appropriate for a thread discussing Perlish
   performance in general? I would guess that symbol table fiddles
   might be risky in a mod_perlish env.

TIA
Jeff

RE: Yahoo is moving to PHP ??

[Jeff AA]

> -Original Message-
> From: Mithun Bhattacharya [mailto:inzoik@;yahoo.com] 
> Sent: 30 October 2002 09:17
> To: [EMAIL PROTECTED]
> Subject: Re: Yahoo is moving to PHP ??
> 
> 
> No it is not being removed but this could have been a very big thing
> for mod_perl. Can someone find out more details as to why PHP was
> preferred over mod_perl it cant be just on a whim. I might be biased
> but considering the fact that PHP and mod_perl were neck to neck the
> cons should have made up for any slipup in performance.

err did you look at the same slides as me? 

in all performance tests, YSP(perl) performed better than PHP, with 
the exception of memory usage.

and there is a slide explaining why not Perl - the main objection 
seemed to be:

"There's More Than One Way To Do It
   so many different Perl styles
   everyone's code looks different
   problematic for development when many people working on 
   single codebase"


While there were Pros/Cons for Perl and the other rejectees, there were 
no Pros/Cons for PHP unless you count the gotchas mentioned after four
months of using PHP:


Shallow learning curve
 - very easy to get some pages up quickly
But mixed app/presentation problematic
 - PHP code and HTML forever intertwined
 - coding conventions help
*.inc for function and class libraries
*.php for web pages (call functions, echo $vars)
 - use Smarty to enforce separation?

"The drawback of using a code in template system, is that your code and
HTML output quickly become forever intertwined. This makes changing the
appearance of your pages difficult. For example, if you check the user
cookie and load user database data in the "common-header" moving around
where you include this template will change where you retrieve the
database information for the user, possibly breaking other parts of the
page which rely on that data. "
  http://www.clearsilver.net/docs/apples_to_oranges.hdf  
 

The "implement twice" problem
 - much offline processing done in Perl
 - example: tax/shipping calculation for Shopping
PEAR != CPAN
 - installer doesn't work in PHP 4.2.x
 - repository smaller, less mature than CPAN
Surprises for people used to coding Perl



Interestingly our experience was/is similar - we chose PHP 2.5 years ago
for the development of our dynamic ASP interactive pages, and Perl for
all our data-processing and server management etc. Hindsight shows us
that it was the right decision at the time - we gained an 18 month lead
on the competition.

After 2.5 years, the 'have to write everything twice' problem has lead
us to plan a gradual migration from PHP to Perl. All our new pages and
products are being developed in mod_perl. I wonder if they will consider
a similar change? Unlikely give the number of developers and the
disruption?

There is one con for PHP that I disagree with - you don't have to mix
your HTML and application logic - just as in Perl, you can separate them
if you want to - we work extensively in PHP ordered hashes and isolate
the formatting and HTML generation in a few included utility
collections, making it easy to change the HTML we generate without
changing any of the underlying business information.

Regards
Jeff

RE: [OT] Perl vs. PHP..... but where is mod_perl?

[Jeff AA]

 - I get 

  The requested story: 19716 has not been published (set live) yet.

when I visit http://www.newsfactor.com/perl/story/19716.html

Do you think the lists comments upset someone? 8-)

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 13:23
> To: Jeff AA
> Cc: [EMAIL PROTECTED]
> Subject: RE: separating C from V in MVC
> 
> 
> >Controller:
> >---
> >my $Stale  = Model::WatchCollection->new( status => 'stale' );
> >
> >Controller:
> >---
> >my $WC= Model::WatchCollection->new();
> 
> Out of these two, I would think that the first one is actually 
> better.  What if you have 300,000 watches and only 25 are stale, for 
> example (numbers that are not all that far from the truth, in my 


Don't make the mistake of fetching all the data when a Collection is
instantiated. It is usually better to make the Collection only really
fetch data when a View actually asks for it by calling $WC->fetch(
status => 'stale' ), after all, sometimes you might go down another
route and the View might never call fetch() - for example if there is an
exception and you decide not to bother showing stale Watches. 

Also, you should generally not fetch everything from the database unless
there is a very good reason to do so. Try to keep your memory usage to a
minimum, and restrict the result set to something useful. I recall a
system that used to pop up a dialog saying 'Warning: This will return
645,345 rows' and the only user option was 'Ok'!

I have seen about 4.2 million Collection designs, and my current
favourite is an abstraction of the Borland Data Engine DB/Table/Dataset
design (BDE) in conjunction with some of the Java collection concepts.
Common Collection niceties include things like 'find me Watch ABC' in
the Collection. A Collection can have the concept of a 'current' thing
so that a View can display both the list of Watches in a table, and more
detailed attributes of the 'currently selected' Watch object etc.

If you are going to support paginated collections, you should build this
into your base Collection class.

So far we have been talking about flat Collections, don't forget that
some of them are not flat, but hierarchical - e.g. tree-like, and some
are circular e.g. no beginning and no end, etc.

ciao
Jeff

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Fran Fabrizio [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 06:48
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: separating C from V in MVC
> 
> 
> 
> Ok, great stuff, now we're getting somewhere.  So, the model = the 
> nouns.  Good.  That helps.  Now, how do you represent in the model a 
> complex query that joins across 5 of the nouns?  

In my other post about Controller, I assert [but feel free to disagree!]
that Models are really Nouns+Business Verbs


> network monitoring and display tool.  It receives status 
...
> them."  We call this a stale watch.  We have a report that 
> shows all of the 
> currently stale watches across our network.  The query is a 
> join of around 
> 4 tables (or nouns) - Site, Watch, Watch Config, Message - 
> something along 
> those lines.
> 
> Does one create a model object called StaleWatchReport?  That 

Not generally. Having grasped the core business Model classes, you now
need to also realise that the real world often deals with Collections of
objects. So instead of a StaleWatchReport class, what you need is a
collection of Watches that are stale.

You should ask this collection to present qualifying Watch items.

Collection can be powerful, so give some careful thought to this, and
don't bind your Collection base class too closely to the database (there
was another post by someone on keeping $dbh chroot jailed!)

Here is an example, though there are many other possible collection
approaches.

Controller:
---
my $Stale  = Model::WatchCollection->new( status => 'stale' );
my $View   = View::StaleWatches( stale => $Stale );

$self->headers();
print $View->render();


View::StaleWatches
--
foreach my $watch ( @{$Stale->fetch()} ) {
  describe_in_HTML( $watch );
}

Note that the web controller knows nothing about stale watches, it just
knows that given the current request, it will pass the token 'stale'
into the WatchCollection. You can use the same Model::WatchCollection
class in a batch overnight report, and it too will understand how to
identify stale Watches.

Here is an alternative, possibly better approach:

Controller:
---
my $WC= Model::WatchCollection->new();
my $View  = View::StaleWatches( watches => $WC );

$self->headers();
print $View->render();


View::StaleWatches
--
foreach my $watch ( @{$WC->fetch( status => 'stale' )} ) {
  describe_in_HTML( $watch );
}


In this second example, we have even moved the need for the Controller
to know about 'stale' into the View, which already knew that it only
wanted stale Watches.

> In your concert example, if I wanted to define a report that 
> showed me all 
> of the seats that were purchased by people from New Jersey with a 
> Mastercard in the last week, how would I represent that?
> 

The web request might look like this:
  /seats?qstate=NJ&qcard=MC&qpurchased=-7

Controller:
  my $query = {};
  foreach ( parameter starting with q ) {
$token = param name without the 'q';
$query->{token} = URLDecode(parameter value);
  }
  my $SC = Model::SeatCollection->new( query => $query );
  my $View = View::SeatGeneric->new( seats => $SC );
  $self->headers();
  print $View->render();

Note that the Controller handles decoding the parameters etc, but
doesn't care what queries that the SeatCollection understands. It does
understand a mini protocol where query params start with 'q', but this
is not business logic, it is UI logic.

Next you'll want to know about handling Form validation and Models with
multiple field level exceptions? 8-)

Jeff

RE: separating C from V in MVC

[Jeff AA]

> -Original Message-
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 13 June 2002 03:43
> To: Fran Fabrizio; [EMAIL PROTECTED]
> Subject: Re: separating C from V in MVC


> > 2.  Does the first part of my code above even remotely resemble a
> > Controller?
> 
> Sort of.  It does choose a view and it does parse some user 
> input, but a
> controller is more than just a dispatcher.  It would include 
> some of the
> code that you're currently putting into your doDoctorActivity() sub.
> The idea is that the model objects represent just the data in your
> application (the nouns) and the controller understands how to 
> translate
> user input into a series of method calls on the model objects to carry
> out the user's request.
> 
> It's hard to give a good example that is short, but let's say you were
> building an application to sell concert tickets.  The act of 
> buying the
> ticket might involve model objects representing a concert, a user, a
> form of payment, etc.  The concert object knows how to reserve a
> specific seat (or call a seat object to do that).  The payment object
> knows how to verify and charge a credit card.  The user object has a
> mailing address.  The controller knows how to turn the user's 
> form data
> into a bunch of method calls on these objects that accomplish 
> reserving
> the ticket and charging the user.  If you find yourself writing a
> "BuyTicket" module, that's a controller not a model object.
> 

I disagree with this definition of a Controller. A Controller is
primarily responsible for mapping user input onto a business Model, and
should not know that buying a ticket requires creation of concert,
payment, seat, client, theatre, agent, reservation, whatever objects.

In the same way that the View keeps the output format independent of the
Model properties, the Controller keeps the User Input method independent
of business logic. This is the reason for having a Controller class.

Consider that your mod_perl website Controllers will have to understand
all about web requests, headers, error headers, cookies, sessions,
redirects, URLs and URL decoding etc etc - these are things that relate
directly to how the user is interacting with the Model.

In the concert example, the Controller would interpret the web request,
create a Ticket object, and call $Ticket->buy(
%all_the_cleaned_up_params ). It would then pass this to the View to
render. That's it.

Consider the case where you wanted to buy hundreds or even thousands of
tickets in a batch process - maybe you have agents that collect all the
details for Kylie concerts, and then send them to you in a file.

If you had made the mistake of creating a web Controller aka BuyTicket()
module that understood it had to create concert, payment, seat, client,
theatre, agent, reservation, whatever objects, you would have to
duplicate all this logic AGAIN in the batch process Controller. You now
have to maintain the business logic in two places.

Always keep the _business_ behaviour in Models. The $Ticket->buy()
processing must instantiate and create relationships to all the other
objects it needs.

Put all things that are specific to handling the User Interaction (eg
web request) into your Controller. Business logic always goes into a
Model.


> The idea is that the model objects represent just the data in your
> application (the nouns) and the controller understands how to 
> translate
> user input into a series of method calls on the model objects to carry
> out the user's request.

Models are not just collections of stateful data, they are the right
place to encapsulate complex business behaviour. At the risk of
repetition, all behaviour [e.g. $Ticket->buy()] that is not specific to
the User Interface should go into Models. 

Controller and View are closely related elements of GUI. This is like
the old 'Two Tier App' problem... when business logic and GUI become
inexorably entwined, maintenance goes out the window.

Have a look at this picture:
http://www.ddj.com/documents/s=867/ddj0105i/0105if2.htm which comes from
this article: http://www.ddj.com/documents/s=867/ddj0105i/0105i.htm


Maybe in the future, we will get drag-and-drop via the web -
interpreting this should go into the Controller. 

Maybe in the future you will change the business requirements for buying
Tickets - this will go in a Model, and the effect will be felt
consistently in both your web applications and your batch processing.

Regards
Jeff

RE: mod_perl/passing session information (MVC related, maybe...)

[Jeff AA]

> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 18:15

> Right, which is why you shouldn't try to store server-side state 
> for anything that could be different in multiple browser windows. 
> Only store global browser information on the server-side.  Everything 
> else has to go into the links and forms.

m I see what you're saying, for example a user wants to look at page
1 and page 3 of the same query in two windows side by side. It doesn't
make sense to store page specific info (egg the current record offset)
on the server. The Next link on each page should deliver the Next set
for this window.

The same problem would occur with query tweaks egg,
/query?query_id=12345&order=colour. The order tweak is relative to the
current query state, and might confuse if the same query is displayed in
multiple windows.

Ditto for use of the Back button in the browser

Ok - full-circle back to encoding page state in links and hidden fields
on the page itself, but it was an interesting loop!

Regards
Jeff

RE: mod_perl/passing session information (MVC related, maybe...)

[Jeff AA]

> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 16:29

>> Agreed, but he wasn't talking about storing the results, just the
query
>> parameters and current offset / number of rows, which is a-ok for
>> putting into a session.

> No, that's exactly what ISN'T okay for putting into a session.  If a 
> user opens two browser windows, does a search in each, and then pages 
> forward in each set of results, he will get completely wrong pages if 
> you do this.  The query parameters from the first search will be
written 
> over and lost.

Please - s/session/Apache::Session/g above


> You could do that, with a unique ID for each set of parameters, but
you 
> might as well just put the parameters right in the link unless they're

> very long.

The [Apache::]session approach makes it easy to store and change lots of
params to the query. It also lets you keep track of [recommendedly]
minimal info about the Query on the server, without having to re-execute
it, and it lets you pick up a previous query, with minor tweaks things
like /query?query_id=12345&order=value+desc where the tweak doesn't get
lost in the params.


>> Don't mix transient query sessions with a User Session that stores
info
>> about the user's logged in state etc. It would be normal for one user
to
>> have multiple queries in a login session
> 
> Hold on, I think we actually agree, but you're using the word session 
> for a bunch of different things.  What you're saying here sounds like 
> the opposite of what you said above.  In common usage, a session is
the 
> state of the user's interaction with the application.  A cache of
query 
> data would be something else.

Again, please s/session/Apache::Session/g 

> MySQL is fast, but usually not as fast as simple disk access. 
> Cache::Cache and Cache::Mmap handle the details of the cache stuff for

> you, making it pretty easy.



I do agree that disk access _can_ be faster, but disagree with the
implication that caching DB results outside the db is a cool trick. I
would assert that in all general circumstances caching DB results is a
Common Mistake. Special circumstances do exist, but in my experience
very rarely, and that's why we have MI6. I can imagine a circumstance
where a cache may prove useful - a large number of concurrent users, all
wanting exactly the same data, slow db connection, non-optimisable
query. This doesn't seem to be the case here where the question was
about a faster Apache::Session.

Interestingly MySQL and other DBs are often as fast as simple disk
access - contrary to popular wisdom, most DB engines actually cache in
memory, with more data access information and hence effective cache
memory usage than is available to external cache components. Yes,
Network transference can be an issue - but hey! be a masochist, buy a
switch!

I recall an impressive chap at a bank, who was asked to address
performance issues. He immediately identified DB queries as taking far
too long, and proceeded to hand craft a mega-smart shareable multi-user
in-memory cache server in C. He ran into dozens of issues, which were
ingeniously solved using the tersest possible sin tax. After about six
months of effort, the performance problem still existed,  - the DB
resided entirely in memory anyway! A tweak of the schema [i.e. about 2
hours including test and release] by a DB admin took the problematic
process from 2 hours down to 120 seconds. We spent cash for cache, and
lived to rue the day.

I parse 'use a cache for db stuff' as 'my XYZ cache component is way
smarter than all the guys at 'Oracle|Sybase|MySQL' combined', or 'I know
my data better than the database, cos I'm a kewl Koder'. Actually, I
really parse 'use a cache for db stuff' as 'I don't really understand
databases, 3NF and indexing, and can't be bothered learning to use them
well'.



But ok then, use a cache for your mod_perl query parameters, but don't
call it an [Apache::]Session.

8-)

RE: mod_perl/passing session information (MVC related, maybe...)

[Jeff AA]

> From: Eric Frazier [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 16:52

> I don't know this term "query hijack" can you put it in different
words?

Lets say your user who is the boss makes a query
  'show me everyone's salary'

and your system checks who he is, and because he is the boss, allocates
query_id 1, issues the query and sends back page one with everyone's
salary details.


now some other user in the system can now say
  /query?query_id=1

and hijack the query results - i.e. they will see the results of the
query, even though they should not be allowed to.


If your security model is user centric, at a minimum you should put the
user_id inside the query_id session, and only let the same user get the
results from the saved query parameters. A better approach is to have
the query ALWAYS authenticate the current user, then you won't ever give
out data to the wrong person, and users can share query links that will
work if they have the appropriate rights.


from www.dictionary.com/search&q=hijack

hijack

n : seizure of a vehicle in transit either to rob it or divert it to an
alternate destination [syn: highjack] v : take arbitrarily or by force;
"The Cubans commandeered the plane and flew it to Miami" [syn:
commandeer, highjack, pirate, expropriate]



Regards
Jeff

RE: mod_perl/passing session information (MVC related, maybe...)

[Jeff AA]

> From: Ken Y. Clark [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 15:39

> I've munged the query results in Perl and a couple template 
> packages to make each link contain everything necessary to 
> perform the query again (including every parameter from the 
> original request) and putting in the appropriate "limit_start"
> number...

Using sessions and a query_id is a shortcut for this, instead of stating
all the complex parameters again, you just issue an id and put that into
the link. 

An advantage of the session/id is that you end up with stateful query
instances, and can remember [at least for a short period!] the total
number of items, so that you can say 'Results 1 to 10 of 34,566' without
having to count all results every time. This is also useful if you want
users to be able to jump to a LAST page, as you can for example calc the
starting point for limit statement easily.

One disadvantage is that you cannot link to the query result pages, as
you will no doubt expire the query sessions eventually. By putting all
the params in the link, Ken's way lets the users link to the results,
remember them in their favourites etc.

Another possible feature is to allow the link to override any of the
current query parameters, so to do a DB resort, you can say something
like Sort by Colour and
the order param is not lost in amongst lots of other params. Obviously
changes to the where clause, ordering etc may invalidate current row /
page remembered values.

Further variations are readily available. You can create persistent
queries, rather than session queries, store the params in the DB and let
your users have their very own private or shareable searches. If you use
the optional param overide approach, you can store the params once, and
then the options as a separate query that refers to the underlying
query. When users add columns or other bits to the underlying, all child
searches will respect the change.

Regards
Jeff

RE: mod_perl/passing session information (MVC related, maybe...)

[Jeff AA]

> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 15:11

> You can store anything in Apache::Session; it's just a persistent hash

> table.  However, storing query results based on a user's session is
not 
> a good idea!  What if your users open up two browser windows and tries

> to do a search in each one?  Server-side session data is global to all

> browser windows, so they'll get bizarre and incorrect results.

Agreed, but he wasn't talking about storing the results, just the query
parameters and current offset / number of rows, which is a-ok for
putting into a session.

some query session do's and don'ts...

Don't forget that you can have multiple sessions - store the query
params in a session identified by a query_id so that subsequent requests
just say something like: Next

Don't mix transient query sessions with a User Session that stores info
about the user's logged in state etc. It would be normal for one user to
have multiple queries in a login session

Don't bother passing the query ids in cookies, they are not browser
session specific. Just use the query_id as a parameter in the
first/next/prev/last links as exampled above. You can then have a web
control page that handles multiple queries simultaneously

Do put the user_id into the query session and check it against the
user_id in the User session to prevent query hijack


> My suggestions would be to have a separate cache just for query
results. 

Or even to use a database that has a decent approach to caching. MySQL
promises automatic cacheable paged queries in the near future. And if
you write your own DB cache, you then need to manage the DB / cache
synch issues, cache size, cache expiry etc etc issues. Good cache is
very hard to do! better to get it from a real data bank.


> From: Vuillemot, Ward W [mailto:[EMAIL PROTECTED]] 
> Sent: 12 June 2002 14:58

> I want to be able to remember the last query so that I can return
> results into multple pages along with memory of where in the stack I
am at.
> The easiest would to be store the query parameters along with the
count
> information. . .but I do not want to use Apache::Session as I believe 
> that has too much overhead for this sort of thing.

Apache::Session is just what you want here! It is an easy peasy way to
remember things on the server, and you can implement it with whatever
type of storage underneath that you want [e.g. database] so that you can
even share sessions when your query is being served by multiple web
servers. If you look through the source, you will see that the overhead
is minimal. You can specialise the session persistence mechanism if you
want to for example store the key => value pairs as visible records in
the DB rather than a serialised blob.


Regards

Jeff

The T in MVC?

[Jeff AA]

I have some questions for users of Templating... we currently, (in
another language) have a set of standard functions for things like
printing data tables, so in our HTML page outlines, we just insert a
call to 

printDataTable( table => $table, user => $user, data => $data, layout =>
layout );

parameters:
 * $table  => optional ref to hash containing
 table title, any unusual table properties etc.
 * $user   => ref to hash of user preferences
 * $data   => ref to array of hash 
 * $layout => ref to array of field names

This standard routine combines these details and produces an HTML table
containing the data. 

The use of standard routines ensures consistency throughout the entire
site. Our printDataTable() function references site specific
configuration data so that all the tables within a website are
consistent, but that different sites can have their own skins applied.

How is something like this best accomplished with the templating tools
like TT?
I guess I am asking how the template world achieves intra/extra site
reuse and ensures consistency?

Tia
Jeff

RE: separating C from V in MVC

[Jeff AA]

> From: Rob Nagler [mailto:[EMAIL PROTECTED]] 
> Sent: 10 June 2002 20:41

> ... a Facade is the front face of the web site which includes colors,
> text, URLs, etc.  All the other MVC components talk to the currently
> selected Facade when they need these values.

> The controller calls Bivio::UI::Task->parse_uri, which strips the
> "*" from the URL (if there) and sets the facade before parsing
> the rest of the URL.  The default Facade is www.bivio.biz, which is
> why we don't need a rewrite.

> The links are generated by the Facade component Bivio::UI::Task.

Sounds interesting, can you briefly describe the MVCF parts, and what
their responsibilities are? Have you split the View into View + Facade?
What are the differences between your MVCF and the MVP pattern?

> This allows the Facade to pick its own URLs.  
...
> URLs are part of your user interface, not your controller.

I think I like this, though the w3 might not 8-)


> We rarely change the controller except to add new function.  
> Query and form values are parsed by the Models after they are 
> translated to key/value format by the controller.  

I definitely like this - small number of relatively generic Controllers
seems to me to be a desirable goal of an MVC arch.

> abstracted the concept of paging and drill down in our ListModel and 
> Table classes.  

I find that the mix of business object e.g. Bank Account and
presentation objects, e.g. Table can lead to confusion - are your Table
objects just a way of organising data, or do they contain presentation
style hints -e.g. dynamic width indication etc? 

Do you have something similar to a Bank Account object with some primary
properties and containing a collection of current Transaction objects?
Or do you focus on the presentation style objects - Tables, nested
Tables, Lists etc?

I looked over your site and code, compact and impressive - probably a
stupid question, but are there any higher-level overviews of your
approach / framework?

TIA
Jeff

RE: separating C from V in MVC

[Jeff AA]

> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] 
> Sent: 31 May 2002 16:27

Perrin, fab feedback as ever, I think I am almost at the 1,000 
thanks for Perrin level 8-) - oh, and 1,000 apologies too, for 
all the questions you've answered before! I hope you don't mind
me pestering you with yet more MVC questions!


> For more background on templating tools, see my article here:
> http://perl.apache.org/features/tmpl-cmp.html

Very interesting, and obviously more to look into... describes
the Pipeline model as more MVC.

> Ideally you should have no style information at all in the model.

Ok - but based on my experience with our reporting system which
currently renders in PDF, Excel, Text and HP-PCL, the rendering
engine aka View needs to know a little more...

For example to render a date in Excel some jiggery pokey is required,
and I would also expect a HTML V to print pretty dates rather than 
20020531172534 (or something other than the raw stringification)

We also deal with lots of numerics - some are quantities, and others 
are values or interest rates - they need zero, 2 or 4dps when being
presented.

And don't forget the 1,000's separator - I want real Excel numbers, 
that users can SUM() but which are presented as commified, whereas the 
HTML V will have to commify the numerics itself.


>> How does the view layer know for example to render an Error cell 
>> as RED in HTML but blue in Excel due to Excel palette limitations?
>
>You have different views for different targets.  Make an HTML view and 
>an Excel view and have the controller know which one to use.

This was more a question about how a View would decide to render a
style like OVERDRAWN / ERROR rather than which view to use - ie the
same as the issue above about working with more than strings.


> the model provides the list of errors, and the view knows how to 
> display them.

Apologies, my use of the word ERROR has confused folks. I was not 
talking about errors that occurred in the model processing, but 
rather about more advanced STYLES that might be applied to an
element (eg a cell in a table) for some business reason. So for
example if your savings balance has gone negative, the value should
be rendered as an error balance rather than a normal balance. In
HTML you might choose to display the cell with a RED background,
but this does not work in Excel, where a RED background prints as
black, so you can't just tell the view RED - you need to tell it
the reason and let Excel choose one of its limited bg colours.


> The model might be made up of dozens of different classes

Ok - so results from a collection of models are assembled and 
passed to the view.

>> What controls the overall layout?
> The view.
>
>> e.g. what is the equivalent of the
>> 'Grid Bag' layout manager - is this done in the Controller? and then
>> passed to the View with all the data from a set of Models? Or do you 
>> make the Controller minimalist and have a meta-Model that assembles
>> all the sub-Models into a layout.

 - not sure if I like this. I thought the whole point of the View
was to contain all the logic about things like HTML tags or Excel binary
representation etc, and as little as possible about other things.

Layout man agent is a problem that has been isolated in other langs - 
the Grid Bag layout manager is an [old!] Java class that manages the 
interaction of collection[s] of widgets and sub-forms on a screen and 
is esp. useful when screens can be dynamically resized, and controls, 
text etc will flow / realign / resize and generally shuffle about.

In HTML things like the WIDTH=100% attribute of a table or TD are 
directives to the HTML layout manager implemented in browsers. The
layout manager is usually concerned with several elements of the
interaction of a collection of things - alignment, flow and sizing.

Exactly where in the MVC world, would I decide that column 3 which
contains a description should expand to fill 70% of the available 
space and that column 5 which contains a possibly long name should 
use the remaining available space, whilst column 1 which contains
a name should not be wrapped?

I think of a layout manager as a collection of hints to the V on how 
all the bits should be fitted together in relation to each other. I 
want my various Vs to be supplied data from the same set of Models - 
but don't forget that the PDF V will not support scroll-bars! Poor 
ol PDF-V will have to intelligently render data that does not fit 
within the width of the users selected physical page width!

I guess I have talked myself round to thinking that the Controller
is actually the layout manager, in that it marshals results from
a set of models, decides how this collection should interact, and
then asks an appropriate View to render the result in a specific
interface flavour.

Have I talked myself out of HTML:Template route? Not sure, I guess
it depends on whether HTML::Template can be smartened up to 
understand that I want Dates rende

RE: separating C from V in MVC

[Jeff AA]

> From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] 
> Sent: 30 May 2002 22:42
> To: 'Ray Zimmerman'; modperl List; Mason List

Jesse, thanks for your comments, I found them very interesting.
I am comfortable with Perl and Web programming (though previously
not the two together) and am about to embark on development of
a new product for an ASP, so have considerable interest at this
stage of the proceedings.

I would like to ask some further questions, please forgive the
extensive haircut of your comments:

> applying a design pattern such as MVC is not a panacea
I agree - I much prefer Perlish DWIM dweomer

>Model:  The business logic.  Not related to the UI at all.
>View:   The user interface.
>Controller:  The glue between the View and the Model.

> ... the Model is simply a Perl module... make it entirely separate 
> from the user interface... the methods... being called from a web 
> application, a cron script, or an email-based interface

Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days'

status] this seems to indicate the Model accepts method calls and
returns
data that will be rendered elsewhere. In our planned development, there
is a LOT of tabular data - do you use any standards for the data being 
returned to the Controller? eg do you use a struct [ie hash/array Perl
primitive] or do you return an object? eg a table object etc?


> The View, in a web application, is really the HTML output.  

Sounds good, so I could also pass the Models returned data to a
different
flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a
lot
like our existing Perl reporting infra which does exactly that.

W3 did a huge amount of analysis on layout and style as part of the CSS 
specs. In our setup, the table objects contain lots of style info. It is

easy to render complex tables in PDF [as HTML will be] but formats like 
Excel are very hard, as there are layout constraints [eg a column can
have 
only one width for the entire page - we call this the 'Highlander
Effect']

Is this true of your setup? does the Model returned data contain lots of
style hints? Or do you leave this completely to the View layer? How does
the view layer know for example to render an Error cell as RED in HTML
but blue in Excel due to Excel palette limitations?


> Optimally, the View avoids *ALL* application logic.  
 - so the Model has to say RED rather than ERROR? but that wouldn't
work if rendering something where RED is illegible? Our reporting knows
about basic things like Error, Good, User Date / Numeric preferences 
etc.

> At my company we use HTML::Template ... it's damn fast, too
will look at this - is there a list somewhere?


> The Controller connects the View to the Model... takes user input 
> ... translates it into method calls on the Model... then takes output 
> from the Model and passes it to your View.

Sounds like Controller only interacts with one Model? I would assume 
that a Controller might collect data from a number of Models, and then
pass the collection of data to a View?

What controls the overall layout? e.g. what is the equivalent of the
'Grid Bag' layout manager - is this done in the Controller? and then
passed to the View with all the data from a set of Models? Or do you 
make the Controller minimalist and have a meta-Model that assembles
all the sub-Models into a layout.


> CGI::Application modules
will do some reading on this also then.

> separating the View from Controller is a problem.

I guess this is a balance between purist and DWIMism, but as we already
have this separation for reporting, I would like to extend it into our
dynamic web page generation.


> If you have to work with an SPS such as Mason but you still want to 
> separate your View from your Controller, you have to work twice as
hard.
Interesting!

Jesse, I found your posting extremely useful - thank you very much!

Regards
Jeff

RE: unable to use method type handlers?

[Jeff AA]

> Try per load the class my::class via startup.pl or PerlModule

I already had PerlModule my::classes in httpd.conf
Tried PerlRequire as well - still the same error

help??


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of
[EMAIL PROTECTED]
Sent: 14 May 2002 09:58
To: Jeff AA
Cc: [EMAIL PROTECTED]
Subject: Re: unable to use method type handlers?


Try per load the class my::class via startup.pl or PerlModule

Tor.


Jeff AA wrote:
> 
> Whenever I try to set up a method type handler
> 
>   PerlHandler my::classes->mymethod
> 
> I get the following in the error log:
> 
>   Undefined subroutine &my::classes->mymethod::handler called.
> 
> using:
>   Apache/1.3.23 (Unix) Debian GNU/Linux
>   mod_perl/1.26 mod_ssl/2.8.7 OpenSSL/0.9.6c
> 
> any hints would be appreciated

unable to use method type handlers?

[Jeff AA]

Whenever I try to set up a method type handler 

  PerlHandler my::classes->mymethod

I get the following in the error log:

  Undefined subroutine &my::classes->mymethod::handler called.

using:
  Apache/1.3.23 (Unix) Debian GNU/Linux 
  mod_perl/1.26 mod_ssl/2.8.7 OpenSSL/0.9.6c

any hints would be appreciated

mod_perl: User Authentication recommendations requested

[Jeff AA]

I have a requirement to protect all pages on a website, and to only
allow in users with a valid user id, password, client certificate and
recognised IP.

I know this is asking a lot, but I would appreciate an
overview/recommendation of approaches that are 1st safe, and 2nd fast.

I think something like:

Scenario 1: unauthenticated user gets authenticated
1) user hits site - no session = unauthenticated
   create new session, remember requested page, redirect to /login page
2) /login page: collect username/password, POST action is /authenticate
3) /authenticate page: perform checks, if all ok set
$session->is_logged_in(TRUE);
   and redirect to originally requested page [stored in session]

Scenario 2: authenticated user accesses site
1) user hits page - has session
   redirect to /login if ( not $session->is_logged_in() );
   redirect to /login?message=inactivity+timeout if (
time-$session->last_access()>1hr );

Which seems to fit the functionality bill - users can bookmark their
favourite part of the system. When they come in but have not yet
authenticated, they get momentarily diverted through the
/login/authenticate pages.

Is this safe? 
How should I ensure that the sessions never get hijacked?

I am thinking along the lines of an additional transient cookie issued
when
the session authenticates the user that contains
md5(some_secret+session_id) that
is also checked?

And... is there already a nifty mod_perl class that does all this? I
have Apache::AuthCookie working from examples, but don't know what the
security implications of using it are, without reading the code [which I
will do soon I guess]. I also have problems with the LOGIN POST saying
POST: METHOD NOT ALLOWED when I try to get mod_perl to be the handler
for Location /.

Any recommendations/feedback appreciated! Even if it's a recipe I
haven't yet reached!

Thanks in advance,
Jeff