[Catalyst] CGI.pm and Catalyst?
Is there anything attached to Catalyst similar to the CGI.pm module? That
is, creating the HTML by a series of procedure calls rather than by
instantiating a template?
Or is there some way to link up the existing CGI module?
$c-response-body(ul(li(q{hello}),
li(q{world} ?
Or is it not a good idea?
I couldn't find anything from a search, so excuse me please if this has been
covered before.
--
Regards,
Martin
([EMAIL PROTECTED])
IT: http://methodsupport.com Personal: http://thereisnoend.org
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On Thu, Mar 6, 2008 at 11:11 PM, David Jack Wange Olrik [EMAIL PROTECTED]
wrote:
Here is a small patch for Catalyst::View::Mason.
When setting $c-stash-{template}, template_extension was not added
to the component path. In my opinion this should always be added, so
one can easily change the view without having to provide extra logic
that sets the template extension according to the current view.
C:V:TT behaves exactly the same way [0] and i suspect its not the only
view that does
cheers m
[0]
http://search.cpan.org/src/MRAMBERG/Catalyst-View-TT-0.26/lib/Catalyst/View/TT.pm
8--
sub process {
my ( $self, $c ) = @_;
my $template = $c-stash-{template}
|| $c-action . $self-config-{TEMPLATE_EXTENSION};
8--
--
siggen.pl: Segmentation Fault
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] On authentication again
Hi Byron,
Actually, it depends largely on what version of the module you are
using.
If you are up to date - the 'Plugin::Authentication' naming is the
proper way to do it (it now follows the configuration naming rules) -
but this is a relatively recent change and the 'authentication' naming
is still referred to as a backup naming if the 'proper' naming is not
found.
Jay
On Mar 6, 2008, at 11:03 AM, Byron Young wrote:
Alex Povolotsky wrote:
I even don't understand what __PACKAGE__-config- I should use -
{'Plugin::Authentication'}, {authentication}
or{authentication}{dbic}.
Docs are unclear.
Alex,
It should be {authentication}. Here's mine:
authentication:
default_realm: database
realms:
database:
credential:
class: Password
password_field: password
password_type: hashed
password_hash_type: SHA-1
store:
class: DBIx::Class
user_class: DB::Users
id_field: username
role_field: name
role_relation: roles
Hope that helps
Byron
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
---
May we not return to those scoundrels of old, the illustrious
founders of superstition and fanaticism, who first took the knife from
the altar to make victims of those who refused to be their disciples.
- Voltaire
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
On 7 Mar 2008, at 19:23, Martin Ellison wrote:
Is there anything attached to Catalyst similar to the CGI.pm
module? That
is, creating the HTML by a series of procedure calls rather than by
instantiating a template?
Or is there some way to link up the existing CGI module?
$c-response-body(ul(li(q{hello}),
li(q{world} ?
Or is it not a good idea?
I couldn't find anything from a search, so excuse me please if this
has been
covered before.
Don't use cgi.pm with catalyst, it's a bad idea which has bitten me
in the arse for reasons I forget. Perhaps you want html::tiny,
although I'd really recommend that you use a proper template engine,
otherwise your code will grow into a horrible monster before you know
it.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
Martin Ellison wrote:
Is there anything attached to Catalyst similar to the CGI.pm module?
That is, creating the HTML by a series of procedure calls rather than
by instantiating a template?
Or is there some way to link up the existing CGI module?
$c-response-body(ul(li(q{hello}), li(q{world} ?
Or is it not a good idea?
I couldn't find anything from a search, so excuse me please if this
has been covered before.
Creating HTML inside the code is the best way to make unreadable,
unmaintainable program with mysterious errors.
Alex.
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
Alex Povolotsky wrote:
Martin Ellison wrote:
Is there anything attached to Catalyst similar to the CGI.pm module?
That is, creating the HTML by a series of procedure calls rather than
by instantiating a template?
Creating HTML inside the code is the best way to make unreadable,
unmaintainable program with mysterious errors.
Also, Kieren Diment wrote:
I'd really recommend that you use a proper template engine,
otherwise your code will grow into a horrible monster before you know it.
It seems to me that these are generalizations. They are often true, but
it is indeed possible to create html inside your code, while keeping
a clean and oo approach.
For example, I designed and maintained for years a web framework where
we allowed something like:
my $table = html::styledtable-new(skin='whatever');
my $chart = html::chart-(type='pie3d', data=[EMAIL PROTECTED]);
my $tree = html::treeview-new(plugin='filesystem', subtree='/mypath');
my $doc = html::document-new(splashscreen=1);
$table-add_row('this', 'that');
$table-add_row($chart);
$table-set_cell_opt(1, 0, colspan=2);
$doc-body-add($table);
$doc-body-add($tree);
We had many kind of html widgets, from simple ones, like 'table',
to complex ones, like 'treeview' or 'multiselect', or charts.
You can still separate (almost) clearly your presentation from your
application logic, and your code is highly maintainable,
at least IMO.
You can also evolve (or change completely) your application presentation, or
even changing the underlying layer to use pre-made templates, without
touching a single line of application code.
--
Cosimo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
On 7 Mar 2008, at 09:03, Alex Povolotsky wrote:
Martin Ellison wrote:
Is there anything attached to Catalyst similar to the CGI.pm
module? That is, creating the HTML by a series of procedure calls
rather than by instantiating a template?
Or is there some way to link up the existing CGI module? $c-
response-body(ul(li(q{hello}), li(q{world} ?
Or is it not a good idea?
I couldn't find anything from a search, so excuse me please if this
has been covered before.
Creating HTML inside the code is the best way to make unreadable,
unmaintainable program with mysterious errors.
Alex.
There's always Template::Declare[0] which lets you do
template simple = sub { html { head {} body { p {'Hello, world wide
web!'} } } };
And keep the html in a sensible place (i.e. not in your controllers).
Never used it but i know Jon Rockway has so perhaps he can comment on
how useful it actually is.
-ash
[0]:
http://search.cpan.org/~sartak/Template-Declare-0.28/lib/Template/Declare.pm___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: CGI.pm and Catalyst?
* Martin Ellison [EMAIL PROTECTED] [2008-03-07 09:30]:
Is there anything attached to Catalyst similar to the CGI.pm
module? That is, creating the HTML by a series of procedure
calls rather than by instantiating a template?
You are looking for Template::Declare.
Or is there some way to link up the existing CGI module?
$c-response-body(ul(li(q{hello}),
li(q{world} ?
No.
Or is it not a good idea?
Yes and no.
It’s a really really REALLY bad idea to mix your display logic
into your controllers, much less your model.
Most people therefore say that you should use a template system
with a minilanguage. But the reason that doing this is good is
that it forces you to write your display logic in a separate file
without easy access to the rest of the code.
In other words, it forces you to properly separate concerns: the
controllers only translate HTTP into model and view calls, and
only the model has business logic, and the view does nothing else
than translate the stash into output.
But the language in which your display logic is written doesn’t
much matter. (In fact, the minilanguages are usually terrible,
like writing shell and awk scripts when you could be writing
Perl.) It’s not an issue to write Perl to generate your output,
as long as you keep that Perl code in separate modules whose
*only* job is to render the stash.
And that’s what Template::Declare makes you do.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] sending a variable to more than one tt2 template
yup, I'm using reusable TT2 widgets via [% PROCESS widget.tt2 %] to render given objects (e.g. row of a given table) so I can call them from several other TT2 pages (and on their own in AJAX calls). root/src/foo/list.tt2 [% FOREACH foo = list_of_foos %] [% PROCESS foo/brief_summary.tt2 entry = foo %] [% END %] root/src/foo/brief_summary.tt2 h1[% entry.title %]/h1 p[% entry.content %]/p If you want to display the same widgets on the page for bar (which also have foos) root/src/bar/list.tt2 [% FOREACH foo = bar.get_foos %] [% PROCESS foo/brief_summary.tt2 entry = foo %] [% END %] FWIW I can then serve these widgets on their own in simple AJAX calls by changing the wrapper applied in root/lib/site/wrapper (e.g. based on CGI param ?format=AJAX). Sending HTML snippets via AJAX is less efficient than sending JSON and client-side rendering with javascript (Jemplate), but when the components are small and simple, I've found this useful. Ian On Fri, Mar 7, 2008 at 12:43 AM, Byron Young [EMAIL PROTECTED] wrote: You can call another template from within the template you specified in the stash, and pass the stash parameters along. I don't use TT, but I think PROCESS is how you call other templates. HTH Byron -- *From:* Emily Heureux [mailto:[EMAIL PROTECTED] *Sent:* Thursday, March 06, 2008 2:36 PM *To:* 'The elegant MVC web framework' *Subject:* [Catalyst] sending a variable to more than one tt2 template Hi, I have a variable in a Controller method sent to the stash for a particular tt file. What if I want that same variable to be available to another tt file? I assume I cannot set two templates in one method. Thanks, Emily ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] CGI.pm and Catalyst?
On Fri, 07 Mar 2008 10:24:45 +0100, Cosimo Streppone [EMAIL PROTECTED]
said:
For example, I designed and maintained for years a web framework where
we allowed something like:
$table-add_row('this', 'that');
$table-add_row($chart);
$table-set_cell_opt(1, 0, colspan=2);
$doc-body-add($table);
$doc-body-add($tree);
We had many kind of html widgets, from simple ones, like 'table',
to complex ones, like 'treeview' or 'multiselect', or charts.
Yes. I did that too. It was keen in 1997, and the reason I was using
those idioms was because e.g. HTML::Mason didn't exist then. (*koff*
and in 1998 I was still certain enough of my own invincibility I
wouldn't look around for the help) and now I have a pain in the butt.
You can still separate (almost) clearly your presentation from your
application logic, and your code is highly maintainable, at least
IMO.
It's only maintainable for you. And once you've actually -maintained-
it for 7 years, you'll find yourself hesitant to assert that much.
Code senescence is real.
Seriously. Every iota of infrastructure you can punt to some larger
community's set of rules and conventions is a win.
- Allen S. Rout
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] sending a variable to more than one tt2 template
* On Thu, Mar 06 2008, Eden Cardim wrote:
On Thu, Mar 6, 2008 at 7:36 PM, Emily Heureux [EMAIL PROTECTED] wrote:
Hi, I have a variable in a Controller method sent to the stash for a
particular tt file. What if I want that same variable to be available to
another tt file? I assume I cannot set two templates in one method.
yeah you can:
my $vars = { foo = 'bar' };
my $output1 = $c-view('TT')-render($c, 'template1.tt', $vars);
my $output2 = $c-view('TT')-render($c, 'template2.tt', $vars);
The problem with this is and then what? I think the original poster
really just wants to [% INCLUDE %] things.
Regards,
Jonathan Rockway
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] The home page, the wiki and the mailing list
On 07/03/2008, Ali M. [EMAIL PROTECTED] wrote: I just want to draw the attention or to ask, Why is the wiki so poorly maintained, the list of sites and projects using catalyst is really umimpressive, are those really all the project using catalyst? The thing is, from the traffic I see on this mailing list, I really doubt it, and I really wish that these sites and project listed on the wiki are not representative. I even visited the NetHorus link from this wiki and beside the fact that this seems like a very small one man show project, the author converged to using RoR because in his own words Catalyst and DBIx::Class is proving too difficult for me to code, resulting in a lack of progress and the danger of de-motivation Yes, thats not brilliant advertising is it :-) Is catalyst being implemented in more serious place, can someone post better links and stories, even the ones on the front page sound ...well ...i wont say not to sound mean ... but totaly dope!!! ... really. And who are these people quoted, I googled one or two of them, they are not major contributors to big FOSS project and they dont work for large enterprise, why are they quoted!! Catalyst is a Perl framework, and within the perl community those people are well known. If you are trying to suggest that they should find some celebrity hackers from outside the community to give endorsements then you might have a point, but you certainly could have a more diplomatic way to express it. And frankly within the Perl community the merits of a recommendation from someone working for large enterprise will be judged almost entirely on who they are and not who they work for. Yves -- perl -Mre=debug -e /just|another|perl|hacker/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
* On Fri, Mar 07 2008, Matthias Zeichmann wrote:
On Thu, Mar 6, 2008 at 11:11 PM, David Jack Wange Olrik [EMAIL PROTECTED]
wrote:
Here is a small patch for Catalyst::View::Mason.
When setting $c-stash-{template}, template_extension was not added
to the component path. In my opinion this should always be added, so
one can easily change the view without having to provide extra logic
that sets the template extension according to the current view.
C:V:TT behaves exactly the same way [0] and i suspect its not the only
view that does
my $template = $c-stash-{template}
|| $c-action . $self-config-{TEMPLATE_EXTENSION};
This is really the only thing that makes sense. To do what David wanted
would have to use a heuristic to determine whether $c-stash-{template}
is the actual template name, or the template name minus the extension.
By definition, that's never going to work.
Fortunately, it's easy to implement the behavior in your own app:
package MyApp::View::Whatever;
use base qw/Catalyst::Component::ACCEPT_CONTEXT Catalyst::View::Whatever/;
sub set_template_name {
my ($self, $name) = @_;
my $extension = $self-{TEMPLATE_EXTENSION};
given($self-context-request-path){
when(/OH HAI/){
$extension = 'something-else';
}
}
return $self-context-stash-{template} = $name.$extension;
}
Then you can do this:
sub action :Path('OH_HAI') {
my ($self, $c) = @_;
...
$c-view('Whatever')-set_template_name('name-without-extension');
}
Then $c-stash-{template} will be 'name-without-extension.something-else'.
Regards,
Jonathan Rockway
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] The home page, the wiki and the mailing list
* On Fri, Mar 07 2008, Ali M. wrote: I just want to draw the attention or to ask, Why is the wiki so poorly maintained, the list of sites and projects using catalyst is really umimpressive, are those really all the project using catalyst? The thing is, from the traffic I see on this mailing list, I really doubt it, and I really wish that these sites and project listed on the wiki are not representative. I don't know how to break this to you, but 99.9% of web apps are not Flickr and Reddit. They're internal applications at companies you've never heard of. This is the area where Perl has a lot of penetration and is where people use Catalyst. I would say that honestly Rails and the J2EE frameworks are the same way. There's the occasional hosted service that you've heard of, then there are thousands of users you haven't heard of. This seems to upset you, but it's the reality of the world. As for the wiki, work is under way to improve it. Perhaps you can help. I even visited the NetHorus link from this wiki and beside the fact that this seems like a very small one man show project, the author converged to using RoR because in his own words Catalyst and DBIx::Class is proving too difficult for me to code, resulting in a lack of progress and the danger of de-motivation Yeah, I would be a really good furniture maker if only I had a better saw. Blaming one's tools for one's failures is the oldest excuse in the book. I use Catalyst every day and can write expressive, maintainable apps in no time. So Catalyst and DBIx::Class probably aren't the issue there. There's More Than One Way To Do It. Not everyone thinks the same way... not every language or framework is for every person. Who cares what other people use, anyway? Is catalyst being implemented in more serious place, can someone post better links and stories, even the ones on the front page sound ...well ...i wont say not to sound mean ... but totaly dope!!! ... really. And who are these people quoted, I googled one or two of them, they are not major contributors to big FOSS project and they dont work for large enterprise, why are they quoted!! This is ignorant. Regards, Jonathan Rockway ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] The home page, the wiki and the mailing list
* On Fri, Mar 07 2008, demerphq wrote: Catalyst is a Perl framework, and within the perl community those people are well known. If you are trying to suggest that they should find some celebrity hackers from outside the community to give endorsements then you might have a point, but you certainly could have a more diplomatic way to express it. And frankly within the Perl community the merits of a recommendation from someone working for large enterprise will be judged almost entirely on who they are and not who they work for. Exactly, the Perl community and the Rails community are different in a number of ways. Most Perl hackers don't feel the need to constantly remind other people of how awesome (they think) they are. The Rails community is all about constantly talking about themselves. The sad reality is that people like to be told what to think rather than deciding for themselves. Hence the popularity of Rails. I think most Perl hackers share my* attitude of shut the fuck up and write some code. That's why we have 15,000 instantly installable libraries whereas the other language communities have at best 10% of that (along with a lot of cut-n-paste this untested monkey patch from my blog!111). There is a finite amount of time in the day, you can spend it programming, or you can spend it inflating your ego. (Or taking flamebait on mailing lists ;) Regards, Jonathan Rockway [*] Actually, I have to credit one of Jesse Vincent's shirts for this saying. :) ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: CGI.pm and Catalyst?
At 11:39 AM +0100 3/7/08, Aristotle Pagaltzis wrote: It's a really really REALLY bad idea to mix your display logic into your controllers, much less your model. Most people therefore say that you should use a template system with a minilanguage. But the reason that doing this is good is that it forces you to write your display logic in a separate file without easy access to the rest of the code. In other words, it forces you to properly separate concerns: the controllers only translate HTTP into model and view calls, and only the model has business logic, and the view does nothing else than translate the stash into output. But the language in which your display logic is written doesn't much matter. (In fact, the minilanguages are usually terrible, like writing shell and awk scripts when you could be writing Perl.) It's not an issue to write Perl to generate your output, as long as you keep that Perl code in separate modules whose *only* job is to render the stash. Speaking for myself (who is now on the cusp of starting to use Catalyst for the first time, and is now reading the book to learn it), I have for the last several years been writing my new web applications with very few external dependencies, with said applications using DBI and SQL directly, and producing their own HTML, both without help from a generic templating wrapper or generic DBI wrapper. That said, the applications were well structured and highly resembled the MVP practices that Catalyst is built on. Practically all of the code was in modules, except for a thin wrapper which invoked the otherwise controller main in an eval block so to trap and report otherwise unhandled compile or runtime exceptions. Its controller logic and HTML-making view code were in separate per-application modules; the controller examined user input, determined what page to display (using the path_info mainly) and gathered data to use; the view was invoked almost just before the controller exited, and rendered the page the controller told it to do. Utility modules wrapped DBI, and wrapped the web client input/output (including 301s etc), uri generation, and managed sessions (the last 3 with CGI.pm and CGI::Session and File::VirtualPath) and the stash. For configuration, the controller starts by do-ing a Perl file that simply contained an anonymous Perl hash declaration, so Perl itself is the config file parser. Many more similarities that I won't detail here. Suffice it to say that as I've been reading the book, I very much understand the reasoning of how Catalyst-using applications, and the framework, are structured, as its essentially the same as what I was doing, but that with Catalyst a greater part of the codebase will be generified and higher quality. The first main benefit I anticipate getting from switching to Catalyst is improved server portability, and in particular the ability to develop and test an app without running it on the actual Apache server. Getting back to the topic at hand, I think it works very well for a view to simply be written in Perl, and in many cases it seemed to work better than the templating approach I had seen in PHP applications. That said, as per the examples in the book, I intend to try using a non-Perl template approach (TT or something) at the same time as adopting Catalyst, and see how well that works out. At the same time, I'll also move to using an alternate database access method than direct DBI+SQL, which would be my first use of Muldis DB. Note that many of my database queries are relatively complicated and would have required writing a lot of SQL anyway were I to use any other DBI wrappers / ORMs, afaik. -- Darren Duncan ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On 07/03/2008, at 19.26, Jonathan Rockway wrote:
To do what David wanted
would have to use a heuristic to determine whether $c-stash-
{template}
is the actual template name, or the template name minus the
extension. By definition, that's never going to work.
No need to do any heuristics, you could just decide that you always
supply the template without extention and let the View module add
it. (But this change will indeed break all existing apps unless some
heuristics are applied, and that is not sane).
--
Best regards,
David Jack Olrik [EMAIL PROTECTED] http://david.olrik.dk
GnuPG fingerprint C290 0A4A 0CCC CBA8 2B37 E18D 01D2 F6EF 2E61 9894
[The first rule of Perl club is You do not talk about Perl club]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On Fri, Mar 07, 2008 at 10:10:25PM +0100, David Jack Wange Olrik wrote:
On 07/03/2008, at 19.26, Jonathan Rockway wrote:
To do what David wanted would have to use a heuristic to determine
whether $c-stash-{template} is the actual template name, or the
template name minus the extension. By definition, that's never going
to work.
No need to do any heuristics, you could just decide that you always
supply the template without extention and let the View module add it.
(But this change will indeed break all existing apps unless some
heuristics are applied, and that is not sane).
I want to keep the default behaviour to not break existing code and to
be consistent with most other catalyst views.
However I'll think about implementing a new configuration option that,
when enabled, will always append template_extension.
-Flo
--
BOFH excuse #189:
SCSI's too wide.
signature.asc
Description: Digital signature
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On 07/03/2008, at 22.22, Florian Ragwitz wrote: I want to keep the default behaviour to not break existing code and to be consistent with most other catalyst views. However I'll think about implementing a new configuration option that, when enabled, will always append template_extension. Great, then I hope the other View authors will consider being consistent with you ;) -- Best regards, David Jack Olrik [EMAIL PROTECTED] http://david.olrik.dk GnuPG fingerprint C290 0A4A 0CCC CBA8 2B37 E18D 01D2 F6EF 2E61 9894 [The first rule of Perl club is You do not talk about Perl club] ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
David Jack Wange Olrik wrote: On 07/03/2008, at 22.22, Florian Ragwitz wrote: I want to keep the default behaviour to not break existing code and to be consistent with most other catalyst views. However I'll think about implementing a new configuration option that, when enabled, will always append template_extension. Great, then I hope the other View authors will consider being consistent with you ;) Ideally, this should be, and was started to be extraced out into a based class... http://search.cpan.org/~jrockway/Catalyst-View-Templated-0.02/lib/Catalyst/View/Templated.pm signature.asc Description: OpenPGP digital signature ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On Mar 07 2008, Jonathan Rockway wrote:
* On Fri, Mar 07 2008, Matthias Zeichmann wrote:
C:V:TT behaves exactly the same way [0] and i suspect its not the only
view that does
my $template = $c-stash-{template}
|| $c-action . $self-config-{TEMPLATE_EXTENSION};
This is really the only thing that makes sense.
It would make more sense if it was a configuration option of the
template engine itself. Then you wouldn't need the extension when
putting the template in the stash and things like
[% INCLUDE path/to/my/template.tt2 %]
wouldn't need to specify the ugly extension either.
--
Rick Delaney
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
* On Fri, Mar 07 2008, Christopher H. Laco wrote:
David Jack Wange Olrik wrote:
On 07/03/2008, at 22.22, Florian Ragwitz wrote:
I want to keep the default behaviour to not break existing code and
to be consistent with most other catalyst views.
However I'll think about implementing a new configuration option
that, when enabled, will always append template_extension.
Great, then I hope the other View authors will consider being
consistent with you ;)
Ideally, this should be, and was started to be extraced out into a
based class...
http://search.cpan.org/~jrockway/Catalyst-View-Templated-0.02/lib/Catalyst/View/Templated.pm
This was a failure, and we I don't think we can fix the various Views on
CPAN until 5.8.
What we really needed to have done was to implement views as a
composition of a bunch of roles.
Templated tried to factor out a minimum set of functionality from the
template engine-based views. But it wasn't minimal enough. Every
templating system has its own odd quirks; TT has a ton of extra config,
mason does weird things with variables, Template::Declare uses modules
instead of filenames, clearsilver can't call back into the application,
etc.
So what we need to do is say, by default Views are new and render (*).
Then we can apply a role to create process from render. Then we can
add a Templated role which adds InstancePerContext and
$view-set_template.
Then you can write your own roles to do things like guess the action
name and extension and set that to the template name. Or whatever, it's
a simple matter of:
package GuessExtension;
use Moose::Role;
around set_template = sub {
my ($super, $self, $template) = @_;
do your munging;
return $super-($self, $munged_template);
}
Because roles are sane, you can introspect the final composition and
pragmatically learn about how a certain view works. This is important
for things like View::Email, which currently just makes random
assumptions about the templating backend. Random assumptions are
fragile.
Anyway, it's possible to prototype this now... but it's not really
possible to replace all the Views on CPAN with this. (For one thing,
NEXT and Moose play together terribly.) Anyone interested in this
should go ahead and implement it, though.
(*) This is wonderfully non-specific-to-Catalyst, btw. See my
Providers in App::TemplateServer. Apply a role that adds a process
method and you can use 'em in Catalyst. That's reuse.
Regards,
Jonathan Rockway
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] The home page, the wiki and the mailing list
Do you really think people are going to list their projects for their internal tools and portals on a public website? Yes the wiki is way out of date and poorly maintained but guess what the one we have here at work is also poorly maintained. That's just the nature of the wiki and I have complained about it before but until I contribute I can't really complain any further. DBIC is confusing if you haven't used ORM or similar techniques. I know I myself have faced a lot of issues with DBIC not being clear or being too confusing. But when you sit down and think about writing your own ORM you quickly realize the beauty of having something like that. But even if DBIC is too confusing you can always just go back to basic DBD and write your own logic for find_or_create or insert_or_update. And I don't think the focus should be on ...post better links and stories... for marketing reasons. If anything we just need to document better probably just use better examples in the documentation. I personally don't care about the hype factor of catalyst but I do care about the features and control it provides. But googling people and saying they shouldn't be quoted is kinda silly in my opinion. That's like saying who are you to post a message like this on this mailing list your not qualified to criticize the marketing tactics of Catalyst. Thanks, -- Ali Mesdaq (CISSP, GIAC-GREM) Security Researcher II Websense Security Labs http://www.WebsenseSecurityLabs.com -- -Original Message- From: Ali M. [mailto:[EMAIL PROTECTED] Sent: Friday, March 07, 2008 9:38 AM To: catalyst@lists.scsys.co.uk Subject: [Catalyst] The home page, the wiki and the mailing list I just want to draw the attention or to ask, Why is the wiki so poorly maintained, the list of sites and projects using catalyst is really umimpressive, are those really all the project using catalyst? The thing is, from the traffic I see on this mailing list, I really doubt it, and I really wish that these sites and project listed on the wiki are not representative. I even visited the NetHorus link from this wiki and beside the fact that this seems like a very small one man show project, the author converged to using RoR because in his own words Catalyst and DBIx::Class is proving too difficult for me to code, resulting in a lack of progress and the danger of de-motivation Is catalyst being implemented in more serious place, can someone post better links and stories, even the ones on the front page sound ...well ...i wont say not to sound mean ... but totaly dope!!! ... really. And who are these people quoted, I googled one or two of them, they are not major contributors to big FOSS project and they dont work for large enterprise, why are they quoted!! Best regards Ali ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ Protected by Websense Messaging Security -- www.websense.com ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] $c-req-body oddity
Ian Docherty wrote:
Jonathan Rockway wrote:
* Ian Docherty [EMAIL PROTECTED] writes:
I am sending a POST to a Catalyst app and according to the documention
I expected the request body to
contain the data I sent. Instead it holds a filename in the tmp
directory which contains the document. Is
this an expected behaviour?
e.g. in my test script
my $request = HTTP::Request-new(POST = 'http://linux:3000/svc/to/1001');
$request-content_type('text/text');
$request-content('THIS IS THE STRING');
my $response = $ua-request($request);
Basically, HTTP::Body assumes you are sending your content as
application/octet-stream, since it's not multipart/form-data or
application/x-www-form-urlencoded (the two cases that it treats
specially).
Since file uploads are application/octet-stream, we put the data into
a file. Maybe it would be better to keep it in memory unless
Content-Length exceeds a certain length, but the current behavior is
consistent and reliable, so I don't see why we should change it. It's
really not that confusing.
Finally, the string that you see in $c-req-body is actually an
IO::File object, so you can easily suck the file in if the need
arises.
Regards,
Jonathan Rockway
Thank you for that explanation. In the light of this does the
following seem reasonable.
I am creating a web service (xml over http) so the POST method would
present an xml
document to the controller using content-type text/xml and the
controller would read it
and parse it.
Regards
Ian
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Hi Ian,
I would like to implement ajax as you described above. In you controller
method, how do you get the XML post file to parse through it? I am
trying to read from STDIN and then use LibXML to parse through the XML.
Is this the right approach?
Thanks,
Jennifer
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Serving static files without Sessions involved
With my current configuration, when serving static files (like images
for my site layout etc.), every request will load session data.
(an older post at:
http://www.gossamer-threads.com/lists/catalyst/users/1437 also mentioned
this)
Is it possible to AVOID sessions for files from a specific directory?
My configuration is:
use Catalyst qw/
ConfigLoader
Authentication
Authentication::Store::DBIC
Authentication::Credential::Password
Authorization::Roles
Authorization::ACL
Session
Session::Store::DBIC
Session::State::Cookie
Static::Simple
/;
__PACKAGE__-config(session = {dbic_class = DB::Session,
expires= 3600,
flash_to_stash = 1,
}
);
__PACKAGE__-config-{static}-{dirs} = [
'static',
qr/^(images|css)/,
];
Thanks in advance :-)
Matt
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Patch for Catalyst::View::Mason
On Mar 07 2008, Jonathan Rockway wrote:
* On Fri, Mar 07 2008, Rick Delaney wrote:
It would make more sense if it was a configuration option of the
template engine itself. Then you wouldn't need the extension when
putting the template in the stash and things like
[% INCLUDE path/to/my/template.tt2 %]
wouldn't need to specify the ugly extension either.
You can do all of these things in your own app. Why do you feel the
need to inflict this on other people? Adding a bunch of weird
configuration options seems wasteful when you can just write a line or
two of code to customize things exactly as you need.
The reason you have a subclass of a View in your application is so you
can do whatever you want.
I think maybe you didn't understand what I wrote. I'm not trying to
inflict anything on anyone, except maybe the maintainers of Template
Toolkit. If I could do something like
my $t = Template-new({ SEARCH_EXTENSION = '.tt2' });
then I could write
$t-process(mytemplate); # finds mytemplate.tt2
and within templates
[% INCLUDE othertemplate %]
which would find 'othertemplate.tt2'.
I think the way Catalyst::View::TT is handling extensions is fine. But
I think the functionality of extension handling belongs in TT itself and
then Catalyst wouldn't need to deal with it at all. The same goes for
any other Template engine, too.
Or maybe you did understand what I wrote but believe there is such an
option that I can specify in my View subclass. If there is, I would
very much like to know what it is.
--
Rick Delaney
[EMAIL PROTECTED]
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
