On Wed, 5 Jun 2002, Andy Wardley wrote:
In TT, you would usually pre-declare a particular format in a config
file, pre-processed templates, or some other global style document.
e.g.
[% USE money = format('%.02f') %]
In your main page templates you would do something like this:
[%
Andy Wardley writes:
Because Perl is a general purpose programming language. TT implements
a general purpose presentation language. A different kettle of fish
altogether.
These are the reserve words of TT:
GET CALL SET DEFAULT INSERT INCLUDE PROCESS WRAPPER
IF UNLESS ELSE ELSIF
Rob Nagler wrote:
The way I understand how plugins work is that they are arbitrary
classes. But how do you share behavior?
I probably wouldn't use a plugin for something that needed to output
HTML, because that would prevent the designers from editing it. A macro
(basically a
On 6/4/02 12:32 PM, Perrin Harkins wrote:
The thing that worries me about a widget approach is that I would have
the same problem I had with CGI.pm's HTML widgets way back: the
designers can't change the HTML easilly. Getting perl developers out of
the HTML business is my main reason for
Perrin Harkins writes:
You can actually do that pretty comfortably with Template Toolkit. You
could use a filter for example, which might look like this:
[% FILTER font('my_first_name_font') %]
... some text, possibly with other template directives in it...
[% END %]
One of the reasons
On Mon, 3 Jun 2002, Rob Nagler wrote:
Date: Mon, 3 Jun 2002 08:09:12 -0600
From: Rob Nagler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: separating C from V in MVC
Perrin Harkins writes:
You can actually do that pretty comfortably with Template Toolkit. You
could use a filter
Rob Nagler wrote:
Perrin Harkins writes:
You can actually do that pretty comfortably with Template Toolkit. You
could use a filter for example, which might look like this:
[% FILTER font('my_first_name_font') %]
... some text, possibly with other template directives in it...
[% END %]
I really enjoyed this topic... I hope you guys are planning on actually
documenting your ideas. I would love to read and learn more about this
topic.
-r
Perrin Harkins writes:
The advantage is that my example can contain other templating code:
[% FILTER font('basic_info_font') %]
Hello [% User.first_name %]!BR
[% IF User.accounts %]
You have these accounts:BR
[% FOREACH User.accounts %]
[% name %]: [% balance
Rob Nagler wrote:
[Skirting on the edge of YATW. :-]
I certainly don't mean to have a templating war. I'm just trying to
figure out what the difference is between these approaches and if
there's something I've been missing that I should consider adding to
future applications.
Here's your
On Sat, 1 Jun 2002, Barry Hoggard wrote:
I don't think the standard HTML::Template has support for formatting
numbers, dates, etc.
And thank the sweet lord it doesn't! HTML::Template is a do one thing
and do it well module. If you want routines for formatting numbers,
dates, etc. then CPAN
It seems problematic to me to require the programmers to do work
when a
designer wants to change the number of decimals in a page, for
example.
HTML::Template::Expr may present a solution to this particular desire,
although it isn't one I've come across. How often are HTML designers
It is interesting to try and fit our approach into the MVC+template
pattern
Just to clarify, it's not MVC+template; it's just MVC. The templates
are one way of implementing views. You could mix and match this where
appropriate, so that your Excel view is a perl module with a set of
A String widget/template allows you to control the rendering of all
fonts dynamically. If the String widget/template sees the incoming
request is from IE5+, it doesn't render the font if the font is the
same as the default font. The Style widget/template renders the
default font in a style
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
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 01 June 2002 00:17
To: Rob Nagler
Cc: [EMAIL PROTECTED]
The same template? How does the layout manager help with that?
Does it modify the template? It would make more sense to me if
this were a sort of abstraction to factor out
At 15:09 01.06.2002, Jeff wrote:
From: Perrin Harkins [mailto:[EMAIL PROTECTED]]
Sent: 01 June 2002 00:17
To: Rob Nagler
Cc: [EMAIL PROTECTED]
The same template? How does the layout manager help with that?
Does it modify the template? It would make more sense to me if
this were
I forgot to ask one thing about Jesse's comments.
I don't think the standard HTML::Template has support for formatting
numbers, dates, etc.
How do you make sure that it's done consistently in your applications?
It seems problematic to me to require the programmers to do work when a
designer
From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]]
Sent: 01 June 2002 18:10
To: Jeff
Well, as I see this, it isn't a problem. The layout manager takes
the place of the view, as it essentially decides how things should
be rendered. You then have two stages in your view, but the same
From: Barry Hoggard [mailto:[EMAIL PROTECTED]]
Sent: 01 June 2002 19:16
I don't think the standard HTML::Template has support for formatting
numbers, dates, etc.
Perrin indicated that you can extend HTML::Template in some way
to accommodate this, but I am not yet sure of the details.
At 21:14 01.06.2002, Jeff wrote:
From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]]
Sent: 01 June 2002 18:10
To: Jeff
Well, as I see this, it isn't a problem. The layout manager takes
the place of the view, as it essentially decides how things should
be rendered. You then have two
From: Rob Nagler [mailto:[EMAIL PROTECTED]]
Sent: 31 May 2002 23:48
Models can only express meta info about the data, not the context
in which the data is rendered. Some info, like placement, is
conditional on the grouping which is chosen by the view. A layout
manager abstracts
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
From: Jeff AA [mailto:[EMAIL PROTECTED]]
Hiya,
my 2 pence worth:
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
Jeff AA wrote:
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?
HTML::Template requires you to pass a perl data structure. Template
Toolkit can handle objects as
Hey Jeff Perrin --
HTML::Template requires you to pass a perl data structure. Template
Toolkit can handle objects as well (i.e. automatically call their
accessor methods to fetch properties). Passing perl structs
is faster,
while passing objects allows for some additional tricks
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
Jeff AA writes:
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?
We call this a Grid widget in our framework (bOP). There are many
options:
Hi Jesse,
It's the addition tricks which bug me out. With those two words you
establish the mother of all slippery slopes to architecture oblivion. When
you have objects passing freely between your Controller and View (which
are quoted here, 'cuz I don't think they are separate in this
Jesse Erlbaum wrote:
As you have already identified, the Model is simply a Perl module. The most
important thing to think of when writing a Model module is to make sure you
make it entirely separate from the user interface. It helps me to think of
the methods in the Model as potentially
On Fri, 31 May 2002, Barry Hoggard wrote:
Do you have a favorite approach for writing the Model objects? At
Investorama we created a class called TableObject that would deal with
getting/setting values from the database, plus doing data verification
like checking for values being present
Dave Rolsky wrote:
Alzabo could handle a _lot_ of this for you. Class::DBI could handle some
of it (though less).
SPOPS is also a good choice for this. All of them are on CPAN, just
waiting for you.
- Perrin
Jeff AA wrote:
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)
Yes. That's why you need to use a good templating system. There is a
Barry Hoggard writes:
Do you have a favorite approach for writing the Model objects?
One solution is to create an interface for accessors, i.e. get,
which the views call on objects they need to access. Our controller
and model objects share this same accessor interface, which allows
the views
Perrin Harkins writes:
That's exactly what I'm saying, except that I don't see what your
layout manager is for. You should just pass some data to a template
(or maybe to something fancier for certain types of output like Excel)
and then the template makes all the decisions about how to
Rob Nagler wrote:
Layout managers accept a declaration ('this cell is northwest', 'this
other one expands across the bottom', etc.). They interpret the decl
at run-time. It's like HTML, but more declarative. Some attributes
of our Grid manager are:
cell_nowrap - don't wrap the text in
Rob Nagler wrote:
Let's say, though, that you want the same template to render
in a WAP, Opera, Konqueror, IE, NS, etc. The implementation of Grid
handles this for you. For example, our code automatically renders
style sheets for IE5+, but no other browsers. (This isn't in Grid,
but you
Perrin Harkins writes:
The same template? How does the layout manager help with that? Does it
modify the template? It would make more sense to me if this were a sort
of abstraction to factor out common layout ideas from multiple
templates.
I think we're miscommunicating. I'm talking
I think it'll be great to present the current discussion as a tutorial,
so others can make a better use of the ideas thrown here, rather digging
in archives. This could be a great addition to our growing tutorials
section for the new site we are working on:
Hi Ray --
I'm looking for some pointers on MVC in this context. Specifically, M
is easy ... use Perl objects, but how are others implementing the
Controllers and Views in order to keep them separate?
[...snip...]
What's the right way to do it? (None of this TMTOWTDO stuff now, I
want
We're developing a pretty complex web app using mod_perl and Mason
and I'd like to use some form of MVC structure to keep things
manageable.
I'm looking for some pointers on MVC in this context. Specifically, M
is easy ... use Perl objects, but how are others implementing the
Controllers and
Ray Zimmerman wrote:
If I understand correctly, the Mason component that generates the page
the user sees would be considered the View. But where is the Controller?
I wrote a little about this in my templating guide, and there has been
discussion on the Mason list. A common approach is to
101 - 142 of 142 matches
Mail list logo
