Re: [Catalyst] Encoding UTF8 ?
On Mon, Mar 28, 2011 at 7:50 PM, John M. Dlugosz wxju46g...@snkmail.comwrote: I don't understand why Catalyst::Plugin::Unicode::Encoding is necessary, based on the writup: it takes request arguments and converts them from whatever they came in to Perl's native encoding, and likewise for the response. But Perl is using UTF-8 in its strings anyway. So what's it have to do with the engine error I noticed before? The point is that if they are not marked as UTF-8 then they are treated as bytes not characters. In fact you should never think about the internal storage of strings - it is not part of the API - it can be changed. You always need to decode external data if you want to treat it as strings and not byte streams. http://perldoc.perl.org/perlunitut.html has all the this introductory info. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Simple literal Model
On Sat, Feb 26, 2011 at 6:22 AM, John M. Dlugosz wxju46g...@snkmail.comwrote: On 2/25/2011 9:30 AM, Ashley Pond V apv-at-sedition.com |Catalyst/Allow to home| wrote: What t0m suggested is perfectly fine but if you want to mimic the DBIC API with a different engine, this example does that (superficially and as a tutorial only): http://sedition.com/a/2739 Log file model–Apache access log. The reason that example makes sense is because the underlying model/data is similar: searchable, sortable rows. If you're trying to shoehorn in something dissimilar, you might be making a mistake. -Ashley I'm not sure to what extent it is wise or correct. The whole point of models is that it abstracts the model and I can change where the data comes from later, right? So don't they all have an underlying abstract interface regardless of how they are sourced? The only abstraction Catalyst::Model provides is initialization. Personally I don't like this approach but I cannot imagine what common abstraction it could provide for so diverse models. Some Catalyst::Model::xxx classes do provide some additional functionality - like Catalyst::Model::DBIC which adds the possibility to address the resutlsets with a shortcut - but it's their own unique additions. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] FormHandler -- pro or con?
On Wed, Dec 15, 2010 at 7:49 AM, Toby Corkindale t...@dryft.net wrote:
On 13 December 2010 21:07, Octavian Rasnita orasn...@gmail.com wrote:
From: Toby Corkindale t...@dryft.net
...
True, but FormFu can also use Config::General code which is much clearer (or
other config formats accepted by Config::Any).
It would be OK if H::FH would allow creating custom elements and validators,
filters... using Moose, but only generic elements, not related with any
form, and then allow us to use configuration files for using those elements
and constraints. It is not nice at all to need writing Perl code using Moose
for just creating an HTML form, but each one with his preferences. :-)
But you can do that if you want..
If you're just doing simple stuff, like name-of-field + type-of-field,
then you could do something like this:
my $form = HTML::FormHandler-new(
item = $c-model('DB::User')-find($id),
field_list = YAML::Load(form.yaml)
);
There is MooseX::SimpleConfig that is used by Catalyst itself and fits
here very well. With some Moose coercions this is enough to build any
Moose object and it let's you use any config file format that is
supported by Config::Any.
If only the underlying MooseX::ConfigFromFile was more actively maintained.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] FormHandler -- pro or con?
On Thu, Dec 9, 2010 at 2:44 AM, Toby Corkindale t...@dryft.net wrote: (I do have some code that programmatically generates the form config based on the object you're editting, although I use a precreated base for it) Well - there is http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/FormHandler/Generator/DBIC.pm -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] FormHandler -- pro or con?
On Tue, Nov 30, 2010 at 4:55 PM, Sir Robert Burbridge rburb...@cisco.com wrote: To mitigate the awkwardness I felt about the API, use a pure-module approach (every form is a separate package/module, that inherits from a base form that's all rigged up the way I want it, along with a few really helpful roles that I drop in on forms here and there to do common stuff. To be fair - this is the way Gerda always used it. The actions attribute with the possibility of having different functionality per form (and field) *instance* were all my additions (copied by they way from Data::FormValidator and FormFu). I am starting to regret coding that - it seems that it complicates the machinery too much. Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Catalyst with HTML::FormHandler
Another question is MyApp/UserInterface/Form/User.pm in one of the directories mentioned in the error message - that is in C:/strawberry/perl/site/lib, C:/strawberry/perl/vendor/lib, C:/strawberry/perl/lib, or .? Z. On Sat, Nov 6, 2010 at 2:50 PM, Steve st...@matsch.com wrote: Sounds like you've got the correct 'use' line, what about the package declaration line in your form module? It should read 'package MyApp::UserInterface::Form::User;' On 11/5/2010 3:11 PM, Blaine Everingham wrote: Sorry the error message is Error: Can't locate MyApp/UserInterface/Form/User.pm in @INC (@INC contains: C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib C:/strawberry/perl/lib .) Resource: User.pm Path: /MyApp-Software/lib/MyApp/UserInterface/Controller/Admin Location: line 5 Line 5 of /MyApp-Software/lib/MyApp/UserInterface/Controller/Admin/User.pm is: use MyApp::UserInterface::Form::User; Date: Fri, 5 Nov 2010 14:40:37 -0400 From: st...@matsch.com To: catalyst@lists.scsys.co.uk Subject: Re: [Catalyst] Catalyst with HTML::FormHandler The actual error message would help... On 11/5/2010 2:33 PM, Blaine Everingham wrote: I'm new to Catalyst and and trying to build a simple form. In the Catalyst controller MyApp/UserInterface/Controller/Admin/Users.pm I've added an 'use MyApp::UserInterface::Form::User', however it can not find this file. Meaning that it's not in the INC path. Obviously I could push this directory on to the INC stack, but none of the examples that I've seen have had to do this. What is the proper way to go about this? Below is an example of the directory structure. MyApp/UserInterface/Controller MyApp/UserInterface/Controller/Admin MyApp/UserInterface/Controller/Admin/Users.pm MyApp/UserInterface/Form MyApp/UserInterface/Form/User.pm MyApp/UserInterface/Model MyApp/UserInterface/Schema MyApp/UserInterface/View ___ 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/ ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 11:59 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
* Zbigniew Lukasiak zzb...@gmail.com [2010-04-26 12:25]:
This is a fine advice - but unfortunately the -param method
call suffers from additional problem - which is described in
much detail in the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).
Yeah, but the -params hash has the converse problem: if you
write
$c-model-insert_person( name = $c-req-params-{'name'} )
then you may be surprised to find out there are people with name
like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
case of data corruption. Worse is if you legitimately expect
a parameter to have one or more values, eg. a pile of checkboxes.
Then you have to constantly check whether you’re getting a scalar
or an array reference.
So either you use the legacy method and have to protect against
getting more values than you wanted, or you use the suggested
method and have to protect against getting fewer values than you
expect in the general case.
I briefly tried to write something to stick Hash::MultiValue into
Catalyst to end the madness, but doing it properly would require
a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
approach that made deep integration of H::MV impossible (with
properly preserved k/v pair order).
Could have written a Request role… but that seemed unsatisfying.
I wonder whether it would be possible to rip out the respective
bits from Cat and use just H::MV, and leave the current stuff to
a compat plugin or something like that…
Not a very concrete answer - but I remember that Miyagawa talked about
fixing that in Plack::Request (and I am not sure but I think it also
involved H::MV) - so there might be some occasion for reuse :)
Cheers,
Z.
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
On Mon, Apr 26, 2010 at 09:36, Dermot paik...@googlemail.com wrote:
On 21 April 2010 18:01, J. Shirley jshir...@gmail.com wrote:
__END__
Benchmark: running all, low, sep for at least 1 CPU seconds...
all: 1 wallclock secs ( 1.11 usr + 0.00 sys = 1.11 CPU) @
2917341.44/s (n=3238249)
low: 0 wallclock secs ( 1.27 usr + 0.04 sys = 1.31 CPU) @
12930179.39/s (n=16938535)
sep: 1 wallclock secs ( 1.21 usr + 0.01 sys = 1.22 CPU) @
3223081.15/s (n=3932159)
Subroutines suck, lets all use hashrefs.
Now that it's quietened down, I can ask a question. Does this I mean
it's preferable to use
$c-req-{parameters}-{foo}
rather than
$c-req-param('foo')
Obviously I'd rather use the faster method but if I'm breaking the
encapsulation in some ways that's going to bite me later, I'd steer
clear.
Obviously.
Unless you're doing method calls in a tight loop somewhere in your
code you *shouldn't care about this*. Now I've written code that
actually *did* suffer from method call overhead but since you're just
casually asking it's very unlikely that you're doing the same.
Don't sprinkle premature optimizations around your codebase just
because someone produced a benchmark showing one is faster than the
other. You should be doing *profiling* of your entire program, not
micro-optimizing something that's likely 0.0001% of its total runtime.
This is a fine advice - but unfortunately the -param method call
suffers from additional problem - which is described in much detail in
the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Alternatives to Catalyst ?
On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
benvanstave...@gmail.com wrote:
Because if you are working with, say, 10 people on a team, and you will have
everyone merrily doing direct hash accesses, sooner or later, someone's
going to fuck it up and something will break in a spectacular fashion.
I take your point even though I am not in a team.
Even if you're not, direct hash accessing is basically akin to juggling
grenades. It might go right for a long time, but eventually the pin's going
to come out and there will be a very messy BLAM.
Even if it is code you just write for yourself, still doesn't hurt to make
sure you avoid the BLAM bit :)
If using -params-{name} (i.e. the direct hash approach) is like
juggling grenades - then what is like using the -param( 'name' ) way
of doing it?
I am asking this because your grenades analogy gives the impression
that you you are against doing direct hash access for every price -
but I think the general advice is that in this particular case using
the -param( 'name' ) is worse than using the direct hash access.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Alternatives to Catalyst ?
On Fri, Apr 23, 2010 at 12:36 PM, Oleg Pronin syber@gmail.com wrote: Can you hear the difference between 3mln/s and 24k/s ? I do not say that using hashes are good. But i'm sure that developers MUST NOT use super-slow frameworks like Moose-shit (which tries to emulate perl6 on perl5: what for???) only to get good maintened code. That's the own problems of developers how do they organize internals. Why users of Catalyst must suffer from that ? Or you wanna tell that good maintened code must have a price of 100x slow down ??? that an absurdity can't you see it? Well - this is not that absurd as you seem to think - the meaning of that 100x slow down depends much on where it happens. If it happens in a tight loop - then it can be harmful - if it happens on some one-off operation then it mostly does not really matter. It is not that using Moose slows your application 100 times - it can slow some parts of it - but how that relates to the overall performance - this depends on many things. I think that most of Catalyst users found that it's port to the Moose framework did not slow their applications much - but there sure there will be some cases that this change was introducing some problems. Unfortunately it's always about tradeoffs. But if you have a real-life example where the port caused a 100 times slow down - then I am sure the developers here would like to hear about the details. Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] How to de-serialize json?
On Sun, Jan 24, 2010 at 8:01 AM, Bill Moseley mose...@hank.org wrote: On Sat, Jan 23, 2010 at 7:20 PM, Hans Dieter Pearcey hdp.perl.catalyst.us...@weftsoar.net wrote: As far as I can tell, you missed the point of my message, which makes me wonder if I've missed the point of yours. Are you talking about a set of conventions you'd like to be able to build for your own use on top of HTTP::Body, or a set of conventions that you expect everyone will want and so should be built into HTTP::Body, or something else entirely? I thought you were saying that the request might not be a normal form posting, and I was saying only that HTTP::Body can support that, too. I was not suggesting everyone should use one method over another. HTTP::Body seems (to me) like the natural place to deserialize. Yet, the REST modules I cited use an action class to deserialize. Thus, I was wondering if there was a specific reasons for that approach that I had not understood. That's really all. I cannot claim to understand all the concerns here - but to add my two cents: it sounds like this deserialisation thing is not something specific to Catalyst and now with other frameworks and libraries gaining grounds - it would make sense to put that logic into something reusable across them. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Basic CRUD example failing
On Wed, Oct 28, 2009 at 6:07 AM, Jason Dixon ja...@dixongroup.net wrote:
Hi all,
Learning Catalyst here. Following along with the manual and I ran into
a weird issue. I assume the documentation is right so it must be
something with my installation (Catalyst packages on OpenBSD 4.6).
Following along with the SIMPLE DELETE FEATURE example, I made changes
to root/src/books/list.tt2. Alas, the uri is not rendering properly.
a href=[% c.uri_for(c.controller.action_for('delete'), [book.id])
%]Delete/a
I may have not updated my view knowledge - but I would write that as:
a href=[% c.uri_for(c.controller.action_for('delete'), book.id) %]Delete/a
Why did you use the square brackets around 'book.id'?
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] How to handle development vs production, required vs recommended module dependencies
On Mon, Aug 31, 2009 at 3:44 AM, Daniel Austindaniel.aus...@gmail.com wrote: Hello I'm curious how other Catalyst developers are managing their CPAN module dependencies. I see our current application as having four types of module dependencies: * Modules that are required for the application to run *at all*. These are specified using requires statements in Makefile.PL (and also, the all from statement which points at the main Catalyst application class). * Modules that are not required, but if present, add additional functionality. These are specified using recommends statements in the Makefile.PL. I am against additional functionalities and recommended dependencies. If this additional functionality is really useful - then you can expect someone will write something depending on it and at that point the whole automatic install idea breaks down. See also: http://www.mail-archive.com/module-auth...@perl.org/msg07485.html Cheers, -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] RFC: no make install on catalyst apps
On Sun, Aug 2, 2009 at 1:32 PM, John Napiorkowskijjn1...@yahoo.com wrote: - Original Message From: Tomas Doran bobtf...@bobtfish.net To: The elegant MVC web framework catalyst@lists.scsys.co.uk Sent: Tuesday, July 28, 2009 8:28:08 PM Subject: Re: [Catalyst] RFC: no make install on catalyst apps On 28 Jul 2009, at 14:14, Marcus Ramberg wrote: I see catalyst apps being complete CPAN packages as a real advantage. Taking away the make install option seems very limiting +1 I would very much support moving to a 'real' sharedir for templates / config etc, rather than the current hacks (given appropriate back compat) however. Cheers t0m I am vaguely planning something roughly based on the XDG directory specification: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html for localizing configs and related. Something like this would make is much easier to have multiply versions of the same catalyst application running. Like, if I had MojoMojo installed and wanted to run two seperate wikis with different configs. You can do that now but requires playing with %ENV and copying some configs around. In my mind the way this would work is that you'd have the config and other share data stuff as templates inside your dist, and than at install time we'd copy to all the correct places. Then we'd merge configurations in the following order. $cpan/config/myapp.conf $home/.config/myapp.conf /etc/myapp.conf Where $cpan is where cpan stuff is installed globally, $home is your home directory. Maybe we could move around the order a bit, but this way we'd set all the 'no moving parts here' config in the $cpan (stuff like when the app was installed, some paths). Then whatever user started the app, we'd read from her local configuration (we'd probably need some sort of 'first time' script if it's not present, which would copy from a template and prompt for required values) and last we'd merge in any globally set up stuff. Maybe with more people using local lib this is not as important, although I see local lib most as a developer tool or as a workaround for people that are on shared servers. That's just for config, but could work as well for search paths for templates So config is supposed to move into a 'config' subdir (and later be merged with the configs in home and etc)? Am I reading that right? Maybe we could call it 'etc' instead of config? And now templates - can we also move them into a 'templates' subdir? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OpenID authentication and LWPx-ParanoidAgent
On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote: On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote: Brad just uploaded the module to CPAN. Unfortunately it still fails everywhere: http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06 I've analyzed the failure and posted a patch at: https://rt.cpan.org/Ticket/Display.html?id=48345 Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OpenID authentication and LWPx-ParanoidAgent
Sorry - OK - so this was not the really the problem, my analysis below
was wrong. But still the tests of
Catalyst-Authentication-Credential-OpenID fail and I would like
someone to confirm that.
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
make test 2 errors
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'inc', 'blib/lib', 'blib/arch') t/00.load.t
t/live_app.t t/pod-coverage.t t/pod.t
t/00.load.t ... ok
t/live_app.t .. Dubious, test returned 5 (wstat 1280, 0x500)
Failed 5/17 subtests
t/pod-coverage.t .. ok
t/pod.t ... ok
Test Summary Report
---
t/live_app.t(Wstat: 1280 Tests: 17 Failed: 5)
Failed tests: 9-10, 12, 16-17
Non-zero exit status: 5
Files=4, Tests=20, 10 wallclock secs ( 0.05 usr 0.01 sys + 4.03 cusr
0.34 csys = 4.43 CPU)
Result: FAIL
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
The errors file is not attached - because it is above the quota and
requires moderation - but I can send it to anyone off the list.
The relevant versions prereqs:
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
perl Makefile.PL
Cannot determine perl version info from
lib/Catalyst/Authentication/Credential/OpenID.pm
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
[Core Features]
- LWPx::ParanoidAgent...loaded. (1.06 = 1.03)
- Test::More ...loaded. (0.86 = 0.42)
- Net::OpenID::Server...loaded. (1.02 = 1.02)
- Test::WWW::Mechanize ...loaded. (1.20 = 1.20)
- Net::DNS ...loaded. (0.63)
- IO::Socket::INET ...loaded. (1.31)
- parent ...loaded. (0.221 = 0.2)
- Class::Accessor::Fast ...loaded. (0.33)
- HTML::Parser ...loaded. (3.60 = 3)
- LWP::UserAgent ...loaded. (5.824)
- Cache::FastMmap...loaded. (1.30 = 1.28)
- Catalyst ...loaded. (5.80007 = 5.7)
- Catalyst::Devel...loaded. (1.17 = 1)
- Crypt::DH ...loaded. (0.06 = 0.05)
- Net::OpenID::Consumer ...loaded. (1.03 = 1.03)
- Catalyst::Authentication::User::Hash ...loaded. (0)
- Catalyst::Plugin::Session::Store::FastMmap ...loaded. (0.11 = 0.05)
- Catalyst::Plugin::Session::State::Cookie ...loaded. (0.11 = 0.08)
- Catalyst::Engine::HTTP ...loaded. (0)
*** Module::AutoInstall configuration finished.
Writing Makefile for Catalyst::Authentication::Credential::OpenID
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
Cheers,
Zbigniew
On Mon, Jul 20, 2009 at 9:28 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
Next thing is that LWPx::ParanoidAgent does not set attributes from
the call to 'new'. It is not documented there - so I guess this is
fair from the side of LWPx::ParanoidAgent - but in line 62 in
Catalyst::Authentication::Credential::OpenID there is:
ua = $self-_config-{ua_class}-new(%{$self-_config-{ua_args} || {}}),
so there is some misunderstanding between those two modules.
But it would be nice if LWPx::ParanoidAgent did work like this.
Cheers,
Z.
On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com
wrote:
Brad just uploaded the module to CPAN.
Unfortunately it still fails everywhere:
http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06
Here are my results:
perl -Ilib t/00-all.t
.
.
.
Three 1-second redirect tarpits (tolerance 2)...
2.008 secs
ok 25
ok 26
ok 27
5 second tarpit (tolerance 2)...
not ok 28
# Failed test at t/00-all.t line 180.
3 second tarpit (tolerance 4)...
ok 29
Killing child pid: 7392
# Looks like you failed 1 test of 29.
I hope you can get in touch with Brad again. I understand that this
is most probably just test error - and forcing the installation is not
a problem for people who analyze it, but if I included this in other
module - then the dependency would hide where the problem comes from.
So I am still not ready to add OpenID to the CatalystX::SimpleLogin
project.
Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] OpenID authentication and LWPx-ParanoidAgent
On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote: Brad just uploaded the module to CPAN. Unfortunately it still fails everywhere: http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06 Here are my results: perl -Ilib t/00-all.t . . . Three 1-second redirect tarpits (tolerance 2)... 2.008 secs ok 25 ok 26 ok 27 5 second tarpit (tolerance 2)... not ok 28 # Failed test at t/00-all.t line 180. 3 second tarpit (tolerance 4)... ok 29 Killing child pid: 7392 # Looks like you failed 1 test of 29. I hope you can get in touch with Brad again. I understand that this is most probably just test error - and forcing the installation is not a problem for people who analyze it, but if I included this in other module - then the dependency would hide where the problem comes from. So I am still not ready to add OpenID to the CatalystX::SimpleLogin project. Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OpenID authentication and LWPx-ParanoidAgent
Next thing is that LWPx::ParanoidAgent does not set attributes from
the call to 'new'. It is not documented there - so I guess this is
fair from the side of LWPx::ParanoidAgent - but in line 62 in
Catalyst::Authentication::Credential::OpenID there is:
ua = $self-_config-{ua_class}-new(%{$self-_config-{ua_args} || {}}),
so there is some misunderstanding between those two modules.
But it would be nice if LWPx::ParanoidAgent did work like this.
Cheers,
Z.
On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote:
Brad just uploaded the module to CPAN.
Unfortunately it still fails everywhere:
http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06
Here are my results:
perl -Ilib t/00-all.t
.
.
.
Three 1-second redirect tarpits (tolerance 2)...
2.008 secs
ok 25
ok 26
ok 27
5 second tarpit (tolerance 2)...
not ok 28
# Failed test at t/00-all.t line 180.
3 second tarpit (tolerance 4)...
ok 29
Killing child pid: 7392
# Looks like you failed 1 test of 29.
I hope you can get in touch with Brad again. I understand that this
is most probably just test error - and forcing the installation is not
a problem for people who analyze it, but if I included this in other
module - then the dependency would hide where the problem comes from.
So I am still not ready to add OpenID to the CatalystX::SimpleLogin
project.
Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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/
[Catalyst] What do you guys use for sanitizing HTML input
Hi, There seems to be a log list of HTML sanitizers at CPAN and no guide. So I quickly made a list at the P5P wiki: http://www.perlfoundation.org/perl5/index.cgi?html_sanitazing and I am asking here what are your experiences with that subject. Myself, I sometime ago I've wrote a sanitizer for HTML::FormHandler based on HTML::Scrubber - but it seems that there are problems with installing it so it never got into the HTML::FormHandler repository. I noticed that there is a new HTML sanitizer bundled with Mojo: http://search.cpan.org/~mramberg/MojoMojo-0.999030/lib/HTML/Declaw.pm by our own Marcus Ramberg. The POD says it is a modifed version of HTML::Defang - but there is no clue as to what was really modified and why it is a fork. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OpenID authentication and LWPx-ParanoidAgent
On Sat, Jul 18, 2009 at 2:27 AM, Tatsuhiko Miyagawamiyag...@gmail.com wrote: I actually applied the same patch against its SVN repository a few weeks ago. I'll poke Brad to make a new release on CPAN. http://code.sixapart.com/svn/LWPx-ParanoidAgent/trunk/ Thanks - that's great! While we are at it - it seems that there is also problem with the Crypt::DH package (which is another dependency)- this is nicely explained in DESCRIPTION in http://search.cpan.org/dist/Crypt-DH-GMP/lib/Crypt/DH/GMP.pm and it seems like a reasonable replacement. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/
[Catalyst] OpenID authentication and LWPx-ParanoidAgent
Hi there, It seems that http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.05 fails on every front (and if you check the history it wasn't much better in previous releases). So what you guys use as the LWP agent for OpenID authentication? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/
sub Attributes (was Re: [Catalyst] How to do pass-through login?)
On Sun, Jul 12, 2009 at 1:43 AM, Tomas Doranbobtf...@bobtfish.net wrote:
Having spoken to the the author of the above mentioned module, I've gone
ahead and converted it to an ActionRole:
http://github.com/bobtfish/catalyst-actionrole-acl/tree/master
I just had a look there:
sub foo
:Local
:Does(ACL)
:RequiresRole(admin)
:ACLDetachTo(denied)
Nice - I hope this formatting becomes a standard. Stacking of more
and more attrs on the same line was driving me crazy - I did not know
that you can put a newline there.
By the way - theoretically all this could be equivalently coded as
something like:
package MyController;
use
with ACL;
sub foo : Local {
($self, $c, @args ) = @_;
$self-check_acl_role( 'admin', 'denied' );
It seems that people prefer the attributes - I guess because they are
more declarative.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] How to do pass-through login?
On Thu, Jul 9, 2009 at 11:03 AM, Gunnar Strandgunnarstr...@yahoo.com wrote:
Hi,
I am looking for a way to send users to the login screen if they are
trying to access a restricted path, and if the login is valid, the
original request should just continue like this:
1. myapp - GET /member/only
2. myapp - /login_form
3. myapp - POST /login
4. myapp - /member/only
I guess this is what is called pass-through login (and other actions)
in the Cookbook, but I can't understand the description:
Provide actions for these, but when they're required for something else
fill e.g. a form variable __login and have a sub begin like so:
sub begin : Private {
my ($self, $c) = @_;
foreach my $action (qw/login docommand foo bar whatever/) {
if ($c-req-params-{__${action}}) {
$c-forward($action);
}
}
}
Where is the data from the original request stored? Is everything stored
in the __$action key including any values in a form submission?
An example on how pass-through works would be very helpful.
I would have expected something like this (pseudo-code):
In begin for /member/only:
unless ( $c - user_exists() ) {
$c - delay_action(); # Saves state in Flash or Session
$c - forward('/login_form');
}
In login after authentication:
if ( $c - restore_action() ) {
$c - continue_action();
}
There is Catalyst::Helper::Auth that generates such a passthrough
login component, but it is rather buggy. You can have a look at mine
ProtoWiki code at:
http://github.com/zby/CatalystX--ProtoWiki/blob/237284a35f5fd65e3d32cb5f88b81c28a47250e9/lib/CatalystX/ProtoWiki/Controller/Auth.pm
- it is copied from the code generated by Catalyst::Helper::Auth - and
then a bit modified/fixed, but it still needs a lot of work. It
redirects to an 'url' not action - so in theory it should retain
parameters etc. - but I am not sure if they are correctly encoded now.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Themes, skins, templates and componentized UI?
On Mon, Jul 6, 2009 at 9:55 PM, Gunnar Strandgunnarstr...@yahoo.com wrote: Hi, I am a little new in the web design area. I'm trying to design an application where the view part must be simple to replace by whomever installs it, with elements of their own design. This would work comparable to themes or skins. I've done some googling, but I haven't got any obvious hits on this. The closest I _think_ is CatalystX::Usul, but I haven't really understood if that's what I'm looking for :-) Also, I would also want the person installing the application to be able to restructure the visual parts using components, where a component could for instance be a result ticker, main menu, member table or such. Perhaps in the way that Joomla does, but the components will be application specific. It's much a matter of deciding what components are present in which views and where. I imagine, for instance, a collection of widgets (button, drop-down-list, text field etc) which are reused in the TT templates. A component would then use these widgets as building blocks, populating them using data from the stash. A view (webpage) would be a template including one or more of these components. A theme could then override any widgets of choice to change the look-and-feel of the whole application instantly. Am I approaching this from the right direction and does anyone know if there exists a framework similar to this to use with Catalyst? Or should I perhaps go barking up the TT tree? ;-) I am working on CatalystX::Elements with the first one being Comments - I am not sure if it goes in the same direction - but it seems close. The main goal is providing Catalyst feature addons - that could be used as kind of scaffolding - that is they should be easy to assemble, implying they are rather simplistic, and later easy to be gradually replaced. For now I am not dealing with templates at all - the Comments element lets you to stash a form which knows how to render itself into HTML and can be inserted somewhere in the templates. I've posted about it at my blog: http://perlalchemy.blogspot.com/2009/06/catalystxcomments-rfc.html (also have a look at the comment). There is some code for it at: http://github.com/gshank/ravlog/tree/8b7ec1493324212cde91927c15fc54cd2c9db25d/lib/CatalystX (but now I've decided to change the name and add Elements - a play on the chemical metaphor of Catalyst). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] FormFu vs. FormBuilder ...
On Wed, Jun 10, 2009 at 9:00 AM, Kiffin Gishkiffin.g...@planet.nl wrote: What are the advantages/disadvantages for choosing between Catalyst::Controller::FormBuilder and Catalyst::Controller::HTML:FormFu? Those two are not the only options. Have a look at: http://www.perlfoundation.org/perl5/index.cgi?form_processing In my opinion the Catalyst controllers don't server any purpose other than documenting how to configure a form processor for Catalyst. This should not require a separate module - as this additional layer only adds friction (problems like exposing not exactly full API of the original processor, lagging after new releases of the processor and Catalyst etc.) - but I agree that this kind of configuration should be put somewhere and should be accompanied by tests. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Best practice: How to build app parts reusable?
On Sun, May 31, 2009 at 6:06 PM, Matthias Dietrich mdietr...@cpan.org wrote: Hi, in one of my Catalyst apps I'm building application parts that I want to reuse in other Catalyst apps where possible. What's the best practice to do that? I mean the complete parts from controller, to model, DBIC schema classes and templates. Let's assume one part is a guestbook (no, it's not but it's a funny example ;)). The integration of the controller class is very easy. I just would build a new controller inside the app which uses the guestbook controller as base class and sets the correct namespace, where the guestbook should appear. A similar procedure would get me the model and schemes into my app, but it requires a wrapper class for each class the guestbook brings with. And the templates? The only way I know of is to copy and paste them into the 'root' folder of the app. Just one idea - in the TT view there is a http://search.cpan.org/~mramberg/Catalyst-View-TT-0.29/lib/Catalyst/View/TT.pm#DYNAMIC_INCLUDE_PATH option. I have never eventually used that - but when I was adding it what I had in mind was something like template inheritance. By splitting the templates into separate files you can use it to override those individual templates just like you can override methods in a class. The difference is that a class is a file and method is a part of that file - here the the corresponding things are a directory and an individual template. There has to be a better way. But which? I'm also thinking about whole reusable applications. For example a shopping system which can be extended and modified by overwriting methods while the base system can be upgraded seamlessly. (I know MojoMojo as a standalone Catalyst app, but it's only standalone and not to be extended locally.) There is Handel - I have never explored it but I think the design goal was to make it extendable. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] More natural access to model?
2009/5/12 Paweł Tęcza pte...@uw.edu.pl:
Dear Catalyst users,
It's my first post here, so I would like to say Hello to all of us! :)
I'm writing my first Catalyst application for student registration and I
have the following tables for details about studies at our university:
CREATE TABLE studies (
id integer NOT NULL,
unit_id integer,
status integer,
limit_soft integer,
limit_hard integer
);
'id' column is a database study identifier. It's also primary key for
that table. 'unit_id' is an unit identifier of study, 'status' column
says whether registration is open/suspended/closed, 'limit_soft' and
'limit_hard' are for student number limits.
CREATE TABLE study_data (
study_id integer NOT NULL,
lang lang NOT NULL,
name text NOT NULL,
value text
);
'study_id' column is database study identifier (please look at
studies.id column), 'lang' column points language for (name, value)
pair, for example 'pl', 'en', etc. 'name' column is for name of data,
for example 'name', 'description', 'program', 'email', etc.
('study_id', 'lang', 'name') is a primary key for that table. Finally
'value' column is for data content.
I think it's very simple structure and fully understandable for you,
so it doesn't need more comments. Of course, I can also define
table 'study_data' with many columns, for example 'name', 'description',
'program', 'email', etc. but I think that its simpler structure is
better idea here, because it's more flexible. I can add new type of
data, without changing table definition.
Unfortunately, when I want to get the study details, then I need to use
the code like below:
my $study_name = '';
my $study_description = '';
my $study_program = '';
my $study_email = '';
my @studies = $c-model('DB::Studies')-all;
foreach my $study in (@studies) {
my $name = $study.study_datas.name;
my $value = $study.study_datas.value;
$study_name = $value if ($name eq 'name');
$study_description = $value if ($name eq 'description');
$study_program = $value if ($name eq 'program');
$study_email = $value if ($name eq 'email');
}
I hope you agree with me that it's not handy way...
So my question is: how can I modify my model to get the study details
in the following, more natural way? Is it possibble at all?
my @studies = $c-model('DB::Studies')-all;
foreach my $study in (@studies) {
$study_name = $study.study_datas.name || '';
$study_description = $study.study_datas.description || '';
$study_program = $study.study_datas.program || '';
$study_email = $study.study_datas.email || '';
}
Hmm - there is something missing there - according to your description
above $study.study_datas.program can not identify one value - but
rather an array of values (one for each language) isn't that true?
You might also want to change the '.' to '-'.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] The Netiquette thread (OT)
I have the feeling that this bashing of top posters or bottom posters or whatever netiquette you have in disregard is often just showing off your status in the community. There are studies showing that practical jokes victims (in traditional work situations) [1] are the less efficient workers than the perpetrators - this is the same online. I don't like it. I don't want to judge it neither and I don't want to request anyone to change this - but perhaps some people here are capable of this self reflection on the true source of their irritation. [1] - http://www.informaworld.com/smpp/content~content=a738552611~db=all -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] RFC: Sample press release and announcement homepage
On Thu, Apr 23, 2009 at 11:03 PM, John Napiorkowski jjn1...@yahoo.com wrote: Thanks these are great additions. I modified the wiki page with these and a few other tweaks I got from reviewing several other press releases Lastest at: http://dev.catalystframework.org/wiki/releaseannouncements/58pressrelease ... the revolutionary Moose Object system, the most advanced Object Oriented framework for any major scripting language I would change that to 'one of the most advanced' - less flame igniting (and by the way Perl 6 probably does have a more advanced Object system). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Google summer of code proposal
2009/4/2 Octavian Râsnita orasn...@gmail.com: From: Devin Austin My proposal is to refactor for the Catalyst web framework's helpers to make them more extensible. Helpers date from the early days of the framework, but have lagged far behind in development compared to other aspects of Catalyst. Current solutions are hackish, brittle, and inconsistent. The goal of this project is to clean up the previous “API”, solidify it with tests and documentation, and then expand it to add features that will give them more usefulness than just “generating scaffolding” code. That is, to make Catalyst helpers more useful for everyone rather than just beginning developers. Congratulations for the idea. What I think it could be helpful for having in the Catalyst helpers that need to use very many parameters, is the possibility of specifying a configuration file that contains all the needed parameters. This way it would be more simple to re-use the helper for the next time, without worrying that we might forget some parameters. For example, instead of: $ perl scripts/myapp_create.pl model DB DBIC::Schema MyApp::Database create=static components=Digest::Columns dbi:mysql:database=test user pass we could use: $ perl scripts/myapp_create.pl @db.txt and the file db.txt could contain: type=model name=DB params=DBIC::Schema MyApp::Database create=static components=Digest::Columns dbi:mysql:database=test user pass I concur - and to make it perfect it should be able to generate many components at once and not use scripts/myapp_create.pl but the original catalyst.pl - so the whole app could be generated in one step. Now I need to do ugly hacks with Find::Bin to do that in InstantCRUD. Two more ideas (that I've already posted to the other mailing list: 1) Helpers now are completely separated - each one generates it's own part of the application, but does not change anything else. It would be useful at least to be able to add the configuration to the main application config file instead of adding config to the generated classes (case in point Catalyst::View::TT). 2) Module::Starter - maybe we could refactor at least part of the helper stuff as Module::Starter plugins - and have the benefit of using something generic? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] LEFT JOIN with AND statement
On Tue, Mar 17, 2009 at 9:55 PM, Jakub Tutaj j...@wp.pl wrote:
Hello!
I'd like to prepare query like:
SELECT group_tasks.*,student_tasks.*
FROM group_tasks
LEFT JOIN student_tasks
ON group_tasks.id = student_tasks.group_task_id AND student_tasks.user_id =
1
WHERE group_tasks.group_id = 1
I stuck at this point:
$c-stash-{studentgrouptasks} = [$c-model('sapsDB::GroupTasks')-search(
{
'me.group_id' = 1,
},
{
join = [qw/ studenttasks/]
}
)];
I don't know where can I put 'AND student_tasks.user_id = 1' so it's
corresponding with 'join'. I'd like to have list of all grouptasks designed
for the student and if student already did the task (there's a studenttask
record in DB) I also want info about it. That's why I need this 'AND' in
JOIN .. ON statement, instead of normal JOIN .. ON .. WHERE clause. Any
help?
My tables are something like this:
GroupTasks:
id
status
task_id
group_id
StudentTasks:
id
status
group_task_id
user_id
has_many and belongs_to :
saps::Schema::GroupTasks-has_many(studenttasks =
'saps::Schema::StudentTasks', 'group_task_id');
saps::Schema::StudentTasks-belongs_to(grouptask =
'saps::Schema::GroupTasks', 'group_task_id');
Another question is, if I have proper query, how to distinct
studenttasks.status and grouptasks.status using stashed 'studentgrouptasks'
variable in TT (using FOREACH etc.)?
This is really not about Catalyst but rather about DBIC - so you might
want to redirect this question to the appriopriate list, but answering
your question I think the only way to do it is via a custom ResultSet
(http://search.cpan.org/~ribasushi/DBIx-Class-0.08099_07/lib/DBIx/Class/Manual/Cookbook.pod#Arbitrary_SQL_through_a_custom_ResultSource)
or using the from attribute
(http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/ResultSet.pm#from
- note the 'Use this on your own risk' warning).
Pozdr.
Zbyszek
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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/
[Catalyst] In search of RESTful CRUD holy grail
This might be a futile mission - but I think I learn something with each recurrence of this discussion. So let's restart it once again. CatalystX::CRUD::REST has a well described RESTful URI structure: # POST /foo- create new record # GET /foo- list all records # PUT /foo/pk - update record # DELETE/foo/pk - delete record # GET /foo/pk - view record # GET /foo/pk/edit_form - edit record form # GET /foo/create_form- create record form I think everyone will agree that this is indeed REST. For some cases there might be a slight problem with that URI schema - if you have a string primary key - and it can have the value of 'create_form' - then you will not know if the client is requesting a view on the object with that id or if he wants the page with the form to create a new object. This leads to new variation: # POST /foo- create new record # GET /foo- list all records # PUT /foo/by_id/pk - update record # DELETE/foo/by_id/pk - delete record # GET /foo/by_id/pk - view record # GET /foo/by_id/pk/edit_form - edit record form # GET /foo/create_form- create record form Of course 'by_id' could be 'instance' or whatever (perhaps the library should let the user to choose that infix part). Now '/foo/by_id/pk/edit_form' needs to make a PUT request to /foo/by_id/pk. To get around the problem with requests outside of the basic 'GET' and 'POST' repertoir we can use Catalyst::Request::REST::ForBrowsers. But it also means that for browser requests in the case of mistakes made in the form the action answering that PUT request to '/foo/by_id/pk' needs to render the form again with error indicators. But for non browser requests in case of similar errors it needs to encode those errors in some other way. This shows that 'edit_form' is only informing us how to *render* (or serialize) the data. In the case of GET requests it informs us that we should render the object data inside of a form and in the case of a PUT request with errors it informs us that we should similarly put the error data into the form. This leads to next variation: # PUT /foo/by_id/pk - update record or return the error encoded for non-browsers # PUT /foo/by_id/pk/edit_form - update record or return the error encoded as HTML form # DELETE/foo/by_id/pk - delete record # GET /foo/by_id/pk - view record (for non-browsers encoded) # GET /foo/by_id/pk/edit_form - view record encoded as an edit form And similarly: # POST /foo - create new record # POST /foo/create_form - create record form # GET /foo - list all records # GET /foo/create_form - create record form i.e. - here we treat 'edit_form' and 'create_form' consistently as a path info parameter informing us about the serialization method. The advantage of this arrangement is also that we don't need to put any address into the 'action' parameter of the form - and let it always submit to itself. In another variation we could move that parameter from path info to real parameters and have uris like: # PUT /foo/by_id/pk- update record or return the error encoded # PUT /foo/by_id/pk?x-view=edit_form - update record or return the error encoded as HTML form # DELETE/foo/by_id/pk- delete record # GET /foo/by_id/pk - view record (encoded) # GET /foo/by_id/pk?x-view=edit_form- view record encoded as an edit form Finally we need serialisation and dispatching to different methods for the same address (/foo/by_id/) based on the method. This is covered by Catalyst::Controller::REST. What I have not yet explored is how to add this new serialisation method (to 'edit_form') to the configuration of a Catalyst::Controller::REST based controller. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OT: edit/add seperate actions?
On Tue, Mar 3, 2009 at 7:33 PM, Peter Karman pe...@peknet.com wrote: Iain wrote on 03/03/2009 09:33 AM: Hello all, So we are having a discussion @work about basic add/edit functions. We currently have currently two lines of thoughts on handling it. 1. Have separate actions for adding and editing e.g. # add /app/notice/add_new (POST To) /app/notice/process_add_new # edit /app/notice/*/edit (POST To) /app/notice/*/process_edit 2. Have a shared edit action with an if ( $c-req-method eq 'POST' ) check. # edit /app/notice/*/edit (POST Back to) /app/notice/*/edit There currently doesn't look like much difference in lines of code to manage. Just wondering if anybody has any thoughts/experience, pros/cons best practice etc of either approach. CatalystX::CRUD::Controller does: /app/notice/create # redirect internally to 0/edit /app/notice/*/edit # POST to /app/notice/*/save The '0' placeholder indicates it is a new object. '0' has the nice effect of evaluating true for defined() and length() but false otherwise. OTOH, it means you can't have a valid OID that == 0. If you use CatalystX::CRUD::REST, you can do: # POST /foo - create new record # GET /foo - list all records # PUT /foo/pk - update record # DELETE /foo/pk - delete record # GET /foo/pk - view record # GET /foo/pk/edit_form - edit record form # GET /foo/create_form - create record form CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of 'x-tunneled-method' param to support PUT and DELETE via POST. And where do the forms submit? I mean what is their action address? Do they submit to themselves - or does edit_form submit to /foo/pk?x-tunneled-method=PUT and create to /foo both with POST method? And it is the second - then what do you do when the form parameters are incorrect and you need to redisplay the form? -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OT: edit/add seperate actions?
On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman pe...@peknet.com wrote: Zbigniew Lukasiak wrote on 03/03/2009 02:53 PM: If you use CatalystX::CRUD::REST, you can do: # POST /foo - create new record # GET /foo - list all records # PUT /foo/pk - update record # DELETE /foo/pk - delete record # GET /foo/pk - view record # GET /foo/pk/edit_form - edit record form # GET /foo/create_form - create record form CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of 'x-tunneled-method' param to support PUT and DELETE via POST. And where do the forms submit? I mean what is their action address? Do they submit to themselves - or does edit_form submit to /foo/pk?x-tunneled-method=PUT and create to /foo both with POST method? And it is the second - then what do you do when the form parameters are incorrect and you need to redisplay the form? using the CXC REST API: if you GET /foo/1234, then you must PUT /foo/1234 to save it. (or POST /foo/1234?x-tunneled-method=PUT -- although I always put the x-tunneled-method value in a hidden input body param, not as part of the URL). Sure - that was just for clarification of how the PUT is done with browsers :) if you GET /foo/create_form, then you must POST /foo. When the form is redisplayed on validation error, it just retains the original action. I was just thinking about the possible CRUD REST schemas and it found that under that schema you display the same form under two addresses: /foo/1234/edit_form and /foo/1234 (in case of the error). And the other day I had that idea that perhaps instead of using path part - use another parameter so /foo/1234?x-view-method=edit_form would render the form and /foo/1234 would render the standard view of the object. This way the form would have just one address. Both things are just different representations of the same thing - so using a parameter to differentiate between them seems quite logical. But on the other hand it might look too different from the traditional ways. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OT: edit/add seperate actions?
On Tue, Mar 3, 2009 at 11:35 PM, Peter Karman pe...@peknet.com wrote: Zbigniew Lukasiak wrote on 03/03/2009 04:18 PM: - Show quoted text - On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman pe...@peknet.com wrote: Zbigniew Lukasiak wrote on 03/03/2009 02:53 PM: If you use CatalystX::CRUD::REST, you can do: # POST /foo - create new record # GET /foo - list all records # PUT /foo/pk - update record # DELETE /foo/pk - delete record # GET /foo/pk - view record # GET /foo/pk/edit_form - edit record form # GET /foo/create_form - create record form CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of 'x-tunneled-method' param to support PUT and DELETE via POST. And where do the forms submit? I mean what is their action address? Do they submit to themselves - or does edit_form submit to /foo/pk?x-tunneled-method=PUT and create to /foo both with POST method? And it is the second - then what do you do when the form parameters are incorrect and you need to redisplay the form? using the CXC REST API: if you GET /foo/1234, then you must PUT /foo/1234 to save it. (or POST /foo/1234?x-tunneled-method=PUT -- although I always put the x-tunneled-method value in a hidden input body param, not as part of the URL). Sure - that was just for clarification of how the PUT is done with browsers :) if you GET /foo/create_form, then you must POST /foo. When the form is redisplayed on validation error, it just retains the original action. I was just thinking about the possible CRUD REST schemas and it found that under that schema you display the same form under two addresses: /foo/1234/edit_form and /foo/1234 (in case of the error). And the other day I had that idea that perhaps instead of using path part - use another parameter so /foo/1234?x-view-method=edit_form would render the form and /foo/1234 would render the standard view of the object. This way the form would have just one address. In CXC REST, /foo/1234 is analogous to /foo/1234/view in the RPC format. It does not return a HTML form. It just returns the object data. I.e., read-only. So the URLs represent two different things. But they do represent two views on the same object - one is as you say 'read-only' the other is the form filled with it's values. The same object - two different renderings. That is what I meant. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: OT: Better TT pager?
On Thu, Jan 22, 2009 at 4:48 PM, Oliver Charles oliver.g.char...@googlemail.com wrote: I might as well join in with this :) Here's what we use at work: [% IF pager %] ul class=paginator li class=counterPage [% pager.current_page %] of [% pager.last_page %]/li lia href=[% c.req.uri_with( page = pager.first_page ) %]laquo;/a/li [% IF pager.previous_page %] lia href=[% c.req.uri_with( page = pager.previous_page ) %]lt;/a/li [% END %] [% start = (pager.current_page - 3) 0 ? (pager.current_page - 3) : 1; FOREACH page IN [ start .. pager.last_page ] %] [% LAST IF loop.count 6 %] li[% IF pager.current_page == page; ' class=current'; END %] a href=[% c.req.uri_with( page = page ) %][% page %]/a /li [% END %] [% IF pager.next_page %] lia href=[% c.req.uri_with( page = pager.next_page ) %]gt;/a/li [% END %] lia href=[% c.req.uri_with( page = pager.last_page ) %]raquo;/a/li /ul [% END %] Though my colleague rightly suggested we subclass Data::Page and perform the sliding window in there. This shows first page, previous page, the current page surrounded by near-by pages. Seems to do the job so far! Hi, I've just adopted your example and replaced my pager in InstantCRUD. I added credit note like that: =head1 AUTHOR Zbigniew Lukasiak C zz bb yy @ gmail.com Pager adapted from example by Oliver Charles. I hope you are satisfied. Cheers, Zbigniew PS. Here is the adopted version: [% IF pager %] div class=pager div class=counter Page [% pager.current_page %] of [% pager.last_page %] /div div [% IF pager.previous_page %] spana href=[% c.req.uri_with( page = pager.first_page ) %]laquo;/a/span spana href=[% c.req.uri_with( page = pager.previous_page ) %]lt;/a/span [% END %] [% start = (pager.current_page - 3) 0 ? (pager.current_page - 3) : 1; FOREACH page IN [ start .. pager.last_page ] %] [% LAST IF loop.count 6 %] [% IF pager.current_page == page %] span class=current [% page %] /span [% ELSE %] span a href=[% c.req.uri_with( page = page ) %][% page %]/a /span [% END %] [% END %] [% IF pager.next_page %] spana href=[% c.req.uri_with( page = pager.next_page ) %]gt;/a/span spana href=[% c.req.uri_with( page = pager.last_page ) %]raquo;/a/span [% END %] /div /div [% END %] ___ 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] CatalystX
On Fri, Feb 27, 2009 at 12:35 PM, Dermot paik...@googlemail.com wrote: Hi, I saw a demo of CatX::ListFramework-builder yesterday and I was very impressed. I'd like to be able to give admin users of a wee app access to something similar. The idea is just to give them and me a means of looking at the schema. There are a lot of CatX modules at cpan. Is ListFramwork-builder recommanded or are there other modules that are more stable? ListFramework is focused on the task of providing such an admin interface - so I guess out of the many other Catalyst CRUD frameworks it must really excel at that. But if you were looking rather for a scaffolding (i.e. something that builds a *template* CRUD application - which you can later modify to adjust to your needs) - then you could have a look at mine Catalyst::Example::InstantCRUD that I've just released in the 0.0.29 version (the new thing in this version is handling text semantic and UTF-8 in output). In general the authoritative page on Catalyst CRUDs is: http://dev.catalystframework.org/wiki/crud Cheers, Zbigniew -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: (OT) Navigation parameters in session
On Fri, Feb 27, 2009 at 4:11 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote: Users will not be e able to use the back button, and they will not be able to work in multiple tabs. You will not be able to load-balance as effectively as you could without sessions. A lot of your content will be hidden from search engines. I could think of more, but that should be enough for a start. Thanks for you all for the arguments. The crazy thing is that they believe that with some Javascript magic we'll be able to manage the multiple tabs and back button problem. If you need an argument from authority, ask why none of the biggest sites like Google, Amayon, etc do it that way. :) - this has potential. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: decoding in core
On Fri, Feb 20, 2009 at 6:57 PM, Jonathan Rockway j...@jrock.us wrote: Braindump follows. snip snip One last thing, if this becomes core, it will definitely break people's apps. Many, many apps are blissfully unaware of characters and treat text as binary... and their apps kind-of appear to work. As soon as they get some real characters in their app, though, they will have double-encoded nonsense all over the place, and will blame you for this. (I loaded Catalyst::Plugin::Unicode, and my app broke! It's all your fault. Yup, people mail that to me privately all the time. For some reason, they think I am going to personally fix their app, despite having written volumes of documentation about this. Wrong.) Some more things to consider. - 'use utf8' in the code generated by the helpers? - ENCODING: UTF-8 for the TT view helper? Maybe a global config option to choose the byte or character semantics? But with the DB it becomes a bit more complex - because BLOB columns probably need to use byte sematic. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: decoding in core
On Mon, Feb 23, 2009 at 2:58 PM, Neo [GC] n...@gothic-chat.de wrote: Zbigniew Lukasiak schrieb: Some more things to consider. - 'use utf8' in the code generated by the helpers? Reasonable, but only if documentet. It took weeks for us until we learned, that this changes _nothing_ but the behaviour of several perl-functions like regexp, sort aso. Hmm - in my understanding it only changes literals in the code ( $var = 'ą' ). So I looked into the pod and it says: Bytes in the source text that have their high-bit set will be treated as being part of a literal UTF-8 character. This includes most literals such as identifier names, string constants, and con- stant regular expression patterns. - ENCODING: UTF-8 for the TT view helper? Maybe a global config option to choose the byte or character semantics? But with the DB it becomes a bit more complex - because BLOB columns probably need to use byte sematic. Uhm, of course, as BLOB is Binary and CLOB is Character. ;) This is even more complex, as the databases have different treating for this datatypes and some of Perls DBI-drivers are somewhat broken when it goes to unicode (according to our perl-saves-our-souls-guru). UTF-8 is ok in Perl itself (not easy, not coherent, but ok); but in combination of many modules (and as far as I learned, Perl is all about reusing modules) it is _hell_. Try to read UTF-8 from HTTP-request, store in database, select with correct order, write to XLS, convert to CSV, reimport it into the DB and output it to the browser, all with different subs in the same controller... and you know, what I mean. Even our most euphoric Perl-gurus don't have any clue how to handle UTF-8 from the beginning to the end without hour-long trialerror in their programs (and remember - we Germans do only have those bloody Umlauts - try to imagine this in China _). Maybe the best thing for all average-and-below users would be a _really_ good tutorial about Catalyst+UTF-8. What to do, what not to do. How to read UTF-8 from HTTP-request / uploaded file / local file / database, how to write it to client / downloadable file / local file / database. What catalystish variable is UTF-8-encoded when and why. How to determine what encoding a given scalar has and how to encode/decode/whatevercode it to a bloody nice scalar with shiny UTF-8 chars in it. Short: -- Umlauts with Catalyst for dummies -- Hmm - maybe I'll add UTF-8 handling in InstantCRUD. I am waiting for good sentences showing off the national characters. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] New version of InstantCRUD
Just one more thought on collaboration in general: let's find some elements in each other work that we would like to collaborate on, let's not strive to steer the other project in full into the direction of our wishes. Let's divide the projects so that later each of us will be able to assemble his own ideal solution out of it. Zbigniew On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). - Alex aka abraxxa Am Montag, den 16.02.2009, 21:44 +0100 schrieb Zbigniew Lukasiak: Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/ *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] New version of InstantCRUD
On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier alexander.hartma...@t-systems.at wrote: Would be great if we could combine our efforts instead of creating even more choices for the users of cat in form of InstantCRUD, Controller::DBIC::API and so on (http://dev.catalyst.perl.org/wiki/crud). Sure. Let me only point out that InstantCRUD was one of the first (published just after Enzyme). But this idea of combining efforts is what lead me when starting that wiki page. I am open for collaboration, I've already started figuring out what can be done with Peter Karman (of CatalystX::CRUD). For me his approach is a bit too heavy - it requires too much knowledge of his libraries to extend the controller using it - it wraps the model into it's own abstractions (CatalystX::CRUD::Iterator, CatalystX::CRUD::Model ) - while I believe that it should be possible to have the CRUD as an add-on and let the user work with his original Model. I updated my work to try out this - and also show the others what I really mean. I've also looked into other CRUDs - but I have not yet found one satisfying my requirements. For example CatalystX-ListFramework-Builder-0.41 is great - but it is not a scaffolding, CatalystX::ListFramework is nice but is not REST-like, Catalyst::Controller::DBIC::API is very close to what I need - and I plan base my future work on it but for now there is some problem with multiple inheritance in Catalyst Controllers that make it incompatible with my approach, I hope that when we get the Moose version of Catalyst this problem will go away. And I hope that then the base controller will become a Moose role instead for greater flexibility. In short I am open for collaboration - but I found it difficult to express my expectations for the library without writing my own code. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/
[Catalyst] New version of InstantCRUD
Looks like we are again discussing CRUD in Catalyst - so I decided to finally update InstantCRUD and release it to CPAN. It is still experimental. It is a 'scaffolding' - like the Rails one - it generates a CRUD application for a given dsn. Some more random thoughs: http://dev.catalystframework.org/wiki/crud/instantcrud and http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I completely disagree with the Preliminary URI naming guidelines). -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Re: loading data types from Oracle DB with DBIx::Class::Schema::Loader
On Wed, Feb 11, 2009 at 1:47 PM, Karl Forner karl.for...@gmail.com wrote: I believe I fixed the problem (cf my post bug found in and tentatively fixed in DBIx::Class::Schema::Loader::DBI::Oracle::_tables_list in the dbix mailing list). Here's a copy : We had a problem because DBIx::Class::Schema::Loader did not get the column_info for our Oracle database : no data_types, is_nullable, default etc.. attributes were set. We traced the problem down to DBIx::Class::Schema::Loader:: DBI::Oracle::_tables_list, that changed the table names to lowercase. So just commenting the line 69 : $table = lc $table; seems to fix the problem. The test is either to call the _tables_list and check the table names, or to create a schema on a n oracle db using DBIx::Class::Schema::Loader::make_schema_at, and to check that the generated DBIx::Class objects have the column attributes such asdata_type, default_value , is_nullable , size etc... Here are some details: DBIx::Class::Schema::Loader $VERSION = '0.04004' perl, v5.8.8 built for i486-linux-gnu-thread-multi diff: --- Oracle.pm2009-02-11 13:35:08.0 +0100 +++ Oracle.pm.fixed2009-02-11 13:35:04.0 +0100 @@ -66,7 +66,7 @@ $table =~ s/\w+\.//; next if $table eq 'PLAN_TABLE'; -$table = lc $table; +# $table = lc $table; # removed by kf Hmm - it was just the first version of that code that I worken on - but I remember that there some problems when the metadata was saved under a hash key different from the table name, because it is referred in other places. Not that I am sure it applies here - but this might be something you should check. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] RFC: Catalyst::Controller::RHTMLO
On Mon, Feb 2, 2009 at 7:59 PM, Jason Gottshall jgottsh...@capwiz.com wrote: Zbigniew Lukasiak wrote: Maybe I am just being lazy now - but before I start digging too deep - did you take into accout that some forms require loading stuff from the DB? It can happen in to cases: 1) loading SELECT choices lists - this one is easy - because it can be done at initialisation as it does not depend on th request. 2) loading related forms for one to many relations - where you don't know how many related forms you need until you have the main object - i.e. until request time. See Rose::HTML::Form::Repeatable. Yes, I'm actually thinking of doing my $form = $class-new( app = $c ); so that the form can access model-related stuff as necessary. (This is safe because RHTMLO automatically weakens any value passed to -app). Would something like that address your cases? Hmm - I thought you mentioned something about caching the form objects between requests? Passing $c to the creator means you create the forms on per request basis. If you like the caching idea - then what would be needed is a kind of two phase initialisation. First you create a prototype - and then you add the necessary repeatable sub-forms on per request basis to it (of course this is only needed if you use repeatable sub-forms). Cheers, Zbigniew http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] RFC: Catalyst::Controller::RHTMLO
On Sat, Jan 31, 2009 at 12:03 AM, Jason Gottshall jgottsh...@capwiz.com wrote:
Ok, for those of you who have been waiting with bated breath, here's my
second attempt at a base controller for loading Rose::HTML::Form classes.
I've completely refactored/rewritten the configuration stuff after a long
chat with mst. I also eliminated the handling of multiple instances of the
same form in the same action, having determined that it's just not a
meaningful case. I did *not* implement any caching mechanism, based on my
concern about form objects being modified beyond simple parameter
initialization.
I think this version is a *lot* better, and I'd appreciate any additional
feedback before I package it up for CPAN. Thanks!
package Catalyst::Controller::RHTMLO;
use strict;
use warnings;
use base 'Catalyst::Controller';
use MRO::Compat;# to get $self-next::method() right
use Catalyst::Utils;
=head1 NAME
Catalyst::Controller::RHTMLO - Catalyst base controller for integrating
Rose::HTML::Form objects
=head1 SYNOPSIS
package MyApp::Controller::Books;
use base 'Catalyst::Controller::RHTMLO';
# loads MyApp::Form::Book, which should -isa('Rose::HTML::Form')
sub edit : Local Form('Book') {
my ( $self, $c ) = @_;
# form object is already init'ed with params and stashed
my $form = $c-stash-{form};
if ( $form-was_submitted ) {
if ( $form-validate ) {
# write to db or whatever
}
else {
# show errors or whatever
}
}
}
# display several search forms on same page
sub search : Local Form('ByAuthor') Form('ByTitle') {
my ( $self, $c ) = @_;
if ( $c-stash-{forms}-{ByAuthor}-was_submitted ) {
# look up books by author
}
elsif { $c-stash-{forms}-{ByTitle}-was_submitted ) {
# look up books by title, duh
}
}
=head1 DESCRIPTION
This base controller glues LCatalyst actions to form classes derived from
LRose::HTML::Form, a component of John Siracusa's burgeoning LRose
framework. Unlike some other form-loading modules (see L/PRIOR ART),
this one does not include any mechanism for defining form structures; it
merely loads, instantiates, and initializes pre-written form classes for use
in your controllers.
In order to utilize a particular form in a particular Catalyst action,
simply declare an attribute on the subroutine:
sub edit : Local Form('Book') { }
This will ensure that CMyApp::Form::Book is loaded and initialized,
basically equivalent to the following:
my $form = MyApp::Form::Book-new();
$form-params($c-req-params);
$form-init_fields;
$c-stash-{form} = $form;
The namespace used to complete the form class name is
Lconfigurable|/CONFIGURATION, or you can specify a full package name by
prepending a 'plus' sign:
sub edit : Local Form('+My::FormClasses::Book') { }
To utilize more than one distinct form class in the same action, simply
declare additional attributes:
sub search : Local Form('ByAuthor') Form('ByTitle') Form('BySubject') {
my ($self, $c) = @_;
$c-stash-{forms}{ByAuthor}-action($c-uri_for('/search/byauthor'));
$c-stash-{forms}{ByTitle}-method('GET');
$c-stash-{forms}{BySubject}-name('bytopic');
}
The first form listed will be stored in the stash in the usual location;
Iall the forms (including the first) will be stored under a separate
(Lconfigurable|/CONFIGURATION) stash key, in a hash keyed to the name used
to load them.
=head1 CONFIGURATION
You can override many defaults using Catalyst's configuration mechanism:
__PACKAGE__-config(
# settings for all controllers using this base
'Catalyst::Controller::RHTMLO' = {
form_attr = 'HasForm',
form_action_class = 'MyApp::Action::RoseForm',
form_stash_name = 'formobj',
form_stash_hash = 'allforms',
form_prefix = 'MyApp::RoseForm',
},
# settings for specific controllers in MyApp
'Controller::Foo' = { # or 'C::Foo' if MyApp is built that way
form_prefix = 'MyApp::FooForms',
},
);
=over
=item Cform_action_class
Default: C'Catalyst::Controller::RHTMLO::Action'
If you want to add more functionality to the automatic form loading and
initialization, you can create your own custom action class:
package MyApp::Action::RoseForm;
use base 'Catalyst::Controller::RHTMLO::Action';
sub execute {
my $self = shift;
my ($controller, $c, @args) = @_;
# load forms via base class
$self-next::method(@_);
# do cool stuff
$c-stash-{form}-add_fields(
secure_token = {
type = 'hidden',
value = $c-some_cool_security_token
}
);
return;
}
=item Cform_attr
Default: C'Form'
Re: [Catalyst] mod_perl converts latin1 to utf8 !?
On Sun, Dec 28, 2008 at 12:17 PM, Bjørn-Helge Mevik b...@mevik.net wrote:
snip snip
I tried modifying Catalyst::Plugin::Unicode the following way:
062016150213:/usr/share/perl5/Catalyst/Plugin# diff Unicode.pm.orig Unicode.pm
3a4
use Encode qw(encode decode);
22c23
utf8::encode( $c-response-{body} );
---
encode('ISO-8859-1', $c-response-{body} );
38c39
utf8::decode($_) for ( ref($value) ? @{$value} : $value );
---
Encode::decode('ISO-8859-1', $_) for ( ref($value) ? @{$value} :
$value );
When running under the development server, this seemed to be a no-op:
everything still worked perfectly.
Under mod_perl, it was almost a no-op as well. The only difference
was that when entering non-ASCII letters in a form field and storing
it, the entered characters were now correctly handled -- however, any
_existing_ non-ASCII character now became stored in the data base as
UTF-8.
Here is my wild guess of what happened: in some circumstances the
internal representation of Perl strings can be latin1 - and if you
don't encode it when writing to the database you'll get latin1 in the
database - but for the most common case the internal representation
will be utf8 - and that you'll have in the db when writing to it
without any encoding. In theory you should not rely on that - because
it is *internal representation*. You need to encode every output
(and decode every input) that comes from the Perl program to the
outside world - including the database. For each output (input) you do
it separately and you can use different encoding (like UTF-8 for the
web pages and Latin-1 for the DB). Said that - I don't know much
about the practical side of that - for my work I just always use UTF-8
and pg_enable_utf8.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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/
[Catalyst] Dispatching in Catalyst::Controller::SOAP::DocumentLiteralWrapped
The POD for C::C::S::DLW says: A Document/Literal service is supposed to have one operation per bind, as it's not techically possible to dispatch on the content of the Body. In fact, as the Body is used as literal the dispatching should not even look at it, it should be based on the port that received the request. RPC/Literal, on the other hand, supports the use of several operations per bind, and the dispatching of this operations is based on the first and only child element of the message body, which defines the operation. The arguments are set as the parts of the message in the WSDL. Document/Literal-Wrapped is a deviation of both, as the message should be interpreted as Document/Lit- eral, but the dispatching requires an additional step of looking at the SOAPAction HTTP header, which will identify the proper operation to be dispatched. I am rather new to this SOAP affair - but according to http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ - the dispaching in Document/Literal-Wrapped should be done on the first and only child element of the message body, which defines the operation just like in the RPC/Literal case. Then formally you when you have a function of type A - ( B - C ) - i.e. the RPC/Literal case - where the first parameter defines what function is applied to the rest of arguments. Then you can always uncurry it to (A, B) - C - that is you can have a function that takes both parameters and returns the end result. So if you treat the dispatching as an internal affair in the server you can always say that the function is of the right type for Document/Literal. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Dispatching in Catalyst::Controller::SOAP::DocumentLiteralWrapped
On Fri, Nov 28, 2008 at 3:34 PM, Ian Sillitoe [EMAIL PROTECTED] wrote: I'm also new to this so any opinion is offered very much on a FWIW basis. I pretty much had this conversation the other day with ruoso on #catalyst - I don't have a copy of the logs but I'll provide a summary as I understood it. The document you pointed to (same document as I pointed to) is a good description of the different styles of WSDL. However, I was reminded that, regarding DocumentLiteralWrapped, this doc is really just an opinion since MS have provided no official specification for it (this is mentioned in the Where is doc/lit wrapped defined? section). Yeah - but if we look at it formally: since there is no official definition - then we should treat it as standard Document/Literal. And, I can be completely mistaken here as I don't know the full semantics of WSDL, but I have the hypothesis that this is possible using the trick of treating the dispatching as an internal affair of the server (and remembering that you can always uncurry a curried function). In other words, we can pretend to have just one operation of type: ( InternalOperation, Parameters ) - Output and treat the the dispatching to the InternalOperations as a part of the algorithm of this one official operation. But if we do that - then we cannot rely on anything outside of the Document/Literal specs (i.e. on the SOAPAction header). I certainly agree that it would be good to have C::C::S::DLW dispatching similar to RPC/Literal (name of the first child element) as that was my understanding of how it should work. Perhaps at least to allow this to be the default if no SOAPAction was explicitly provided. I could be wrong, but I also got the impression that the developers have already invested a fair amount of time providing this and maybe don't have tons of spare time for further development (especially supporting a style of WSDL that they clearly aren't very impressed by :). Basically that suggestions/fixes are probably best accompanied by suggested patches. Yeah - I just hoped to first validate my understanding, before sending any patches. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] OT: Use the CPAN, Luke? (was: Catalyst install failure due to Mouse.pm on Debian Etch)
On Thu, Nov 27, 2008 at 3:55 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Toby Corkindale [EMAIL PROTECTED] [2008-11-27 01:55]: The problem is the dependency Mouse (0.11) fails its unit tests there. That's really the sole solid argument against a flamboyant use-the-CPAN attitude: you end up pulling in heaps of bloat because none of the stuff was written to form a coherent whole: every author uses their own favourite way of doing some common thing so you get four different OO frameworks of varying heft, two different YAML modules, every JSON module there is, etc., all loaded into the same perl process. What a waste. Case in point, Mouse is essentially Moose Light. Since Catalyst itself is becoming Moose-based, is there *any* reason to use Mouse instead? I suppose if it automatically stubs itself into a Moose loader where Moose is available, that would be not *too* bad, but it's still a pointlessly added dependency. There is also Squirrel (http://search.cpan.org/~sartak/Mouse-0.11/lib/Squirrel.pm) - it loads Mouse unless Moose is already loaded (just citing the Synopsis). At the operating system level I've seen sometimes 'virtual packages' that decouple the services from packages that provide those services. So you can have a service 'sendmail' that actually is provided by the 'postfix' package. This level of compatibility between libraries is rather exceptional - I think that Moose and Mouse are the only examples so far, but maybe it is time to start thinking about that. CatalystX::CRUD tries to work with both RDBO and DBIC - the effect is a bit too heavyweight for my liking, but it is a bold experiment. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/
[Catalyst] Catalyst::Controller::SOAP no operation `index' for portType error
Hi,
I have a SOAP controller based on WSDL. Maybe I confused something
but I understood that I need to add
# this is the endpoint from where the RPC operations will be
# dispatched. This code won't be executed at all.
# See Catalyst::Controller::SOAP::RPC.
sub index :Local SOAP('RPCEndpoint') {}
to the controller (as described in the Synopsis). And then the
client will be allowed to call the root address and be despatched to
the right action based on the SOAP message (instead of using different
addresses for each action).
But with this addition compilation fails with the error: no operation
`index' for portType {urn:calculator}SMSPortType, pick from
Strictly speaking the message is true - there is no 'index' operation
defined in the WSDL - but I thought that this RPCEndpoint action would
be treated differently.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Water the grass roots, please
On Wed, Nov 12, 2008 at 9:41 PM, Matt S Trout [EMAIL PROTECTED] wrote: Perlbuzz was kind enough to post an article by jshirley providing a different view of Catalyst; I've lobbed it at reddit: http://www.reddit.com/r/programming/comments/7czb5/populist_not_dictatorial_the_catalyst_web/ OK - I voted for it. But doesn't it make us seem a bit desperate? I mean this direct invocation to mailing list subscribers not the article. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Success stories please
On Mon, Oct 6, 2008 at 1:01 AM, J. Shirley [EMAIL PROTECTED] wrote: Andy apparently just wanted to start a flamewar. This article is idiotic, the reasons more so. I'm disappointed in perlbuzz in general as it now holds the same amount of respect as getting my news from The National Inquirer. Nearly all the comments talk about Catalyst - looks like it is the number one player here - I don't see any reason to be defensive. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Search example in any docs?
On Tue, Sep 23, 2008 at 10:21 PM, Dr. Jennifer Nussbaum
[EMAIL PROTECTED] wrote:
--- On Tue, 9/23/08, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Hi there,
I am sure you are referring to
http://www.catalystframework.org/calendar/2007/16 :) I
don't really
know what you need, but I start that article with a very a
simple
solution:
my @records = $schema-ResultSet( 'MyTable'
)-search(
$reqest-params,
{ page = 1, rows = 5 }
);
Only after presenting that I start discussing what to do
when you need
to add some more complex predicates to the query and
propose a
solution to that.
Yes i did see that and i did try it, but i quickly found that i ran into all
sorts of problems. For example my params would usually include something
like a action param with the value Submit query, whihc doesnt work so
well when it hits the database ;-)
Perhaps something like: $params = $c-req-params; delete $params-{action}; ?
You further talk about the 'LIKE' queries etc. It must be my writing
skills or maybe I did a too big step between the simple solution and
the complex ones - but answering the question on how to extend the
basic search in a clean way was exactly the point of my article. If
you ask this question then I must have failed in my goal - so excuse
my persistance but I would like to persue it a bit further.
So here is a simple search with a 'LIKE' operator on mycolumn.
sub search_for_mycolumn {
my ( $self, $params ) = @_;
my %search_params = { mycolumn = { 'like' = '%' .
$params-{my_column} . '%' };
$self = $self-search( \%search_params );
return $self;
}
The key is that advanced_search will look for methods called
search_for_* and use them automatically for the search. You can
combine it with the exact matches (that you don't need to write any
additional method for) and any other complex predicates. The full
advantage of this technique might not be visible for simple cases like
this one - but I am sure that as soon as you add tags into that you'll
find it cleaner.
Now I think I should have written a full example - so that the reader
would see how the parts need to be assembled.
So your ResultSet class would be something like:
use base AdvancedSearch;
sub search_for_mycolumn {
my ( $self, $params ) = @_;
my %search_params = { mycolumn = { 'like' = '%' .
$params-{my_column} . '%' };
$self = $self-search( \%search_params );
return $self;
}
... (other complex searches here) ...
1;
And the code in your controller would be similar to:
my $params = $c-req-params;
delete $params-{action};
my $result_set = $c-model( 'MyModel')-ResultSet( 'MyTable' );
my @records = $result_set-advanced_search(
$params,
{ page = 1, rows = 5 }
);
Maybe an update would fit for the next Advent Calendar?
Cheers,
Zbigniew
___
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] Search example in any docs?
On Tue, Sep 23, 2008 at 9:38 PM, Dr. Jennifer Nussbaum
[EMAIL PROTECTED] wrote:
Hi.
Im working on a new app which is working well. While doing it though i
realised that i never get my serach done right. I mean, it works, but
i end up spending a lot of code munging parameters, making adjustments,
and so forth, and this cant be right. What should be a few lines takes a page
or two of code, just for a simple one or two table search.
I tried looking through the docs for a best-practices approach and unless i
missed something there arent ANY examples of search in the docs, the
tutorial, the wiki, the Advent (Oh in one place there was something about
harder searches, fulltext in PostGres, but nothing general.)
Is there any place that shows a simple example of a web form - DBIC search
in Catalyst? And if not, shouldnt there be?
Hi there,
I am sure you are referring to
http://www.catalystframework.org/calendar/2007/16 :) I don't really
know what you need, but I start that article with a very a simple
solution:
my @records = $schema-ResultSet( 'MyTable' )-search(
$reqest-params,
{ page = 1, rows = 5 }
);
Only after presenting that I start discussing what to do when you need
to add some more complex predicates to the query and propose a
solution to that.
Of course that article ignores the part of generating the HTML form
code and getting the parameters from $c - I had to concentrate on
somethign.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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/
[Catalyst] #catalyst
Hi there, I did not see how it looked like at the channel a few days ago - but I hope that my irc client malfunction did not offend someone too severly (unlike that famous wardrobe of some US pop singer). And that the bane for my home machine is not eternal and can be released soon. Looking forward for those passionate discussions, Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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/
[Catalyst] Failing tests in Catalyst::Controller::SOAP
Dear all, I have tried to install Catalyst::Controller::SOAP on both an Open SUSE 10.3 with Perl 5.8.8 and Ubuntu Hardy with the same Perl version. Both give the same errors as in the report at: http://www.nntp.perl.org/group/perl.cpan.testers/2008/09/msg2179625.html Can anyone with more knowledge of SOAP tell if that is something important? Cheers, Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] DBIx::Class method, update_or_create_related - it tries to populate the primary key value of the related object
On Mon, Aug 18, 2008 at 2:56 PM, [EMAIL PROTECTED] wrote: hello, all, I am trying to use DBIx::Class method, update_or_create_related to cut down the amount of code I have. My code has happily worked with 1) me manually doing a search (with find) to see if an object in question exists or not. If it doesn't, I will issue a new/create . Else, the find will give out the object, I perform whatever I need to perform on the attributes and update it. 2) the database table of the related object has a nice sequence set up for its primary key, ID. Now, when I tried to use update_or_create_related, the code actually produces an error for which the ID attribute in the SQL for INSERT is null and hence, cannot be inserted to the database engine for reason that a primary key attribute value can never be NULL. It's fair up there but I just do not know why is DBIX::Class even bothering to put the primary key value, ID into the dynamic SQL that it uses to insert the entry into the database when there's already a sequence declared for it It's a long story - you might have a look at: http://lists.scsys.co.uk/pipermail/dbix-class/2008-June/thread.html#6403 to see some discussion about it. I also posted some code for a DBIx::Class plugin with a modified update_or_create_related method (which should work for you and additionaly it allows for recursive updating the database). It is not really polished code - it requires some name changes - but it has test :) By the way - there is a separate DBIC mailing list (see the link above) where you should direct emails in thit subject. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Facebook Fund
On Fri, Aug 8, 2008 at 8:44 AM, Peter Edwards [EMAIL PROTECTED] wrote: Grants of $25k - $250k for writing Facebook apps. Tempted to write one with a Catalyst backend? And for those that do write Catalyst backed Facebook apps I've started a wiki page at: http://dev.catalystframework.org/wiki/gettingstarted/howtos/facebook_applications Competition begins August 29th: http://developers.facebook.com/fbFund.php Regards, Peter http://perl.dragonstaff.co.uk ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.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] Multiple inheritance of controllers
On Sat, Jun 14, 2008 at 12:24 AM, Byron Young [EMAIL PROTECTED] wrote:
I ran into the same problem. But I found that adding this to my controllers
that inherit from multiple controller base classes works as a work around:
use Class::C3;
sub create_action {
my $self = shift;
return $self-maybe::next::method(@_);
}
It's an annoying workaround, but I didn't have time to pursue the issue any
further :P Does anybody know why this might be happening?
Anyway, I hope that helps somewhat..
Unfortunately it did not help - and I encountered one more strange behaviour.
So basically I changed the test controller to:
===
package Base;
use strict;
use warnings;
use base qw/Catalyst::Controller/;
sub basefoo :Local { }
package Intermediate;
use strict;
use warnings;
use base qw/Catalyst::Controller Base/; # this one does not inherit
actions from Base
package TestApp::Controller::Action::Subclassed;
use strict;
use warnings;
use Class::C3;
sub create_action {
my $self = shift;
return $self-maybe::next::method(@_);
}
use base qw/Intermediate/;
1;
===
But I got following error:
t/subclassed..Inconsistent hierarchy during C3 merge of class
'Intermediate': merging failed on parent 'Catalyst::Controller' at
/usr/local/lib/perl/5.8.8/Class/C3/XS.pm line 64.
So I changed that to:
===
package Base2;
use strict;
use warnings;
use base qw/Catalyst::Controller/;
package Base;
use strict;
use warnings;
use base qw/Catalyst::Controller/;
sub basefoo :Local { }
package Intermediate;
use strict;
use warnings;
use base qw/Base2 Base/; # this one does not inherit actions from Base
package TestApp::Controller::Action::Subclassed;
use strict;
use warnings;
use Class::C3;
sub create_action {
my $self = shift;
return $self-maybe::next::method(@_);
}
use base qw/Intermediate/;
1;
Mysteriously this one compiles OK - but basefoo still is not inherited.
--
Zbigniew
Zbigniew Lukasiak wrote on 2008-06-13:
I've tried to build a module that would merge two base controllers and
then use it as another base controller. Unfortunately it looks like
only actions from the first base class in the 'use base ...' phrase are
being inherited:
I've created a test case for that - it is attached and I paste it
below for your convenience.
If someone sent me some instructions how to modify it to fit into the
Moose model I'll test it on the Moose branch as well (I am not sure if
they would be base controllers there at all - perhaps Roles instead?).
Cheers,
Zbigniew
package TestApp::Controller::Action::SubclassedChained;
use strict;
use warnings;
use base qw/Intermediate/;
1;
==
package Intermediate; use strict; use warnings;
use base qw/Catalyst::Controller::REST Base/; # this one does not
inherit actions from Base
#use base qw/Base Catalyst::Controller::REST/; # this one does
1; ==
package Base; use strict; use warnings;
use base qw/Catalyst::Controller/;
sub basefoo :CaptureArgs(1) :Chained('/') { }
sub baseendpoint :Args(1) :Chained('basefoo') { }
1;
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Actions as Moose::Role
On Mon, Jun 16, 2008 at 9:52 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, Jun 16, 2008 at 10:16 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Hi,
I wanted to start preparing for Catamoose and thought about extracting
some Controller code as Moose::Roles - but unfortunately Catalyst
attributes don't compile normally:
Invalid CODE attributes: CaptureArgs(1) : Chained('/') at t/lib/Base.pm line
7
In a simple class:
package Base;
use strict;
use warnings;
#use Moose::Role;
sub basefoo :CaptureArgs(1) :Chained('/') { }
sub baseendpoint :Args(1) :Chained('basefoo') { }
1;
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
Is it intentional to omit the use base 'Catalyst::Controller';?
Well - I was not sure about that - but with use base
'Catalyst::Controller'; I get:
Could not load class (Base) because : Can't locate object method
linearized_isa via package Moose::Meta::Role at
/home/zby/progs/Catalyst-Runtime/5.80/branches/moose/lib/Catalyst/ClassData.pm
line 23.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.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] Re: RFC: Catalyst::Controller::REST::DBIC
On Fri, May 16, 2008 at 12:06 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-05-16 06:25]: Hmm - frankly I have never thought out REST entirely - but I have the feeling that it is always better to be cautious (and you know - be liberal in what you receive). It's like Turing completeness: you can do everything RESTfully that you can do in any other way, you just have to model the problem in a way that fits the constraints. REST doesn't restrict what you can achieve at all, it just imposes some requirements on how you go about it. Some ideas top of my head: - a login method (the advantage would be that it does not need to redirect) I'm not sure I follow. You mean you want to have something like `/api/rest/cd/login`? And how do you avoid redirecting from that if you have `login` in the URI, which isn't where the client needs to be looking at? Yeah - I think you are right, that was just a quick one. - a search I tend to prefer expressing searches with query parameters… hm. I understand that what you propose is '/cd?year=1968', is that right? I really don't know - but some people would prefer to do the search by POST, or might just like to have the uri as '/cd/search?year=1968'. - exposing some class data (as opposed to instance data) and maybe class methods? Example? I can't quite imagine what you would want to do here. Hmm - how about a help screen - conveniently at '/cd/help'? In short I think '/cd/instance/1' style of URIs is less interferring with how people think about structuring their uris. If you do '/cd/1' then you force them to choose one way of doing everything - even if it is a Turing complete way and you can do everything in that style. -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Re: RFC: Catalyst::Controller::REST::DBIC
Hi, I don't know what to do with this thread. On Fri, May 16, 2008 at 6:31 PM, Dave Rolsky [EMAIL PROTECTED] wrote: On Fri, 16 May 2008, Zbigniew Lukasiak wrote: - a search I tend to prefer expressing searches with query parameters… hm. I understand that what you propose is '/cd?year=1968', is that right? I really don't know - but some people would prefer to do the search by POST, or might just like to have the uri as '/cd/search?year=1968'. Why would anyone care about GET vs POST? I guarantee most users don't care. If you mean they want to use a form, that has nothing to do with the method. Forms can submit GET requests. It might need to be a POST if you need to download a file as one of the search arguments (for example for searching for a similar picture). The URI you propose could be RESTful, if you think of search as a noun, maybe short for search results. OK - what I was argumenting about is that sometimes it is convenient to have an URI like that. The other part of the argument is that if you have an uri '/cd/search' - then you should not use '/cd/1' to retrieve the CD object - because then you mix data with commands (id with actions). Example? I can't quite imagine what you would want to do here. Hmm - how about a help screen - conveniently at '/cd/help'? Again, could be RESTful. Great. I am only argumenting that sometimes you need such an uri - see above. One part of REST is that URIs contain nouns, period. The type of nouns, the path hierarchy, all that is irrelevant, the key is that the URI never contains a verb like submit or edit. Note that edit_form is a noun, and is perfectly RESTful, and _necessary_ if you plan to have browsers interact with a set of RESTful URIs. As above. -- Zbigniew Lukasiak http://brudnopis.blogspot.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] RFC: Catalyst::Controller::REST::DBIC
Hi there,
This is a frequently recurring conversation - so I created a wiki page
to gather all the points where we reached some consensus:
http://catwiki.toeat.com/crud. For the start I just dumped my
opinions. I tried to be not controversial - but it is a wiki - if you
don't agree then you can edit it and make it more acceptable for you.
I am especially waiting for people with opinions on the REST and
browser REST part - I have got much knowledge in that area.
Cheers,
Zbigniew
On Sun, May 4, 2008 at 2:38 AM, luke saunders [EMAIL PROTECTED] wrote:
I have started to write a Catalyst base controller for REST style CRUD
via DBIC. I have noticed that a number of other people have been
working on or are thinking about working on something similar, most
notabley J. Shirley who seems to be creating
Catalyst::Controller::REST::DBIC::Item
(http://dev.catalystframework.org/svnweb/Catalyst/browse/Catalyst-Controller-REST-DBIC-Item/)
and some chaps from a recent thread on this list (entitled
Dispatching with Chained vs HTTP method).
Ideally I would like to merge J. Shirley's effort into mine (or visa
versa) along with anything that anyone else has. Basically I want to
avoid ending up with a load of modules that all do the same thing.
My effort is heavily based on something mst wrote a while ago, and
since then I've ended up writing something very similar for every
project I've worked on which indicates it's worth OSing. Essentially
it is used like so:
package MyApp::Controller::API::REST::CD;
use base qw/Catalyst::Controller::REST::DBIC/;
...
__PACKAGE__-config
( action = { setup = { PathPart = 'cd', Chained =
'/api/rest/rest_base' } },
class = 'RestTestDB::CD',
create_requires = ['artist', 'title', 'year' ],
update_allows = ['title', 'year']
);
And this gets you the following endpoints to fire requests at:
/api/rest/cd/create
/api/rest/cd/id/[cdid]/update
/api/rest/cd/id/[cdid]/delete
/api/rest/cd/id/[cdid]/add_to_rel/[relation]
/api/rest/cd/id/[cdid]/remove_from_rel/[relation]
The full source is here:
http://lukesaunders.me.uk/dists/Catalyst-Controller-REST-DBIC-1.00.tar.gz
If you have a few moments please have a look, especially if you are
working on something similar. Today I even wrote a test suite which
has a test app and is probably the best place to look to see what it
does.
Note that it lacks:
- list and view type methods which dump objects to JSON (or whatever)
- clever validation - it should validate based on the DBIC column
definitions but it doesn't
- any auth - not sure if it should or not, but it's possible
Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP
requests favouring instead entirely separate endpoints, but that's up
for discussion.
So, J. Shirley, do you have any interest in a merge? And others, do
you have ideas and would you like to contribute?
Thanks,
Luke.
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] RFC: Catalyst::Controller::REST::DBIC
On Thu, May 15, 2008 at 7:31 PM, Mark Trostler [EMAIL PROTECTED] wrote: You don't need 'create' 'update' 'delete' parts of your URL - those should be denoted by the request type - POST, PUT, or DELETE right? Yes - you are right about REST, but what something more than that. We want to have is a REST interface together with something REST-like that will work for browsers. Similarly you don't need 'id' in the url - so POST to /api/rest/cd will create a cd. A PUT to /api/rest/cd/5 will update that CD - a DELETE to /api/rest/cd/5 will delete that CD... Additionally we would like to have other non REST actions in the same controller. This mixing will require some separation between the method names and the object id (which is data). This is why I propose /cd/instance/5 for the retrieve action. -- Zbigniew ___ 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] Re: RFC: Catalyst::Controller::REST::DBIC
On Thu, May 15, 2008 at 11:11 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-05-15 21:25]: On Thu, May 15, 2008 at 7:31 PM, Mark Trostler [EMAIL PROTECTED] wrote: Similarly you don't need 'id' in the url - so POST to /api/rest/cd will create a cd. A PUT to /api/rest/cd/5 will update that CD - a DELETE to /api/rest/cd/5 will delete that CD... Additionally we would like to have other non REST actions in the same controller. This mixing will require some separation between the method names and the object id (which is data). You are thinking about it wrong. You don't put method names into the URI; you expose more of the state as things to manipulate. If you give an example of what you mean I can give you one of what I mean. Hmm - frankly I have never thought out REST entirely - but I have the feeling that it is always better to be cautious (and you know - be liberal in what you receive). Some ideas top of my head: - a login method (the advantage would be that it does not need to redirect) - a search - exposing some class data (as opposed to instance data) and maybe class methods? Cheers, Zbigniew Lukasiak http://brudnopis.blogspot.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] Dispatching with Chained vs HTTP method
On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale [EMAIL PROTECTED] wrote: Hi Adam, On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote: On 07/05/2008, at 11:05 AM, Toby Corkindale wrote: Ah, I was thinking of transactions vs a REST API, eg: PUT /user/1234/account_balance?subtract=1 POST /user/4567/account_balance?add=1 Since those are two separate HTTP requests, and REST specifically states you cannot maintain state on the server, how would you perform those two operations inside a transaction? (My solution is to implement it in one request, like: PUT /user/1234/money_transfer?user=4567;amount=1 However that is not CRUD-like, nor a direct mapping of DBIC functionality to REST) The solution suggested in Restful Web Services is to POST to a factory resource which creates you with a transaction resource. e.g. POST /transactions/account-transfer returns Location: /transactions/account-transfer/11a5, where the 11a5 is a unique transaction identifier. Then PUT /transactions/account-transfer/11a5/accounts/checking/11, where 11 is the account identifier. The body carries the transaction details, in the example the balances are adjusted absolutely, i.e. balance=150. A similar PUT is sent for the other account. Once the required components of the transaction have been PUT it is possible to rollback by DELETEing the transaction resource or commit it by putting committed=true to the resource. While seeming a bit fiddly, it does keep the state on the client and allows the client to make (at least some of) the commit / rollback decision rather than (only) the server. I've read parts of RESTful Web Services, but not that bit.. I'll have to go back and look. I wonder how one goes about implementing such a transaction on the server side.. One would not want to lock DB rows indefinitely, waiting for the client to finally complete the transaction. But if one just recorded the queries and then executed them all (internally) at the end, then other risks exist, eg: $id = POST transaction $amount = GET /user/1/account_balance $amount2 = GET /user/2/account_balance PUT /user/1/account_balance/$amount-1 PUT /user/2/account_balance/$amount+1 PUT transaction/$id?completed How about: $id = POST transaction PUT /transaction/$id/payer/1 PUT /transaction/$id/receiver/2 PUT /transaction/$id/amount/1 PUT /transaction/$id?completed or even $id = POST transaction PUT /transaction/$id?payer=1;receiver=2;amount=1 PUT /transaction/$id?completed And - yeah - looks like we have differnet goals. But I'll watch your project proceeding :) -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Catalyst / dbix-class / mysql / REST job
There were a few long threads on the subject of REST CRUD in Catalyst here. Maybe you would like to crowd source a bit - and make a competition for the code pieced that you need? Inspiration: http://www.ddj.com/architect/207404123?pgno=1 Cheers, Zbigniew On Wed, May 7, 2008 at 6:52 PM, Mark Trostler [EMAIL PROTECTED] wrote: The job description is kinda crapy: http://jobs.perl.org/job/8624 But you can work in Sunnyvale, CA or Carslbad, CA. The backend in Catalyst/REST/DBIx::Class/MySQL. Frontends are currently command line/library using Moose and lots of AJAXy Javascript (using ExtJS - yah should be YUI ideally...). Join the team! Mark ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Anybody who fancies some LWP poking ...
On Mon, May 5, 2008 at 11:12 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: If you don't want new versions of modules, then *don't upgrade them*. and when you (or a total newcomer to the language/framework) do a *new* install? and the latest greatest is broken right out of the box? looks great, hey? The code may have been broken - but not so broken that it couldn't work (acceptably) well in the last N releases. But, hey, all of a sudden, it must be changed *now*. There is a proposal from Michael Schwern for a Debian-like releases (unstable, test, stable and old-stable) http://www.perlfoundation.org/perl5/index.cgi?cpan_stability_project . I just thought this might be interesting to you. -- Zbigniew Lukasiak http://brudnopis.blogspot.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] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 6:19 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Mon, May 5, 2008 at 8:18 AM, Andrew Rodland [EMAIL PROTECTED] wrote:
On Monday 05 May 2008 09:50:08 am J. Shirley wrote:
On Mon, May 5, 2008 at 4:31 AM, Matt S Trout [EMAIL PROTECTED] wrote:
On Sun, May 04, 2008 at 09:06:30AM -0700, J. Shirley wrote:
I fail to see how whether the PK is the lookup key or not has any
relevance at all to the original point, which was your lookup key
and
names of actions might clash so it can be nice to have an extra path
component such as 'id' for the lookup part to disambiguate.
Because I'm talking about REST and a verb in the URI doesn't need to be
there.
But those nouns you're talking about aren't verbs at all.
Andrew
How is /create, /edit or /delete not a verb?
My argument is separate to the /create is valid in the /foo/{token}
bit. I'm saying that /foo/create is silly to have in the first place,
and the /foo/id/{id} is nothing more than a conversion from named
parameters to positional, and ugly.
If you apply actual REST principles, you don't have such nonsense.
But again, as I said, this is if you are working with REST. If REST
doesn't fit your application model, don't use it. Just don't name
things REST when they are really CRUD.
The point is about having something that will work as REST for
automated agents and also work for browsers by some emulation or what
ever - so you'll have some additional actions on the controller as
well. Additionally if we really want to make this REST Role (assuming
Moose Catalyst by that time) - then the user of the library can have
his own actions. In both way you'll have a clash if we go your way.
Because /foo/id/{id} looks like a parameter - which is the only
argument agains it and is just a bit of pedantry on your side - you
would allow for broken logic?
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 6:06 PM, J. Shirley [EMAIL PROTECTED] wrote:
On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
Sorry but I don't understand your point - so maybe first I'll restate
mine. If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
My point is that you do not have to use the primary key as the record
lookup identifier.
A user has no control over the record lookup identifier (ID) when you
do things like /user/{primary_key} (or /user/id/{primary_key}, which
is just converting named params to positional in a weird way). In a
lot of cases, the record lookup identifier makes more sense to be
somewhat bound to the user. As an example, lets say registering for a
web service where you have to have a unique login:
POST /user/jshirley
---
login: jshirley
first_name: Jay
last_name: Shirley
...
Now, it's a simple check here - does /user/jshirley exist? If so,
reject the request appropriately. If not, create the user at
/user/jshirley.
The primary key that the database uses is completely useless to the
user. /user/1634254 is silly, /user/jshirley is meaningful.
If the ID is generated, that gets a bit trickier but I usually handle
that with a POST to /user with the data and then let the application
forward me to the final URL of where the resource exists.
The other reason is that this system breaks when you no longer have
records tied to a database. As an example, if you use an md5 sum of a
file as the identifier. /file/1234 doesn't work because it isn't in a
database under that system (think of a MogileFS cluster or something
with hash keys rather than primary keys in the conventional sense) -
instead /file/{md5sum} is used.
In brief summary, over-utilization of primary keys as record lookup
identifiers ends up diminishing the human readability and
accessibility of your web service. I'm not trying to win over any
converts, because I think there is a time and a place for each (even
in the same application, it just depends upon what each action is
really doing). If I'm not building something that is REST/webservice
driven I tend to do the /user/{id or token} (with a simple regex to
check, and if someone has a login of all numbers then screw 'em) - but
it's a very different strategy when I work with webservices -- each
time I always make sure if the record lookup indicator should be the
primary key, and what cases should it not and then react accordingly.
Then we are talking about two diffrent things. My point is that you
should not have /foo/create and foo/{id or token} - because you mix a
reserverd work 'create' with data, you can never guarantee that the
data, be it primary key or token or whatever, does not contain
'create'.
I do understand that in full REST design you would not have a
'/foo/create/' uri - but if you want to add this REST as an add-on to
a controller you'll still have other methods on the controller that
could conflict with the token/id.
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Dispatching with Chained vs HTTP method
Hi Toby,
I don't know if you are aware - but building a REST-like CRUD
interface to DBIx::Schema is my long term goal (started with
Catalyst::Example::InstantCRUD). Do you think we could collaborate?
Cheers,
Zbyszek
On Wed, Apr 30, 2008 at 10:26 AM, Toby Corkindale [EMAIL PROTECTED] wrote:
just looking for some advice on the best way to do something..
So I wrote a controller class using Chained that basically auto-converts any
DBIx::Schema (which includes a tiny extra base class itself) into a REST
API..
Well, a simple one anyway - it supports find and search so far, and foreign
keys in the objects get serialised into hashes of the URIs to fetch them.
All working nicely so far, but this is all for GET queries.
But the behaviour should be different depending upon whether you
GET /item/1234
or
DELETE /item/1234
etc.
I was thinking something like this: (Abbreviated code below)
sub item_by_id : Chained CaptureArgs(2) {
my ($self, $c, $type, $id) = @_;
$c-stash-{item} = $c-model(DB:$type)-find($id);
}
sub delete : Chained('item_by_id') Args ActionClass('MethodDELETE') {
my ($self, $c) = @_;
$c-stash-{item}-delete;
}
sub modify : Chained('item_by_id') Args ActionClass('MethodPUT') {
my ($self, $c) = @_;
$c-stash-{item}-update($c-request-params);
}
Then the appropriate ActionClasses would check if the $c-req-method eq
'GET'
or 'DELETE' or whatever.
But I was just wondering if you had other ideas, and if using ActionClasses
with Chained actions is crackfuelled and going to lead to a world of misery
and
pain.
Cheers!
Toby
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Dispatching with Chained vs HTTP method
On Wed, Apr 30, 2008 at 11:46 AM, Moritz Onken [EMAIL PROTECTED] wrote: Hi Zbyszek, do you plan FormFu support? In case the submitted values are not valid the response is a xml/json/whatever which includes the error messages. That would be really great :) I have not yet settled down with the choice of the form processor. I've started with FormFu - but now I am playing with Rose::HTML::Form - and I found it much more flexible. -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Sending email safely with Catalyst
On Sat, Apr 12, 2008 at 1:06 AM, Dave Rolsky [EMAIL PROTECTED] wrote: On Fri, 11 Apr 2008, Jonathan Rockway wrote: In an ideal world, you should be able to dump the messages into your mail system's queue as quickly as you can dump them into a database table (adding to the mail queue is a disk write, adding to a database is a disk write, unless you've turned off data integrity). I could see how calculating the text of 1 mail messages during a request would be slow, but why would you want to do that? Usually you'll just want to say Your account was created, [% name %]! and queue that. The template rendering and the mail system's queue should be more than fast enough to handle that during a request. As for bulk emails, you probably have a process that calculates those outside of your Catalyst app anyway (running from cron), so calculate them, dump them into the mail queue, and let your mailer daemon figure out what to do. Much better than putting a queue in front of a queue, IMHO. This is UNIX after all. The big problem I've run into when sending lots of emails from a web app (just hundreds, in this case), is that it can be slow enough the browser times out. Presumably you could have a similar problem with a work queue as well. Ultimately, I suspect a solution that forks _immediately_ and then does its thing (whatever that thing may be) is going to be necessary past a certain scale. Then the trick becomes monitoring that forked process. Another solution might be to come up with a way to queue up the job with a single write and do the full email generation via cron. Either way, you have to add complexity to your app if you want to provide feedback on the job status to the user. I'll be working on this soon for an app I'm creating, and I suspect I'll go the route of doing a single insert and processing via a cron job. The upside of this is that for a multi-user app, I won't end up forking a whole bunch of email sending processes and I can exercise some control over the rate that email is generated. My first approach was to do the sending in a cron job - but then came the requirement that the emails should be sent as soon as possible. Now I have a forking model, but I don't know if I implemented it correctly (the mod_perl guide recommends against forking http://modperlbook.org/html/10-2-Forking-and-Executing-Subprocessesfrom-mod_perl.html). I am also contemplating a compromise of sending the first few emails immediately and the rest from a cron job. -dave /*== VegGuide.Org Your guide to all that's veg ==*/ ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Sending email safely with Catalyst
On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote: I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Sending email safely with Catalyst
On Fri, Apr 11, 2008 at 4:49 PM, J. Shirley [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 3:51 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote: On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote: I see there's an Email plugin and wondered if this is enough to send email from a form safely securely or whether something more involved like a port of NMS CGI exists? http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm http://nms-cgi.sourceforge.net/ It's terribly easy to get this wrong so wanted some feedback from people who'd previously implemented something like this live before inadvertently turning my site into a spam conduit :-) I've got a related question - does anyone send bulk emails with that plugin? Is the delay reasonable when sending let's say a hundred emails or do I need a background mechanism for that? I have now a forking solution - but it is a bit complex (and for mod_perl they recommend to do it in a 'cleanup' handler instead of a forked process). I've been dying to play with http://search.cpan.org/~btrott/Email-Send-TheSchwartz-0.01/lib/Email/Send/TheSchwartz.pm I like TheSchwartz because it's fairly simple, easy to get going and... has this module ready. I'm hoping to have a reason to play with it in the next couple of months. This is interesting - but the documentation unfortunately does not answer following questions: - The worker looks like a polling daemon - how often does it poll the database? Would it be feasible solution on an SQLite database (which does not work very well with many concurrent connections). - How should I run the worker process so that it does not die unexpectedly? Should I put it into inittab or perhaps should I run it in a pair of processes that would fork another one if one of them dies? -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Re: Catalyst-Manual-FAQ Addition
On Wed, Apr 2, 2008 at 2:27 PM, Paul Makepeace [EMAIL PROTECTED] wrote: On Mon, Mar 31, 2008 at 7:09 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Russell Jurney [EMAIL PROTECTED] [2008-03-31 14:30]: I discovered that 'call' is a reserved word for Catalyst controllers, and any subroutines in a controller named 'call' will be ignored. OK, but… So, attached is a patched Catalyst::Manual::FAQ indicating this condition. … err, how is your question a frequently asked one? There would be some good mileage out of Catalyst::Manual::Gotchas Just brainstorming: How about first creating it at the wiki first - and distill it into a POD document only after it accumulates some more useful info. -- Zbigniew Lukasiak http://brudnopis.blogspot.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] not working URLS
Check the new Catalyst wiki: http://catwiki.toeat.com/. It'll become the official one soon. -- Zbigniew On Thu, Mar 13, 2008 at 6:37 AM, Octavian Rasnita [EMAIL PROTECTED] wrote: Hi, On the page http://dev.catalystframework.org/wiki/Faq_ref#sc.1 In the section Best practices there is a link to: http://home.ngmedia.net/chansen/catalyst/conf/ that doesn't seem to display anything related to Catalyst. If somebody know if I could find the content of that page somewhere, please let me know. That page should contain set of web server configurations that you can build your environment from. (samples for Apache 1.3, 2.0, and lighttpd utilizing mod_perl, speedycgi, fastcgi, and standard cgi) Thanks. Octavian ___ 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 12:33 PM, Kieren Diment [EMAIL PROTECTED] wrote:
On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:
After some more playing with CatalystX::CRUD I think I can formulate
my arguments a bit more clearly.
OK, bear in mind that you're competing with Reaction here. Reaction
has some promise, but its development is slow so far (for casual
users anyway), and it may suffer from some of the hyperverbosity and/
or (superficially) excessive indirection that is endemic in
enterprise ready™ software. I'm not qualified to comment further on
this.
Yeah - I hope there is a room for two competitors here.
I believe the objects that users of CatalystX::CRUD get in their
controller should be the real things - i.e. objects from their models
not CatalystX::CRUD::Model::Objects. This would be the minimal
interface and minimal hassle for injecting CatalystX::CRUD::Controller
actions to a legacy Catalyst controller.
What I particularly like about InstantCRUD is that everything is
spelled out nicely for the coder once they run the helper. That is,
mostly once you've been through the catalyst learning curve, the
instantcrud learning curve isn't very much more at all.
InstantCRUD's main problem is HTML::Widget, and secondarily the lack
of many-to-many introspection. I'm not sure how big the problem with
the tight coupling with DBIC is - I'd like to see a shitfight between
merlyn and mst, with zby as mediator to straighten that one out. Or
maybe between merlyn and zby with mst mediating ...
I think it would be best to be able to treat a CatalystX::CRUD
application like any other catalyst application. That is, minimal
modification of $c-model('Foo') compared to an ordinary catalyst app
so that the CRUD generator mostly gets out of the way.
Just thinking how this can be done - you need a
CatalystX::CRUD::ModelAdaptor:: and a model_adaptor_class config
option for the CRUD controller. Then in the controller methods you
would do:
$c-stash-{object} = $self-model_adaptor-fetch( @arg );
instead of
$c-stash-{object} = $c-model( $self-model_name )-fetch(@arg);
and in places where you call methods on the object like: $obj-$method
you could do again $self-model_adaptor-$method( $obj ).
This way $c-stash-{object} could still be an unmodified object from
the model and you would have your indirection layer needed to make the
CRUD methods universal.
Cheers
Zbigniew
For bonus points I'd like to see a REST service available by default,
with a browser based service available on top of this. This way we
get the API for free and the browser UI gets to forward to the REST
API (with suitable massaging of the stash).
___
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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 4:27 PM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
On Wed, Mar 12, 2008 at 4:12 PM, Peter Karman [EMAIL PROTECTED] wrote:
On 03/12/2008 09:44 AM, Zbigniew Lukasiak wrote:
So we'd have:
sub thing : Local {
my ($self, $c, $id) = @_;
my $thing = $c-model('Foo')-fetch( id = $id );
my $thing = $self-model_adaptor-fetch( id = $id );
The model adaptor should know the model it is using (and in the case
of DBIC also the table )
In my example, $self is not a CX::CRUD::Controller. Just a plain ol'
Catalyst::Controller.
Why must it implement a model_adaptor method then?
OK - so that was just a misunderstanding - I thought we were still
talking about the CRUD methods.
$c-stash-{object} = $thing; # NOT a CX::CRUD::Object
}
and if wanted to update $thing:
$c-model('Foo')-update( $thing );
$self-model_adaptor-update( $thing );
I could live with that. Does it meet your needs? Does it make it
easier to implement a
DBIC model and FormFu controller?
Yes. In general - my point is that let's do the wrapping only for the
CRUD methods that need them. Let's not force the user to use the CRUD
wrappers as their models.
Users of CX::CRUD Models or Controllers don't have to use both together.
It's just easier
if they do. And CX::CRUD doesn't force you to only use its models.
You could have:
lib/MyApp/Model/Foo.pm # not a CX::CRUD::Model. Just a DBIC::Schema
model.
lib/MyApp/Model/FooCRUD.pm # is a CX::CRUD::Model::DBIC
MyApp::Model::FooCRUD can act like your ModelAdaptor. By adding yet
another kind of thing,
a model adaptor, into the mix, that feels more complex to me rather than
less.
If you'd make them to use the same db connection than indeed this
would be like the ModelAdaptor. But then again you should have just on
adaptor per model type - not per table (for models with tables).
That should be: just one adaptor class per model type (class).
I think I'm agreeing with you that the CX::CRUD API could be simplified,
that the ::Object
class could go away, and that the Model class could take over the c/r/u/d
methods that
Object currently performs.
Yeah - I would consider the objects on the stash as part of the
interface so they should be the original ORM objects.
If you like the model_adaptor() syntax in the Controller API, how would
you implement a
ModelAdaptor class and how would you change the Controller API to use it?
--
Peter Karman . [EMAIL PROTECTED] . http://peknet.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/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Instant CRUD with DBIC::Schema
On Wed, Mar 12, 2008 at 8:07 PM, Peter Karman [EMAIL PROTECTED] wrote: On 03/12/2008 01:24 PM, Zbigniew Lukasiak wrote: We are closing to it. Basically the adaptor needs to store the table name in it's instance - that's all. So one adaptor per table? How is that different than one model per table? It is one instance of adaptor per table instead of one class of adaptors per table. -- Peter Karman . [EMAIL PROTECTED] . http://peknet.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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Instant CRUD with DBIC::Schema
Hi Peter, On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman [EMAIL PROTECTED] wrote: Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated. I had today another look at CatalystX::CRUD - it is promising, but I think there is too many indirection layers in it. For DBIC it requires configuration of both CatalystX::CRUD::Model::DBIC and CatalystX::CRUD::Object::DBIC. I believe it could work with just one - for example CatalystX::CRUD::Model::DBIC where you could configure what methods on the object and how to call them to implement the needed interface. Or perhaps you could all of it move to CatalystX::CRUD::Model and add configuration to interface it to DBIC and RDBO - they are not that different. What do you think? I believe some reduction of the number of modules used will simplify the whole thing. Maybe we could start the discussion with what you interface you need from the database model? -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Base controllers and multiple inheritance
I would say don't use Catalyst::Controller::HTML::FormFu in that case - the functionality it provides is rather basic. By the way I am also working on a FormFu based CRUD Catalyst base class (continuation of Catalyst::Example::InstantCRUD). Looks like it has become fashionable thing recently. -- Zbigniew On Wed, Mar 5, 2008 at 8:36 AM, Byron Young [EMAIL PROTECTED] wrote: Hi, I've been using Catalyst for a project and decided to make some base controllers for common functionality. So far I've made two: CRUD, and List, for standard database operations and for sortable, paged listings of data. They work fine on their own but I'm running into trouble with multiple inheritance. If I have a controller for some database table that I want to inherit the actions from both CRUD and List, only the first one inherited will initialize properly. The inheritance looks like this: Catalyst::Controller /\ / \ /\ /Catalyst::Controller::HTML::FormFu / | MyApp::Base::Controller::List | \ | \MyApp::Base::Controller::CRUD \/ \ / \/ MyApp::Controller::SomeDatabaseTable Each of the controller base classes has a new() method which sets up config data and does error checking and whatnot. If I inherit both of my base classes, only new() on the first inherited is called. I've tried calling $class-NEXT::new(@_) in each, and I've also tried Class::C3's $class-maybe::next::method(@_), but new() is still not called down the second inheritance chain. When I tried the Class::C3 approach I called Class::C3::initialize() in MyApp.pm - I wasn't sure where to call it so I tried before and after MyApp-setup() - still no luck. Can somebody tell me why new() isn't called down both paths? Thanks, 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Doing work inside the DBIx::Class model
On Thu, Feb 21, 2008 at 9:17 AM, Peter Sørensen [EMAIL PROTECTED] wrote:
He meant result_source:
http://cpan.uwinnipeg.ca/htdocs/DBIx-Class/DBIx/Class/ResultSet.html#result_source
But this is not all and it is something that begs for a FAQ entry - I
always forget how to do it. The important thing is how to add new methods
to the ResultSet:
package ArchivedBooks;
use base qw/DBIx::Class/;
__PACKAGE__-table('books_archive');
__PACKAGE__-source_name('Books');
__PACKAGE__-resultset_class('ArchivedBooks::ResultSet');
package ArchivedBooks::ResultSet;
use strict;
use warnings;
use base qw( DBIx::Class::ResultSet );
sub advanced_search {
my ( $self, $params, $attrs ) = @_;
$self now is a ResultSet - so you can use methods on it.
..
I have a similar problem want - to add some custom methods to the model.
I've read
your references but still - I can't get this thing to work.
I have generated the model using Catalyst and get the following layout:
LogParser.pm
LogParser
|
|Components.pm
|Connectinfo.pm
|Logtype.pm
and if I take a look into Components it looks like:
package LogParser::Schema::LogParserDB::Components;
use strict;
use warnings;
use base 'DBIx::Class';
__PACKAGE__-load_components(Core);
__PACKAGE__-table(components);
__PACKAGE__-add_columns(
id,
{ data_type = INT, default_value = undef, is_nullable = 0, size = 11
},
component,
{ data_type = VARCHAR, default_value = , is_nullable = 0, size = 32
},
regex,
{ data_type = TEXT, default_value = , is_nullable = 0, size = 65535
},
nvars,
{ data_type = INT, default_value = 1, is_nullable = 0, size = 10 },
varnames,
{ data_type = VARCHAR, default_value = , is_nullable = 0, size = 64
},
);
__PACKAGE__-set_primary_key(id);
# Created by DBIx::Class::Schema::Loader v0.04004 @ 2008-02-12 17:08:38
# DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:gkSc31rRGpYHxL8tAAd/kw
# You can replace this text with custom content, and it will be preserved on
regeneration
1;
As I understand I have to add to above:
__PACKAGE__-source_name('SomeName');
This looks like a mistake to me - I did not mention source_name
anywhere - I don't know what this is for.
__PACKAGE__-resultset_class('Components::ResultSet');
LogParser::Schema::LogParserDB::Components;ame
And what is this?
and create a new package with:
I usually just add this package to the same file as the source package
- in this case to Components.pm.
package LogParser::Schema::LogParserDB::Components::ResultSet;
use strict;
use warnings;
use base qw( DBIx::Class::ResultSet );
sub advanced_search {
my ( $self, $params, $attrs ) = @_;
}
1;
So I created Components/ResultSet.pm with this content.
But it fails with :
Couldn't instantiate component LogParser::Model::LogParserDB, Cannot load
schema class 'LogParser::Schema::LogParserDB': Can't locate object method
source_name via package
LogParser::Schema::LogParserDB::Components::ResultSet at
/usr/lib/perl5/site_perl/5.8.5/DBIx/Class/Schema.pm line 301.
I tried to remove the line:
__PACKAGE__-source_name('SomeName');
but still same problem.
As I read the docs the meaning of this is to use another name than the
default name so why use it???
see above
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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] Calendar for Catalyst application?...
On Feb 17, 2008 8:14 PM, Alex Povolotsky [EMAIL PROTECTED] wrote: Hello! I recall I've seen somewhere calendar plugin for catalyst applications, but I cannot find one. Maybe someone will point me to a missing link?... Some very basic support you can get with Template::Plugin::Calendar::Simple (assuming you use TT). Zbigniew http://brudnopis.blogspot.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] Instant CRUD with DBIC::Schema
Are you talking about Catalyst::Example::InstantCRUD? It uses DBIC - see at CPAN. It is still a bit outdated though - I have to admit that. I have plans to port it to use HTML::FormFu. Cheers, Zbigniew On Wed, Feb 20, 2008 at 4:17 PM, Alex Povolotsky [EMAIL PROTECTED] wrote: Hello! Scaffold seems to be a good thing, but it is using CDBI. Maybe something like it with DBIC exists? 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/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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] Re: REST - like uri design for CRUD
On Jan 22, 2008 8:25 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote: On Jan 22, 2008 1:30 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-01-21 07:40]: While we are at that - I do understand the need to divide the operations into the 'indempotent' and 'non-indempotent' classes (because of caching and predictive link loading) - but what is really the practical argument for having two more classes (PUT and DELETE)? I don't understand this question. It sounds like you have some confusion about several distinct things and that you don't actually understand what idempotence is. Can you try to explain a bit more what you are trying to ask? Are you just asking why there are more verbs than GET and POST? Are you asking about why it's important to categorise verbs as non-/safe in addition to non-/idempotent? Is it something all together different? The first one. Why you need to split the class of non-idempotent operations into three more categories (POST, PUT and DELETE). Just after sending it I have realized that DELETE can be also viewed as idempotent since a second call to it does not really change the state (even if it can return an error to the caller). And that shows another question - perhaps all we need is the simple division into safe and non-safe operations? -- Z. ___ 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] REST - like uri design for CRUD
I know this has been discussed already - but I can't find it in the archives. What I conjured is: /class/search /class/id//view /class/id//update /class/create Update and create use really the same logic and templates - so I just forward to a create_or_update action from them. What are your opinions? -- Zbigniew Lukasiak http://perlalchemy.blogspot.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] REST - like uri design for CRUD
On Jan 20, 2008 10:33 PM, Thomas L. Shinnick [EMAIL PROTECTED] wrote: At 01:56 PM 1/20/2008, Zbigniew Lukasiak wrote: I know this has been discussed already - but I can't find it in the archives. What I conjured is: /class/search /class/id//view /class/id//update /class/create Update and create use really the same logic and templates - so I just forward to a create_or_update action from them. What are your opinions? -- Zbigniew Lukasiak spew register=pedant The book RESTful Web Services has been very useful to me in understanding the confusion about what REST means when it comes to 'verbs'. And that I'm interested in how close one can come to 'strict' REST design using Catalyst. One important topic in the book is that people mix 'verbs' into their URIs when they shouldn't, or at least when they don't _have_ to. Using the book's concepts your URIs would become 1) GET/class?pattern=breadbox 2) GET/class/id/ 3) PUT/class/id/ 4) POST /class While we are at that - I do understand the need to divide the operations into the 'indempotent' and 'non-indempotent' classes (because of caching and predictive link loading) - but what is really the practical argument for having two more classes (PUT and DELETE)? Cheers, Zbigniew 1) is your /class/search and says let me retrieve the representation/list of the items selected by searching for the given pattern, where the base URI would indicate the set/list of items, and the pattern is kept in the query parameters because it could be anything. Note that the idea is that GET /class references the list of all items, and you here are just qualifying that search with the pattern. 2) Your /class/id//view would be seen in strict REST as just a GET of /class/id/. The HTTP 'verb' GET already says give me a representation of the item. Done. 3) Your /class/id//update would become a PUT of /class/id/, where the new representation coming from the remote client would _replace_ the old representation/data for that item. This strict use of the HTTP 'PUT' verb is actually the hardest to accomplish, as it assumes that the remote client can receive and update a representation on the client, and then send it back using PUT. It is easiest to picture this usage when the client completely replaces the old representation held on the server. (see farther below for why) 4) Your /class/create becomes a POST to /class. This was another concept brought out by the book. The matter of who determines the item's 'id' is important. Here we assume that the _server_ will determine the id of the new added item. You do a POST to the base URI of the data area, and the server determines the new id, stores the data into the item, and does a redirect to tell the remote client where the new item is, that is, what is the new item's URI, for instance /class/id/1234. Why is who determines the id important? Because it says what HTTP verb you should use to create a new item. If the server, you use POST to add another item. (Much discussion of that most misunderstood of HTTP methods: POST in the book) But if the remote client were to determine the id, say because the id is a license plate number input at the client, then strict REST would say the client should do a PUT to /class/id/STRWBYP and the client would send the complete data for the item. The server would create the item using the id 'STRWBYP as requested by the client. Creation using POST would say create a new item and tell me (the client) where you (the server) put it. Creation using PUT defines where to put it to the server, because the client knows what the id should be. So under some designs it is possible that PUT will be used for both creation of new items and update (replacement) of existing items. In both these cases (under such a design) the client knows the correct id for the item. Anyway this spew was prompted by the new pedant seeing 'REST' in the subject and then no mention of 'PUT', etc. The book tries to be clear that it depends on both your design and the capabilities of the client whether you can implement using the strict REST HTTP verb set GET, PUT, and POST, or whether you must compromise on a REST-like set of GET and POST. The authors discuss how to overload POST to effect PUT-like usage, because we have to implement in the real world. But they are clear about the goals of RESTful design, the problems it solves, and the benefits it brings in the real world. It looks to be very useful to consider URI design with a view towards how would I accomplish this by splitting my data objects into URI addressable data that can be manipulated using the full set of HTTP verbs GET, PUT, POST and HEAD. (And not putting verbs into URIs that might be cached) /spew ___ List: Catalyst@lists.scsys.co.uk Listinfo
Re: [Catalyst] [OT] ASP.NET MVC#
On Dec 21, 2007 10:22 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: i'm not completely following the new syntax that you are proposing, so please forgive if I am wide of the mark here ... but ... IMO the existing syntax is really not *that* bad - the only mild crit I have is that Args() really means I'm an endpoint, which it doesn't say. For me, a simple improvement would be to allow an alternative name such as EndpointArgs that is a bit more obvious, and keep the rest just as it is. My argument really is that the number of parameters an action takes is independent from the fact that it is an end point or is not, and that you should not have one attribute that carries both of those meanings. So my latest proposal is to use Args to indicate the numer of parameters an action takes (just like you do it now, but also when you now use CaptureArgs) and IsParent to indicate that you can attach other actions to it. I worry a bit that two syntaxes, achieving the same thing but looking quite different to each other, and both coexisting in docs, mailing lists, and code, are just going to add more potential confusion than they clear up. Understood. If my proposal gets accepted I volunteer to purge CaptureArgs from the docs (and the Ministry of Love will go after those that mention CaptureArgs on the mailing lists). I think my proposal is really minimal - in fact I would say it does not introduce more new things than your 'simple improvement' above. Cheers, Zbigniew Lukasiak http://perlalchemy.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
Or maybe a better idea would be to use IsParent (or Parent) for those actions that can have children (logical isn't it?). Then we could use Args all the time instead of CaptureArgs (with EndPoint). Z. On Dec 20, 2007 12:31 PM, Matt S Trout [EMAIL PROTECTED] wrote: On Wed, Dec 19, 2007 at 02:18:17PM +, Zbigniew Lukasiak wrote: On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... A proof of concept implementation is in Catalyst::Controller::PathPart. It replaces the attributes at parsing time, I guess this would not be appropriate for the core of Catalyst. I am now going to port that change into lib/Catalyst/DispatchType/Chained.pm. I am not sure I'll be able to do it though. Remember you can't break backcompat in the process either ... -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... A proof of concept implementation is in Catalyst::Controller::PathPart. It replaces the attributes at parsing time, I guess this would not be appropriate for the core of Catalyst. I am now going to port that change into lib/Catalyst/DispatchType/Chained.pm. I am not sure I'll be able to do it though. Cheers, Zbigniew http://perlalchemy.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC#
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote: On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote: Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). I don't remember seeing the code - if you update your patch to work against 5.80 trunk we can have a look ... Ok - so I attach a patch (it is against http://dev.catalyst.perl.org/repos/Catalyst/branches/current/Catalyst-Runtime - I hope that is the 5.80 trunk - if not tell me and I'll change it). It passes the tests. In two cases when the test application uses the original TestApp::Controller::Action::Chained::* instead of TestApp::Controller::Action::ChainedEndPoint::* - I think this is due to how the test application is build. I've marked those cases in the test file and modified the tests so that they pass. For the tests I've copied the tests of live_component_controller_action_chained.t and adopted it to test TestApp::Controller::Action::ChainedEndPoint instead of TestApp::Controller::Action::Chained. So - what do you think? Zbigniew http://perlalchemy.blogspot.com/ ChainedEndPoint.diff.gz Description: GNU Zip compressed data ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] ASP.NET MVC
On Dec 17, 2007 4:03 PM, Daniel McBrearty [EMAIL PROTECTED] wrote: The chained thing is probably the single most useful thing in cat IMO (if it's possible to even make such a dumb call ;) The way I have come to see it (it took a while, reading discussions here helped me grasp this) is that the way you design your URI space is very very fundamental to design of a web app. Chained helps you to remember this and try to get it right at the start. It also makes the decision about what actions go in what controllers separate from decisions about URI namespace. (I haven't really figured out if that is entirely a good thing or not, but it seems helpful.) The syntax *is* a bit hard to get used to at first - I find that the important thing is to remember that Args() defines an endpoint (hope I am remembering that right), other than that take a good look at what Yeah - some time ago I proposed to add an EndPoint attribute and get rid of the CaptureArgs one that is not very intuitive (and use Args in both cases). -- Zbigniew Lukasiak http://brudnopis.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Input/Parameter Checks
You might have a look at http://www.perlfoundation.org/perl5/index.cgi?form_processing - you'll find there the most popular parameter validation modules. By the way if you use SQL queries with placeholders you don't need to fear SQL injection attacks. Cheers, Zbyszek On Dec 13, 2007 9:21 PM, Mesdaq, Ali [EMAIL PROTECTED] wrote: Anyone have some suggestions or references to good modules or best practices in this regards? This is mainly in regards to using these inputs in sql queries or other areas where common attacks against web applications happen. I wonder in the catalyst world what best practices are. Would it be a catalyst plugin that would best fit that role or a module that gets used in the controller possibly maybe just some code in the model? It just feels like its one of those things that has been solved by someone else way better than I would have done it and I am just not aware of it. Kinda like when I wrote my own logging module because at the time I didn't find a good one then I stumble accross log4perl and realize how badly I wasted my time! Thanks, -- Ali Mesdaq (CISSP, GIAC-GREM) Security Researcher II Websense Security Labs http://www.WebsenseSecurityLabs.com -- 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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/ -- Zbigniew Lukasiak http://brudnopis.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] State of the art in form validat =?UTF-8?Q?ion; _opinion_poll=E2=80=A6_Model_based_forms/validation=3F?=
What I like about the FormFu approach is that it gives you a *path*
for the development. For a quick start you just stay with the
defaults - they still are displayed OK and you can show the project to
someone. Then when need to customise it's look and feel you generate
the templates and tickle them to submission.
--
Zbyszek
On Dec 5, 2007 9:16 AM, Carl Franks [EMAIL PROTECTED] wrote:
On 05/12/2007, Ashley Pond V [EMAIL PROTECTED] wrote:
What are best practices? DBIx::Class::Validation reusing your form
package profiles? But you still have to write your own forms. I've
searched around a lot and can't find a thorough, coherent Catalyst
related doc about it.
I really want one, final approach to this I'll use every time from
now on instead of experimenting with packages and home rolled stuff
over and over. If someone is there, or even close. Please kick down.
I'm really happy with how HTML::FormFu is coming along.
Like your example, you can define your entire form in any config file
Config::Any supports. Although I (predictably) prefer the FormFu style
declarations.
It has lots of little shortcuts that make things easier, such as auto_label().
If you set, for example, auto_label('label_%n') at the form-level,
then all fields will automatically use localize() to set their own
label (replacing the '%n' with their field name).
Like many settings, this can be set at either the form-, the
fieldset-, or the field-level, and when the method's used as a
'getter', it traverses the field's parents, searching for a value.
There's also an auto_error_message() which can get error messages from
your localize() object, based on the field's name and/or type.
(the next couple of features are currently only in svn, and will be
released to cpan in the next week...)
By default, the form's markup is generated internally by perl
subroutines. However, by simply setting render_method('tt') it
switches to using TT templates (which are installed using
File::ShareDir) and generates the exact same markup.
If you wish to customise the form markup, you can create a local copy
of the templates, and change the form however you want.
You can also use your own, single TT file, much like claco's example
earlier in this thread, explicitly placing individual fields.
There's also DBIC integration, which I'm currently in the process of
documenting - again, on it's way to cpan soon.
If you had, say, these 2 tables:
table: user
cols: name
might_have: address
table: address
cols: user, street, city
belongs_to: user
Then you could create a form like so:
---
elements:
- name: name
- type: Fieldset
nested_name: address
elements:
- name: street
- name: city
- type: Submit
If you then pass that form a 'user' row, it will automatically
traverse the 'address' relationship, filling in the form fields:
$form-values_from_model( $user_row );
And when the form's submitted, you can save the changes back to the
database, again, automatically following the relationship:
$form-save_to_model( $user_row );
It also handles has_one, has_many, and many_to_many relationships.
To finish off, here's an example of how I'd probably write your form
(as far as I can interpret it):
---
auto_fieldset:
legend: user
elements:
- name: last_name
constraints:
- type: Required
- type: Length
max: 50
- name: suffix
constraints:
- type: Regex
regex: '?-xism:\A[IVX]{1,3}\z'
- name: email
constraints:
- type: Required
- type: Email
- type: Length
max: 80
- type: Submit
If you're interested in looking further, the svn location is:
http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu
or you can ask any questions on the mailing list:
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu
Cheers,
Carl
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
--
Zbigniew Lukasiak
http://brudnopis.blogspot.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/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] transforming a Catalyst uni-lang app into a multi-langone
On 10/19/07, Brian Cassidy [EMAIL PROTECTED] wrote: Octavian Rasnita wrote: From: Jonas Alves Why not use $c-uri_with(lang = $lang) ? Thank you. I didn't know about $c-uri_with. Actually, it's $c-request-uri_with(). He can also use the third parameter to uri_for for that: $c-uri_for( $path, @args?, \%query_values? ) -- Zbigniew Lukasiak http://brudnopis.blogspot.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/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
