RE: Building high load mod_perl/Mason servers
Eric, What we do with our PHP/mod_perl boxes is develop everything locally on development servers and then export it all using rsync. We have six servers in our cluster that we rsync to. Basically, we store everything in a local CVS repository. When changes are made on the local dev boxes and any script is updated, they are checked into the CVS. Then we run a script that syncs from the local CVS to the remote servers (cvs checkout to a temp dir, then rsync from the temp dir to the live servers). It has been working very well so far. Jeremy -Original Message- From: Eric Frazier [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 06, 2002 7:44 PM To: [EMAIL PROTECTED] Subject: Building high load mod_perl/Mason servers Hi, I just got the chance to be in charge of a very busy website, and its future growth. Currently it is running with PHP on two round robin servers with a separate mysql db server. We are going to be moving to mod_perl, but I am worried about how to keep from getting into the same kind of trap with mod_perl as with PHP. The PHP guys don't know OOP, so we have to code halfway, modules exporter but not OOP modules. It has to be something OOP like without getting too complex at first. The PHP trap is just the horrible require once stuff all over the place and global vars etc. I know lots of people blame this kind of coding on perl geeks, but the PHP stuff I have been seeing is pretty bad with it because the constant thought is must fix current problem wait till later to be pretty but later never comes. Also things like using ten instr functions instead of one reg exp. So I am thinking whatever I do it should fit within an existing framework, something like Mason. But I am confused about what real advatage Mason provides, and how things like source code control would work if we are running lots of servers. Do people use rsync to keep up to date? Say one machine is always the upload point and the rest get synced from that one? I am having a hard time asking really good questions I think because there are so many things I am trying to think out. Thanks for any ideas, Eric http://www.kwinternet.com/eric (250) 655 - 9513 (PST Time Zone) Inquiry is fatal to certainty. -- Will Durant
Re: separating C from V in MVC
On Thu, 6 Jun 2002 20:15:24 -0600, Rob Nagler [EMAIL PROTECTED] said: (http://sourceforge.net/projects/poop/). RN Great, another mailing list. :-) Thanks. It is not just mailing list. Don't miss http://poop.sourceforge.net/. It has nice review of most Perl OO persistence modules. -- Ilya Martynov (http://martynov.org/)
Re: rfc Apache::Dynagzip
On Thu, 6 Jun 2002, Slava Bizyayev wrote: I mean that Apache fixup handler is not right place to decide should we use gzip encoding or not. I'd prefer to address it the point where the web server administrator has to fix the Accept-Encoding HTTP header, if one is incorrectly issued by buggy web client. Any early stage of the request proccessing is good for that as long as the following stages do not alter this header. The FixUp is the most appropriate place for such correction in terms of Apache architecture. I don not think that change or deleting of incoming headers is good idea. How can I log a real Accept-Encoding value ? Igor Sysoev http://sysoev.ru
Re: separating C from V in MVC
On Fri, 2002-06-07 at 03:15, Rob Nagler wrote: Agreed. Perl is good at text manipulation. It is imiho superior to XSLT in all spaces which XSLT claims to solve. Once you have an XML parse tree in Perl, it's trivial to write a translator to any format more correctly than XSLT. My favorite example is XML to CSV. Every example I've seen in XSLT is cumbersome and wrong. You'd think it wouldn't be hard, but try it. ;-) XSLT is an XML to XML transformation tool. Seems fairly obvious to me it's not going to do XML to CSV very well. For that you use SAX. I disagree with you in all uses of transforming an XML tree into another XML tree. Right tool for the job, as always. Matt.
RE: [OT] MVC soup (was: separating C from V in MVC)
Hi all, On Fri, 7 Jun 2002, Valerio_Valdez Paolini wrote: On Thu, 6 Jun 2002, Jeff wrote: We can take the discussion off-line if the list feels it will be too OT. No, please :) Yes, please. 73, Ged.
Exporter variables get lost
Hello,
I'm working on mod_perl project which has many different modules. One is
so-called 'main' modules which loads other when needed. Until now
everything worked just fine, but now one module just says that he doesn't
know the variable I've exported.
And interesting is, that when I comment out either
$sub_first-do_something(); or other three lines about Sub::Second then it
works just fine.
Error it get looks like this:
Can't call method notice on an undefined value at
/usr/local/lib/perl/5.6.1/Sub/First.pm line 25.
First.pm and Second.pm use Export.pm exactly same way. So, it this some
mod_perl specific feature to just eat up some variables, or what?
Here are cut-down versions of my modules:
Site.pm:
-
package Site;
use strict;
use Apache::Log;
sub handler {
my $r = shift;
use vars qw( $log );
$log = $r-log();
if ( $some_case eq 'true' ) {
use Sub::First qw( $log );
my $sub_first = new Sub::First;
$sub_first-do_something();
if ( $some_other_case eq 'yes' ) {
use Sub::Second qw( $log );
my $sub_second = new Sub::Second;
# if I comment out $sub_first-do_something then it works...
$sub_first-do_something();
$sub_second-do_something_else();
}
}
}
1;
---
package Sub::First;
use strict;
use Apache::Log;
BEGIN {
use Exporter();
Sub::First::ISA = qw( Exporter );
Sub::First::EXPORT= qw();
Sub::First::EXPORT_OK = qw( $log );
}
use vars qw( $log );
sub new {
my $class = $_[0];
my $objref = { };
bless ( $objref, $class );
return $objref;
}
sub do_somehing {
$log-notice(Now this here doesn\'t work);
}
1;
--
Rgds,
Viljo
Re: separating C from V in MVC
On Thu, Jun 06, 2002 at 08:15:24PM -0600, Rob Nagler wrote:
The issue here is not whether TT is a bad approach, but rather why the
syntax is not Perl.
One reason is that I like to have minimal syntax in the templates. One
argument often used is that non-programmer find it easier to say foo.bar
than $foo-{ bar }. But I think the more compelling argument is that
even experienced programmers find it easier to write. It's just less
syntax. I don't mind syntax in my Perl programs, it serves an important
purpose there. But in my templates, I prefer to have everything as
simple as possible.
Another reason is that foo.bar deliberately abstracts the difference
between $foo-{ bar } and $foo-bar(). You can change the underlying
implementation of a data structure and you don't need to update your
templates.
A third reason is that by abandoning strict Perl syntax I can be much
more flexible in providing a domain specific language tailored to the
task of generating and manipulating content.
A
Re: Exporter variables get lost
Viljo Marrandi actually wrote:
my $r = shift;
use vars qw( $log );
$log = $r-log();
if ( $some_case eq 'true' ) {
use Sub::First qw( $log );
I haven't tested, but this doesn't look as a good idea.
I don't think your code does what you think it does
(or what you think it should do.) Moreover I don't
know what this actually does (or should do) precisely.
Exporter essentially does this:
*Site::log = \$Sub::First::log;
and vars essentially does this:
*Site::log = \$Site::log;
And this symbol table manipulation occurs at compile-time,
before your code is run (without scoping effecs).
In other words don't do that.
--
Rafael Garcia-Suarez
persistent Mail::ImapClient and webmail
List,
I have the task in my hands of creating a web mail application. Initial
thoughts lead me to think I would use an external popper to pop mail and
parse it into a database for retrieval by the modperl application. The only
problem here is that I must provide the implementation of the mail storage
and folder management etc. Something I would rather not spend my time on. So
my thoughts turned to IMAP. Retrieve the mail from an IMAP server. IMAP
itself supports most mail management methods such as move message, delete
message, save draft, mark seen etc. So a few lines of perl later I had a
PerlChildInitHandler which connected to the IMAP server and saved the
connection object. I wanted to know if people saw any immediate problems
with this solution and also if anyone could explain the following
percularities.
If I store a single imap object in $imap, e.g.
my $imap;
sub connect {
my ($self,$centro_id) = @_;
print STDERR $imap,\n;
unless (defined $imap) {
print STDERR Connecting to IMAP for $centro_id\n;
$imap = Mail::IMAPClient-new( Server = 'cyrus.andrew.cmu.edu',
User = 'anonymous',
Password = '[EMAIL PROTECTED]',
);
}
return $imap;
}
This seems to successfully save the connection object. However if I attempt
to store the object in a hash, e.g.
my %imap_cache;
sub connect {
my ($self,$centro_id) = @_;
print STDERR $imap,\n;
unless (exists $imap_cache{$centro_id}) {
print STDERR Connecting to IMAP for $centro_id\n;
$imap_cache{$centro_id} = Mail::IMAPClient-new( Server =
'cyrus.andrew.cmu.edu',
User = 'anonymous',
Password = '[EMAIL PROTECTED]',
);
}
return $imap_cache{$centro_id};
}
I seem to have intermitent success in retrieving an already connected
object. Using the first example, as far as I can tell the object remains
available flawlessley. But storing the object in the hash doesn't. Am I
making a mistake here?
Another question sprung to mind, should I think about using Persistant::Base
or some similar approach to store the IMAP objects?, or should I lean
towards Randal's and others suggestions of having a seperate (possibles SOAP
or LWP::Daemon or even apache server in single user mode) server
specifically designed for performing IMAP requests?
Finally, does anyone with experience in having to write webmail interfaces
see any problems with using the functionality provided by IMAP.
Richard
p.s. Yes quite obviously if I have 100 children then I'll be connected to
the IMAP server 100 times per user, hence possibly the need to have a either
a dedicated daemon connected to the IMAP server once or some successfuly way
of sharing IMAP objects between children.
Re: Exporter variables get lost
The answer to the trick question is that the subroutine name in package
Sub::First is misspelled (missing a t).
However, I think I would provide the Apache::Log object as a parameter to
new() rather than twiddling with package vars to try to have it magically
updated by Exporter. For example:
package Sub::First;
use strict;
# simple constructor expects classname, log object
sub new {
my($class,$ap_log) = _;
return bless {apache_log=$ap_log}, $class;
}
sub do_something {
$self-{apache_log}-notice(this will work);
}
package Sub::Second;
use strict;
# another simple constructor expects classname, log object
sub new {
my($class,$ap_log) = _;
return bless {apache_log=$ap_log}, $class;
}
sub do_something_else {
$self-{apache_log}-notice(this will work, too);
}
package Site;
use strict;
use Sub::First;
use Sub::Second;
sub handler {
my $r = shift;
# test values for conditions
my $some_case = 'true';
my $some_other_case = 'yes';
if ( $some_case eq 'true' ) {
my $sub_first = Sub::First-new($r-log);
$sub_first-do_something();
if ( $some_other_case eq 'yes' ) {
my $sub_second = Sub::Second-new($r-log);
$sub_first-do_something();
$sub_second-do_something_else();
}
}
}
# End Example
Regards,
Tim Tompkins
--
Programmer
http://www.arttoday.com/
http://www.rebelartist.com/
--
Re: [OT] MVC soup (was: separating C from V in MVC)
Bill Moseley wrote: My MVC efforts often fall apart in the C an M separation. My M parts end up knowing too much about each other -- typically because of error conditions e.g. data that's passed to an M that does not validate. And I don't want to validate too much data in the C as the C ends up doing M's work. I agree that this is one of the thornier problems. For simple things you can just throw exceptions, as Jesse mentioned. This is all you need to do for system-level problems like failing to connect to the database. The difficult part is when you need to provide feedback to users on their incorrect input. For example, if you have a form for registering as a user which has multiple fields, you want to be able to tell them everything that was wrong with their input (zip code invalid, phone number invalid, etc.), not just the first thing you encountered. Putting that into a model object is awkward, since coding your constructor or setter methods to keep going after they've found the first error feels wrong. You can write a special validate_input() method for it which takes all the input and checks it at once returning a list of errors. You could also just punt and push this out to the controller. (Not very pure but simple to implement.) Either way you can use one of the convenient form validation packages on CPAN. Anyone have links to examples of MVC Perl code (mostly controller code) that does a good job of M and C separation, and good ways to propagate errors back to the C? You could look at the OpenInteract code. It includes some good examples. - Perrin
Can't set multiple cookies?
Ok, so continuing down the path of a single sign-on system, I've completed a
rough framework, and it works fine. However, I thought it might be nice to
segregate the various bits of information into different cookies.
Unfortunately, setting multiple cookies doesn't seem to be working. Here
are the outbound headers obtained via $r-as_string:
Set-Cookie: ACS_UID=miller; path=/
Set-Cookie: ACS_Test=blah; path=/
Set-Cookie: ACS_Ticket=stuff; path=/
on the next request, here's the Cookie header:
Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C
The RC_Creds cookie is set in a callback handler. So, where are the other
two cookies?
I've tried the following incantations:
foreach( [ $cookie_a, $cookie_b, ... ] ) {
$r-err_headers_out-add( 'Set-Cookie', $_ );
}
or
$r-err_header_out( 'Set-Cookie' = $cookie_a );
$r-err_headers_out-add( 'Set-Cookie' = $cookie_b );
or
$r-err_headers_out-add( 'Set-Cookie' = [ $cookie_a, $cookie_b ] );
The outbound headers all look the same, but in each case, only the last
cookie is set. This happens with both Netscape and IE.
The really annoying thing is that this was working at one point: I would set
multiple cookies in one go, and all the cookies would be sent back to the
server on the next invocation.
I've searched the Guide and online, but I've not found any clues as to why
the multiple cookies are NOT being set.
Brain cramp, or something more serious?
-klm.
Re: Can't set multiple cookies?
On Fri, 7 Jun 2002, Ken Miller wrote: Ok, so continuing down the path of a single sign-on system, I've completed a rough framework, and it works fine. However, I thought it might be nice to segregate the various bits of information into different cookies. Unfortunately, setting multiple cookies doesn't seem to be working. Here are the outbound headers obtained via $r-as_string: Set-Cookie: ACS_UID=miller; path=/ Set-Cookie: ACS_Test=blah; path=/ Set-Cookie: ACS_Ticket=stuff; path=/ on the next request, here's the Cookie header: Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C I suspect you're using a 2-tier Apache setup with Apache 1.3.23 on the frontend, right? This is a bug in mod_proxy with 1.3.23. I _think_ its fixed in 1.3.24. If you're using 1.3.24 try reverting to 1.3.22 (which I know works) and see if that fixes it. -dave /*== www.urth.org we await the New Sun ==*/
Re: [OT] MVC soup (was: separating C from V in MVC)
On 6/7/02 1:04 PM, Perrin Harkins wrote:
For example, if you have a form for registering as a user which has
multiple fields, you want to be able to tell them everything that was
wrong with their input (zip code invalid, phone number invalid, etc.),
not just the first thing you encountered.
Putting that into a model object is awkward, since coding your
constructor or setter methods to keep going after they've found the
first error feels wrong. You can write a special validate_input()
method for it which takes all the input and checks it at once returning
a list of errors. You could also just punt and push this out to the
controller. (Not very pure but simple to implement.) Either way you
can use one of the convenient form validation packages on CPAN.
I use my form objects to do this. For example, to process a create user
form, the controller creates the form object:
$form = My::Form::User::Edit-new;
Initializes it based on the form submission:
$form-init($form_params);
runs the form object's validate() method:
unless($form-validate)
{
...
and then (if the validation fails) passes the initialized form objects to
back to the view:
$app-edit_user_page(form = $form);
There are per-field and per-form errors which are set during the validate()
step. The view decides where, how, and if to display these.
Going in the reverse direction (say, editing an existing user), the
controller creates the form again:
$form = My::Form::User::Edit-new;
gets the user object (and handles errors, yadda yadda):
$user = My::Users-get_user(id = $id) || ...;
initializes the form with the model object:
$form-init_with_user($user);
and then passes the form to the view:
$app-edit_user_page(form = $form);
The details have been heavily simplified above, but that's the general idea.
I'm not sure how this all fits into MVC, but it works very well for my
purposes.
-John
RE: [OT] MVC soup (was: separating C from V in MVC)
Hey Perrin Bill -- You could also just punt and push this out to the controller. (Not very pure but simple to implement.) This is exactly what I had in mind. (Perhaps you can explain what you mean by not very pure.) The methods in any model module I would write would have expectations that input is already valid. Invalid input to a model method should throw an exception of some sort (maybe die() -- but something clearly documented in POD, whatever it is). The purpose of the controller is to validate input and construct valid arguments into these model methods. The controller is also responsible for catching any exception from the methods it calls (model methods, Perl core methods, other module methods -- they're ALL the same!), and relaying that to the output view in a reasonable fashion. By reasonable I do *not* mean pretty HTML. A 500 Internal Server Error is perfectly reasonable in some situations. This fits into my general feeling that the role of the controller is to interface between the UI and the model. As I said in my first message on the topic, the model should be thought of in the context of being used from a variety of interfaces besides the web (cron, for instance). A controller between a cron process and your model, for example, would be responsible for ensuring that valid arguments are passed into the model methods and that errors are thrown back to cron in such a way that cron can do something useful with them (such as invoke Vixie cron's capability to email the process owner). Either way you can use one of the convenient form validation packages on CPAN. The members of the CGI::Application mailing list seem particularly fond of the Data::FormValidator module. TTYL, -Jesse-
open_basedir
Hello, is there a possibility to limit mod_perl users in the same way as the PHP 'open_basedir' option does? Quoting from the PHP manual: --- open_basedir - Limit the files that can be opened by PHP to the specified directory-tree. When a script tries to open a file with, for example, fopen or gzopen, the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink. --- Thanks for any help, Ben Blazke ([EMAIL PROTECTED]) __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com
RE: Can't set multiple cookies?
Yup, just confirmed it. 1.3.20 works fine, but .24 is busted. I'll try the latest CVS version. Thanks guys! -klm. -Original Message- From: Balazs Rauznitz [mailto:[EMAIL PROTECTED]] Sent: Friday, June 07, 2002 2:48 PM To: Dave Rolsky Cc: Ken Miller; [EMAIL PROTECTED] Subject: Re: Can't set multiple cookies? On Fri, Jun 07, 2002 at 12:32:56PM -0500, Dave Rolsky wrote: On Fri, 7 Jun 2002, Ken Miller wrote: Ok, so continuing down the path of a single sign-on system, I've completed a rough framework, and it works fine. However, I thought it might be nice to segregate the various bits of information into different cookies. Unfortunately, setting multiple cookies doesn't seem to be working. Here are the outbound headers obtained via $r-as_string: Set-Cookie: ACS_UID=miller; path=/ Set-Cookie: ACS_Test=blah; path=/ Set-Cookie: ACS_Ticket=stuff; path=/ on the next request, here's the Cookie header: Cookie: ACS_Ticket=stuff; RC_Creds=miller%2C I suspect you're using a 2-tier Apache setup with Apache 1.3.23 on the frontend, right? This is a bug in mod_proxy with 1.3.23. I _think_ its fixed in 1.3.24. If you're using 1.3.24 try reverting to 1.3.22 (which I know works) and see if that fixes it. 1.3.24 is broken in more than one way; I am using the latest CVS version without problems. Balazs
Re: separating C from V in MVC
::really hesitates to step into this ... but like a train wreck ... he simply can't resist:: It's like asking why XML has different syntax and semantics from Perl. Well, if you read the XSLT spec and then look at an XSLT program, you'll see a lot of verbosity and a lot of general purpose constructs like variables, conditionals, and loops. I haven't done much with XSLT, but I do know you can get it in an infinite loop. That seems pretty general purpose to me. Well aside from the fact that XSLT is Turing complete (And thus theoretically as powerful as Perl or C or Java) the syntax structure of XSLT (because it is a derivitive of XML) makes it difficult to do some things (try writing a version of sed in XSLT). This I think was the original point. Perl handels Regex's better than C, this is one of the reasons people use Perl. It makes (some) hard things easy and (some) impossible things hard ... within it's domain. XSLT is no different. Use the appropriate tool (or Toolkit) for the problem. I think the rule is: if you can solve Towers of Hanoi in the language, its general purpose enough. True formatting languages, such as, Scribe do not contain general-purpose constructs, so you couldn't solve the Towers of Hanoi. HTML is another good example (ignoring script). I do want to point out for clarity and posterity that HTML and XSLT are siblings ... in that they are both applications of XML (or SGML). HTML is not Turing Complete while XSLT. Turing completeness has a mathmatic existance beyond the Towers of Hanoi problem. But I haven't seen it solved in TeX either (::know's there's gotta be a link for this::). Rob, is what you are suggesting that one should not use a turing complete language for visual markup or that simply the language should be the best match for the solution? I'm just looking for clarity on your position. Why is there so little discussion of the M in MVC? It's far from a trivial problem. As I am currently mostly writing M and C and would be interested in some thoughts on the issues surrounding M. Like what issues have other people come across and how have other's dealt with them? This is the biggest benefit I have gained thus far from Perrin's eToys article (that and using it to sell mod_perl to my superiors as a better solution than Java eToys delt with 10x these many customers ... I think our system can handle the load). -Chris -- [A] Genuinely skillful use of obscenities is uniformly absent on the Internet. -Karl Kleinpaste
Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)
On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote: Suppose you have a model object for a concert which includes a date. On one page, the designers want to dipslay the date in a verbose way with the month spelled out, but on another they want it abbreviated and fixed length so that dates line up nicely. Would you put that formatting in the controller? In the script: $template-param(long_date = $long_date, short_date = $short_date); In the template: The long date: tmpl_var long_date br The short date: tmpl_var short_date Can I vote for yick on this? A designer should never have to come to a programmer just to change the formatting of a date. I'm a huge fan of passing Date::Simple objects, which can then take a strftime format string: [% date.format(%d %b %y) %] [% date.format(%Y-%m-%d) %] Tony
Re: separating C from V in MVC
::realizes this may be going a bit futher a field ... but tries to maintain topicality:: Chris writes: Perl handels Regex's better than C, this is one of the reasons people use Perl. I disagree. Perl's Regex processor is written in C. The difference is that it has outgrown Henry Spencer's regexp library. Mmm semantic differences I yield the floor seneator, but I wish it to go on the record that Regex's are built into the main syntax of the Perl language, and are fully supported by the culture. While you must specifically link to and consiously add in Regex's in C. You can build a Hash, Queue and Stack in C as well, but that doesn't mean that they aren't generally simpler to use in Perl because they're built right into the language. It makes (some) hard things easy and (some) impossible things hard ... within it's domain. XSLT is no different. Use the appropriate tool (or Toolkit) for the problem. Agreed. Perl is good at text manipulation. It is imiho superior to XSLT in all spaces which XSLT claims to solve. Once you have an XML parse tree in Perl, it's trivial to write a translator to any format more correctly than XSLT. My favorite example is XML to CSV. Every example I've seen in XSLT is cumbersome and wrong. You'd think it wouldn't be hard, but try it. ;-) Well XSLT wasn't really designed (and shouldn't have been) to output plain text. Despite what the W3C says. It's designed to tranlsate between XML Vocabularies. I'll explain in a bit why I feel that XSLT is better suited for this than Perl. existance beyond the Towers of Hanoi problem. But I haven't seen it solved in TeX either (::know's there's gotta be a link for this::). I'm sure Randall wrote a TeX to TT translator to generate his TT version of ToH. ;-) Merlyn any comments here? Other Powers-That-Be? I could see this as a JAPH ... only for size N problems it would take N^2 years to print. Rob, is what you are suggesting that one should not use a turing complete language for visual markup or that simply the language should be the best match for the solution? I'm just looking for clarity on your position. The question really surrounds little languages. Perl is ideally suited to creating them. There's no reason to invent a new syntax ([% %]) or semantics for standard structures. I think you should write classes in Perl that map to some interface which defines the language. This is where I think we have a disagreement. In usability circles there is an idea that different things should be ... well ... different. If one button turns on the radio ... it shouldn't look anything like the button that launches the missles. This is why I find XSLT well suited for XML-XML transformations because it is visually/ideologically well suited to it's primary domain. If I'm dealing with the angle brackets and the tree structure ... then I'm thinking about the angle brackets and the tree structure ... eventually I'm zenning in the whole Angle Brackety Tree Structury-ness of the world. (I have a degree in english I know exactly how awful that sentance was.) It may be true that Perl can do it quicker and faster ... but for me the advantage to visually distinguishing the logically different parts helps future maintainability. C and Perl are distinctly different because the domains they are best suited (and designed) for are distinctly different. Nobody wishes Perl's syntax were more like that of C, Java, or Cobol. If they do they should probably be writing C, Java or Cobol. (Inline::Cobol anyone?) In MVC if each letter were written in it's own language it would be very easy to maintain the seperation. If it's generally impractical to use three distinct languages* one should keep as much visual distinction between the three as possible. *Generally people already do use three langauges though with the Template Language (HTML|ASP|TT|XSLT), the Controller Language (Perl) and the Model Language (SQL). It's pretty much gotten to the point where nobody gets fired for choosing Java. I've lost many contract bids because I didn't say Java was the right solution. I haven't lost a single customer who let us solve the problem for them. People don't approach a contractor and tell them what tools to build a house with. Why do they insist on doing it with programmers? -Chris -- [A] Genuinely skillful use of obscenities is uniformly absent on the Internet. -Karl Kleinpaste
Re: [Templates] Re: Separating Aspects (Re: separating C from V in MVC)
On Fri, Jun 07, 2002 at 09:14:25AM +0100, Tony Bowden wrote: On Thu, Jun 06, 2002 at 05:08:56PM -0400, Sam Tregar wrote: Suppose you have a model object for a concert which includes a date. On one page, the designers want to dipslay the date in a verbose way with the month spelled out, but on another they want it abbreviated and fixed length so that dates line up nicely. Would you put that formatting in the controller? In the script: $template-param(long_date = $long_date, short_date = $short_date); In the template: The long date: tmpl_var long_date br The short date: tmpl_var short_date Can I vote for yick on this? A designer should never have to come to a programmer just to change the formatting of a date. I'm a huge fan of passing Date::Simple objects, which can then take a strftime format string: [% date.format(%d %b %y) %] [% date.format(%Y-%m-%d) %] Tony xmlns:date=http://exslt.org/dates-and-times; wins for me. date:date-time() date:date() date:time() date:month-name() ... etc xslt solutions win for me because it its supported (or seems to be) by many major languages, and applications. xslt stylesheets can be processed, reused and shared with my c,perl, java,javascript, ruby, mozilla, ieexplorer ... kde apps, gnome apps ... etc Imagine having your templates and data supported and interoperable ... Aren't we trying to rid the world of proprietary (only works here) things? Ed (an axkit lover)
