Re: [Catalyst] New version of InstantCRUD
I'm currently patching the hell out of Controller::DBIC::API. Search by passing a json string and pagination is already in the repo, prefetch support is done but needs some sort of controller side restriction so that someone can't fetch the contents of the whole db by using the rels (api for that welcome). This should/could be the basis for ajax based LFB modules to load data instead of relying on an LFB internal API. What I'd like to see is a more split up LFB so I could use the (extjs) form generation on a per table (=controller) basis wherever I need it (for tables where a customized form isn't needed). - Alex Am Samstag, den 21.02.2009, 10:08 +0100 schrieb Oliver Gorwits: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Zbigniew, Zbigniew Lukasiak wrote: In short I am open for collaboration - but I found it difficult to express my expectations for the library without writing my own code. I (author of the ListFramework Builder CRUD - LFB) couldn't agree more. All these CRUD systems are lovely and go a great job but it is painful to see everyone developing in different directions. This is what has kept me from working on re-engineering LFB (I've done some bug fixes only, in the last six months). I know what needs factoring out, where there needs to be an API etc, but to be honest I suck at API design, I thought I'd better wait for someone else's DBIC API :-) And as an aside... At the moment I am happy with the niche LFB fills (i.e. not a scaffolder) and am working on a new user interface in something more lightweight than ExtJS. It might also get renamed to something like Catalyst::Plugin::AutoCRUD (well, or...?). If you are not familiar with LFB, see here (feedback welcome): http://tinyurl.com/listframework http://dragonstaff.co.uk/oliverg/ - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJn8Sk2NPq7pwWBt4RAjGTAKC6wZwRm/JlLXioXGwBSScd319BWQCbBZVQ irNs/whuX90LqvKDvgJDYPI= =Wzug -END PGP SIGNATURE- ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ *** 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/
[Catalyst] Re: template design issue: varibales stand-alone components
* Bill Moseley mose...@hank.org [2009-02-22 18:20]:
On Sun, Feb 15, 2009 at 11:05:20AM +0100, Aristotle Pagaltzis wrote:
Your templates should build up the page inside-out, and they
should not be calling *any* methods in your model. As far as
possible they should only be using stashed variable values.
If you call any methods they should only be helper methods
from the context like `uri_for`.
Hope that quote is not out of context.
So are you saying you should never do this?:
Hello [% user.first_name | html %]
That instead you should have in your controller:
$c-stash-{first_name} = $user-first_name;
Ack, no. What I said really didn’t make much sense, although what
I actually meant does. Now that you pointed out the inconsistency
I’m not sure how to put my point as a simple rule of thumb.
No, `user.first_name` in the template is perfectly acceptable.
Calling methods to retrieve values from stashed objects is
perfectly reasonable.
What I meant is that the templates should not go fetching data
from the the model by themselves, nor of course should they be
making insert/delete calls against the model. They should also
avoid calling any methods on the context object, as far as
possible. Frequent exceptions are `c.uri_for` and `c.req`’s
various methods.
The point is: if rendering the template requires the entire Cat
app to be set up and running, you are probably relying on global
state, and the template will be hard to test in isolation and
hard to reuse. Ideally it would be no harder to render from a
10-liner than from the Cat app.
Regards,
--
Aristotle Pagaltzis // http://plasmasturm.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] New version of InstantCRUD
Am 23.02.2009 um 10:53 schrieb Alexander Hartmaier: I'm currently patching the hell out of Controller::DBIC::API. Search by passing a json string and pagination is already in the repo, prefetch support is done but needs some sort of controller side restriction so that someone can't fetch the contents of the whole db by using the rels (api for that welcome). This should/could be the basis for ajax based LFB modules to load data instead of relying on an LFB internal API. What I'd like to see is a more split up LFB so I could use the (extjs) form generation on a per table (=controller) basis wherever I need it (for tables where a customized form isn't needed). - Alex Hi all, I'm following a different approach. My current project uses HTML::FormFu config files for both validating user input and generating json which contains the data of a resultset or result row. I do not use the html generation capabilities of FormFu, just validation, filters, transformers, inflators and deflators. I wrote http://search.cpan.org/~perler/DBIx-Class-AsObject-0.09_01/ which is far from being stable. But it generates a perl object from a result row using a HTML::FormFu configuration file. I think Controller::DBIC::API lacks of the ability to do proper validation. Maybe we can join forces on that one and add a configuration file to each controller. moritz ___ 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] How to clear off request parameter element
hi all
I have an app with a listing method in the controller. It goes a little
like this:
sub list
{
# get object from model based on $c-request-param('id');
IF (object)
{
return;
}
ELSE
{
return all objects belonging to the current user;
}
return 1;
}
then , i have a deletion method which will delete a given object (by ID
specific in a form via POST method) and list out all objects belonging
to the current user.
sub delete
{
# get specific object based on ID ($c-request-param('id');)
#delete object
$c-forward( 'list' );
}
The problem here is that sub list will always call the
$c-request-param('id'); which is no longer valid once an object has
been deleted.
What is the best way to delete the 'id' attribute off $c-request-param??
thank you.
K. akimoto
___
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] Session trouble
Hello All, I am using Session::Store::File and Session::State::Cookie. Session expiration period is set to 32768 seconds. However from time to time when I browse the site I am logged out. Any idea how to trace this? Kind regards, Michal. ___ 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
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. - 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 -- (sorry for sounding so emotional afaik our company burned man-weeks on solving minor encoding-bugs :-/ every tutorial we found was like you can do it so or so or another way 'round the house, so it's perfect and if you don't understand is, you're retard and should use 7bit-ASCII... while lately even a colleague sounds like this - as he is enlinghtened by CPAN literature like UTF-8 vs. utf8 vs. UTF8 ;)). Greets and regards, Tom Weber ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: How to clear off request parameter element
kakim...@tpg.com.au wrote:
hi all
I have an app with a listing method in the controller. It goes a little
like this:
sub list
{
# get object from model based on $c-request-param('id');
IF (object)
{
return;
}
ELSE
{
return all objects belonging to the current user;
}
return 1;
}
then , i have a deletion method which will delete a given object (by ID
specific in a form via POST method) and list out all objects belonging
to the current user.
sub delete
{
# get specific object based on ID ($c-request-param('id');)
#delete object
$c-forward( 'list' );
}
The problem here is that sub list will always call the
$c-request-param('id'); which is no longer valid once an object has
been deleted.
What is the best way to delete the 'id' attribute off $c-request-param??
http://search.cpan.org/~mramberg/Catalyst-Runtime-5.71000/lib/Catalyst/Request.pm#$req-%3Eparam
maybe you need $c-req-param('id', 0);
Thanks.
thank you.
K. akimoto
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] 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] Re: decoding in core
Zbigniew Lukasiak schrieb:
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.
Ah SORRY! In my confusion I've confused it again...
So if I get it right, use utf8 means you can do stuff like $s ~=
s/a/ä/; (as the plain ä in the source will be treated as one character
and not two octets), while the magical utf8-flag for $s tells perl, that
the ä in the scalar really is an ä and not two strange octets.
Am I right or am I completely lost again?
Hmm - maybe I'll add UTF-8 handling in InstantCRUD. I am waiting for
good sentences showing off the national characters.
Does it have to be a complete sentence? My favourite test-string is
something like
äöüÄÖÜß'+ (UTF-8)
C3 A4 C3 B6 C3 BC C3 84 C3 96 C3 9C C3 9F 22 27 2B (Hex)
If I can put this string into some html-form, post/get it, process it,
save to and read from db, output it to browser _and_ still have exactly
10 characters, the application _might_ work as it should.
The Umlauts and the Eszett are a pain of unicode, the and ' are
fun-with-html and escaping and the + ... well, URI-encoding, you know...
For even more fun, one should do a regex in the application using utf8
(give me all those äÄs) and select it from the DB, first with blahfield
LIKE 'ä', maybe upper(blahfield) LIKE upper('ä') and finally an
ORDER BY blahfield, where blahfield should contain one row starting
with a, one with ä and one with b and the output should have
exactly this order and _not_ a,b,ä (hint hint: utf9 treated as ascii
or latin1).
Greets and regards,
Tom Weber
___
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
Oh I forgot something... or more precisely, my boss named it while having a smoke. Maybe somewhat OT, but definetly interesting (maybe could be used to simplify the problem of double-enconding): Does anyone know a _safe_ method to convert _any_ string-scalar to utf8? Something like anything_to_utf8($s) , regardless if $s contains ascii, latin1, utf8, tasty hodgepodge or hot fn0rd, utf8-flag is set or not and is neither affected by full moon nor my horrorscope, _without_ doing double-encoding (there MUST be some way to determine if it already is utf8... my silly java editor can do it and perl makes difficult things at least possible). I would greatly appreciate this philosophers stone and will send my hero a bottle of finest bavarian (munich!) beer called Edelstoff (precious stuff - tasty). Greets and thanks! Tom Weber ___ 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
Neo [GC] wrote on 02/23/2009 09:41 AM: Does anyone know a _safe_ method to convert _any_ string-scalar to utf8? Something like anything_to_utf8($s) , regardless if $s contains ascii, latin1, utf8, tasty hodgepodge or hot fn0rd, utf8-flag is set or not and is neither affected by full moon nor my horrorscope, _without_ doing double-encoding (there MUST be some way to determine if it already is utf8... my silly java editor can do it and perl makes difficult things at least possible). I would greatly appreciate this philosophers stone and will send my hero a bottle of finest bavarian (munich!) beer called Edelstoff (precious stuff - tasty). Search::Tools::UTF8::to_utf8() comes close. It won't handle mixed encoding in a single string (which would be garbage anyway) but it does try to prevent double-encoding and uses the Encode goodness under the hood. -- Peter Karman . pe...@peknet.com . 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/
Re: [Catalyst] Re: decoding in core
From: Peter Karman pe...@peknet.com Neo [GC] wrote on 02/23/2009 09:41 AM: Does anyone know a _safe_ method to convert _any_ string-scalar to utf8? Something like anything_to_utf8($s) , regardless if $s contains ascii, latin1, utf8, tasty hodgepodge or hot fn0rd, utf8-flag is set or not and is neither affected by full moon nor my horrorscope, _without_ doing double-encoding (there MUST be some way to determine if it already is utf8... my silly java editor can do it and perl makes difficult things at least possible). I would greatly appreciate this philosophers stone and will send my hero a bottle of finest bavarian (munich!) beer called Edelstoff (precious stuff - tasty). Search::Tools::UTF8::to_utf8() comes close. It won't handle mixed encoding in a single string (which would be garbage anyway) but it does try to prevent double-encoding and uses the Encode goodness under the hood. -- Peter Karman . pe...@peknet.com . http://peknet.com/ I understand that there are reasons for not transforming all the encodings to UTF-8 in core, even though it seems to be not very complicated, because maybe there are some tables that contain ISO-8859-2 chars and other tables that contain ISO-8859-1 chars, and when the data need to be saved, it should keep its original encoding. But if somebody wants to create a new Catalyst app, with a new database, new templates, controllers, etc, I think it could be very helpful if the programmer would only need to specify only once that he wants to use UTF-8 everywhere - in the database, in the templates, in the configuration files of HTML::FormFu, in the controllers, and not in more places in the configuration file, or specify UTF8Columns in DBIC classes... It could be a kind of default. 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/
Re: [Catalyst] stripping path parts and then redispatch?
Hi Lars -
I have an existing site, and want to add the page language to the URLs
so that caching will work correctly, e.g. /foo/bar would now look like
/en/foo/bar or /fr/foo/bar.
Apart from the missing true return value from auto, this works:
http://lists.scsys.co.uk/pipermail/catalyst/2009-February/021072.html
Thanks for the pointer. But this approach only seems to work for Local
actions, not Private actions like default(). E.g. using these
controllers:
#
package MyApp::Controller::Foo;
use parent 'Catalyst::Controller';
sub default :Private {
my ($self, $c, @args) = @_;
$c-response-body(Foo args: @args);
}
sub bar :Local {
my ($self, $c, @args) = @_;
$c-response-body(Foo::Bar args: @args);
}
#
package MyApp::Controller::En;
use parent 'Catalyst::Controller';
sub default :Private {
my ($self, $c, @args) = @_;
my $path = $c-request-path;
$path =~ s{^en}{};
$c-go($path, []);
}
#
The paths /en/foo/bar or /en/foo/bar/arg1 work as expected, but if I
try to hit /en/foo I get an error message:
Couldn't go to command /foo:
Invalid action or component.
because the action name it wants is really /foo/default, not just
/foo.
For a path like /a/b/c, I would need to figure out whether to do this:
# Will hit: A::Bwith arg 'c'
# or: A::B::C with no args
#
$c-go(/a/b/c, []);
vs this:
$c-go(/a/default, ['b', 'c']);
vs this:
$c-go(/a/b/default, ['c']);
?
I'm guessing there must be a way to use the Dispatcher to figure out,
for a given path, how to make go() work consistently, but I have not yet
found the trick for making this work...
Thanks!
Larry
___
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] Models and inflating
Hi,
I'm still a bit confused about how models using DBIx::Class should work
in a catalyst application.
Is it the case that classes placed in the Model-directory will somehow
(magically?) let me have objects inflated as instances of the class
using a similarly named Schema?
For example, I have this class:
package TestApp::Model::Foo::User;
use strict;
sub full_name {
my ( $self ) = @_;
return $self-first_name() . q{ } . $self-last_name();
}
1;
Objects created by $c-model('Foo::User') *will* work. Ie. they have the
methods full_name(), first_name() and last_name().
It looks a bit weird to me, but it seems to work. Should it work?
I also have another application A which has a more complex setup.
Application A also works. OTOH, application B, which is very similar to
application A, does *not* work. I get an error message saying Can't
locate object method inflate_result via package B::Model::DB::Snafu.
Can't really paste the code here, but I'd like some pointers where to
look for the cause of the error. Should it work at all, or do TestApp
and A work through some weird lucky bug?
Cheers,
Alex
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: decoding in core
On Mon, Feb 23, 2009 at 06:45:40PM +0200, Octavian Râşniţă wrote: I understand that there are reasons for not transforming all the encodings to UTF-8 in core, even though it seems to be not very complicated, because maybe there are some tables that contain ISO-8859-2 chars and other tables that contain ISO-8859-1 chars, and when the data need to be saved, it should keep its original encoding. Don't think about transforming encodings to UTF-8. In the vast majority of cases people expect to work with characters, and that's what Perl works with internally. UTF-8 is an encoding, not characters. The HTTP request is octets. The HTTP request specifies what encoding those octets represent and it's that encoding that is used to decode the octets into characters. The fact that Perl uses UTF-8 internally is best ignored -- it's just characters inside Perl once decoded. Conceptually it's not that much different than a request with Content-Encoding: gzip -- before using the request body parameters the gzipped octets must obviously be decoded. Likewise, the body must be url-decoded into separate parameters. And again, the resulting octets must be decoded into characters if the parameters are to be used as character. That last step has often been ignored. Then when sending a response of (abstract) characters that are inside Perl they must first be encoded into octets. Those things should be handled at the edge of the application, and that would be in the Engine (or the code the Engine uses). Yes, the same thing has to happen with templates, the database, and all external data sources. Those are separate issues. HTTP provides a standard way to determine how to encode and decode. -- Bill Moseley mose...@hank.org Sent from my iMutt ___ 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] Maybe there is a need for some speedups of 'config' method ?
Oleg Pronin wrote:
I use many actions that take params from config in runtime, for example
sub pay_for_vip : Private {
...
my $price = $c-cfg-{vip}{price};
}
As I understand it, this is NOT the way config is intended to work. All
the config for your component (controller in this case) is passed to the
constructor at setup time; all you need to do is make accessors for
whatever you want access to:
__PACKAGE__-mk_accessors(qw/vip/);
sub pay_for_vip : Private {
...
my $price = $self-vip-{price};
}
--
Jason Gottshall
jgottsh...@capwiz.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] stripping path parts and then redispatch?
Larry Leszczynski wrote:
Hi Lars -
I have an existing site, and want to add the page language to the URLs
so that caching will work correctly, e.g. /foo/bar would now look like
/en/foo/bar or /fr/foo/bar.
Apart from the missing true return value from auto, this works:
http://lists.scsys.co.uk/pipermail/catalyst/2009-February/021072.html
Thanks for the pointer. But this approach only seems to work for Local
actions, not Private actions like default(). E.g. using these
controllers:
#
package MyApp::Controller::Foo;
use parent 'Catalyst::Controller';
sub default :Private {
my ($self, $c, @args) = @_;
$c-response-body(Foo args: @args);
}
That construct is deprecated. You can do basically the same thing with:
sub default : Path {
...
}
See:
http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/Intro.pod#Built-in_Private_Actions
--
Jason Gottshall
jgottsh...@capwiz.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 clear off request parameter element
kakim...@tpg.com.au wrote:
hi all
I have an app with a listing method in the controller. It goes a little
like this:
sub list
{
# get object from model based on $c-request-param('id');
IF (object)
{
return;
}
ELSE
{
return all objects belonging to the current user;
}
return 1;
}
then , i have a deletion method which will delete a given object (by ID
specific in a form via POST method) and list out all objects belonging
to the current user.
sub delete
{
# get specific object based on ID ($c-request-param('id');)
#delete object
$c-forward( 'list' );
}
The problem here is that sub list will always call the
$c-request-param('id'); which is no longer valid once an object has
been deleted.
What is the best way to delete the 'id' attribute off $c-request-param??
thank you.
K. akimoto
What if, after the delete is performed, the user decides to bookmark the
list of items? The bookmark will be the URL to delete, instead of the
more appropriate URL to list. Instead of forwarding within the current
request, you should consider an actual redirect to your list page. It
admittedly does require an extra request cycle, but the user's
experience will be more correct.
--
Jason Gottshall
jgottsh...@capwiz.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] Maybe there is a need for some speedups of 'config' method ?
* On Mon, Feb 23 2009, Jason Gottshall wrote:
Oleg Pronin wrote:
I use many actions that take params from config in runtime, for example
sub pay_for_vip : Private {
...
my $price = $c-cfg-{vip}{price};
}
As I understand it, this is NOT the way config is intended to
work. All the config for your component (controller in this case) is
passed to the constructor at setup time; all you need to do is make
accessors for whatever you want access to:
__PACKAGE__-mk_accessors(qw/vip/);
sub pay_for_vip : Private {
...
my $price = $self-vip-{price};
}
Yes, exactly.
This is another case of the all-too-frequent change Catalyst so that I
won't have to change any code in my poorly-implemented app.
I don't think the patch will be harmful, though, so if there is one we
might as well apply it. But it's a lot easier to not misuse config than
it is to patch Catalyst to make the misuse faster.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
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] Models and inflating
* On Mon, Feb 23 2009, Alexander Tamm wrote:
Hi,
I'm still a bit confused about how models using DBIx::Class should
work in a catalyst application.
Is it the case that classes placed in the Model-directory will somehow
(magically?) let me have objects inflated as instances of the class
using a similarly named Schema?
For example, I have this class:
package TestApp::Model::Foo::User;
use strict;
sub full_name {
my ( $self ) = @_;
return $self-first_name() . q{ } . $self-last_name();
}
1;
Objects created by $c-model('Foo::User') *will* work. Ie. they have
the methods full_name(), first_name() and last_name().
It looks a bit weird to me, but it seems to work. Should it work?
You shouldn't do this (*), it is very confusing. Put functions like
this in the row class, i.e. YourApp::Schema::Foo::User, so that all
users of the schema have access to these methods.
Catalyst::Model::DBIC::Schema just proxies each class so that
$c-model('Schema::Foo') == $c-model('Schema')-resultset('Foo').
That's all you should use it for.
(*) BTW, the behavior you described does work intentionally, for cases
when you need the objects in Catalyst to be different than with plain
DBIC. I think it's a bad idea to use this feature except in very
special cases -- of which full_name is not one.
Regards,
Jonathan Rockway
--
print just = another = perl = hacker = if $,=$
___
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] stripping path parts and then redispatch?
Hi Jason -
I have an existing site, and want to add the page language to the URLs
so that caching will work correctly, e.g. /foo/bar would now look like
/en/foo/bar or /fr/foo/bar.
Apart from the missing true return value from auto, this works:
http://lists.scsys.co.uk/pipermail/catalyst/2009-February/021072.html
Thanks for the pointer. But this approach only seems to work for Local
actions, not Private actions like default(). E.g. using these
controllers:
#
package MyApp::Controller::Foo;
use parent 'Catalyst::Controller';
sub default :Private {
my ($self, $c, @args) = @_;
$c-response-body(Foo args: @args);
}
That construct is deprecated. You can do basically the same thing with:
sub default : Path {
...
}
See:
http://search.cpan.org/dist/Catalyst-Manual/lib/Catalyst/Manual/Intro.pod#Built-in_Private_Actions
Thanks, acknowledged. However, changing default:Private to
default:Path doesn't solve the problem - the expected argument to
$c-go() for the path /foo is still /foo/default, which is not
obvious just from looking at the path.
Larry
___
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] Models and inflating
It looks a bit weird to me, but it seems to work. Should it work? You shouldn't do this (*), it is very confusing. Put functions like this in the row class, i.e. YourApp::Schema::Foo::User, so that all users of the schema have access to these methods. The reason I want to do this (or something similar) is that I don't want all the database-specific cruft in the class I'm editing. I'm trying to keep the classes clean and separate the storage from the functionality. If I put the functionality in the Schema::*, I will have about 400 lines of code that I need to replicate across eight or more sites and the classes won't be usable without DBIx::Class or Catalyst. I don't regard that as a an option. Especially, since the Schema-classes are created by the helper script. If I use the method I describe, I can do this with inheritance and keep my classes clean and available to applications that don't use Catalyst or DBIx::Class. (*) BTW, the behavior you described does work intentionally, for cases when you need the objects in Catalyst to be different than with plain DBIC. I think it's a bad idea to use this feature except in very special cases -- of which full_name is not one. full_name() was just a very simple example to illustrate the problem. The real use case is a lot more complex and involves functionality that has nothing to do with DBIx::Class. Cheers, Alex ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Models and inflating
* On Mon, Feb 23 2009, Alexander Tamm wrote: It looks a bit weird to me, but it seems to work. Should it work? You shouldn't do this (*), it is very confusing. Put functions like this in the row class, i.e. YourApp::Schema::Foo::User, so that all users of the schema have access to these methods. The reason I want to do this (or something similar) is that I don't want all the database-specific cruft in the class I'm editing. I'm trying to keep the classes clean and separate the storage from the functionality. If I put the functionality in the Schema::*, I will have about 400 lines of code that I need to replicate across eight or more sites and the classes won't be usable without DBIx::Class or Catalyst. No, your current solution is the one that's not usable without Catalyst and DBIC. If you just want some random classes, you write them: package Class; use Moose; has 'some_row_object' = ( is = 'ro', does = 'Some::Interface', required = 1, ); # code goes here 1; I usually wrap the DBIC classes like this when I have operations that logically operate on a group of unrelated (in the DB) objects, or operate on two separate schemas. (What most people do in the controller I do in what I call Backend classes. It's the glue between the low-level DBIC stuff, and high-level operations.) If your classes depend on the structure of DBIC results, then the code needs to go in your schema classes. That is how everyone does it. (Your full_name example is just the sort of thing that you would keep inside DBIC.) Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$ ___ 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] Maybe there is a need for some speedups of 'config' method ?
Jonathan Rockway wrote:
* On Mon, Feb 23 2009, Jason Gottshall wrote:
Oleg Pronin wrote:
I use many actions that take params from config in runtime, for example
sub pay_for_vip : Private {
...
my $price = $c-cfg-{vip}{price};
}
As I understand it, this is NOT the way config is intended to
work. All the config for your component (controller in this case) is
passed to the constructor at setup time; all you need to do is make
accessors for whatever you want access to:
__PACKAGE__-mk_accessors(qw/vip/);
sub pay_for_vip : Private {
...
my $price = $self-vip-{price};
}
Yes, exactly.
This is another case of the all-too-frequent change Catalyst so that I
won't have to change any code in my poorly-implemented app.
Jeez. That's a little harsh, though I sympathise with the general point.
We use the Catalyst config file to initialize Catalyst components, to
initialise non-Catalyst configuration objects, and also to provide via
config() a simple runtime interface to 'get this key/value pair'. We
store other (runtime) conf values in the db, wrapped with memcached, to
avoid having to deploy a config file if we need timely changes. Many of
our conf values are shared between components, not directly relevant to
components, or are most readably kept together as a discrete
configuration set, rather than added per component. Finally, given the
size of our conf file, I don't think we'd want to clutter either our
packages with accessors, or our project with classes that merely wrap
configuration sets.
I don't think the patch will be harmful, though, so if there is one we
might as well apply it. But it's a lot easier to not misuse config than
it is to patch Catalyst to make the misuse faster.
I can't see anywhere in the docs where this 'intended use' is stated.
That's not to say that it isn't there.
Having said all that, our app must call config 10s of million times a
day, and we've never perceived it to be a bottleneck.
Regards,
David
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: decoding in core
* Neo [GC] n...@gothic-chat.de [2009-02-23 16:45]: Does anyone know a _safe_ method to convert _any_ string-scalar to utf8? There isn’t. Strings in Perl are untyped. They are simply sequences of arbitrarily large integers. If a string only contains values between 0 and 255, then it can be stored in an optimised form that uses exactly one byte per integer and the UTF8 flag is off. Otherwise, it is stored in a variable-width format that is identical to UTF-8 encoding, but is not actually UTF-8. (There is no particular meaning implied for these integers, and Perl strings can store integer values that are undefined in Unicode.) The UTF8 flag simply means “this is an unoptimised string”. It will sometimes be enabled on octet strings (even though no integer value in the string is 255) and it will frequently be disabled on character strings. It tells you nothing useful *at all* about the content of the string and you should just forget that it exists. [^1] If you have a string that corresponds to a sequence of octets which store the encoded form of a string according to some encoding, you have to manually keep track of this encoding, because there is nothing about the string that tells you this. The best approach is to simply decode strings as soon after input as possible and encode them as late before output as possible. In the middle of your code, then, you only have strings containing Unicode codepoints. [^1]: Almost. Unfortunately, there is quite a bit of broken XS code in modules out there which means you will have to `utf8::downgrade` strings to make sure they are stored in byte-wise optimised format before passing them in to such modules. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Models and inflating
Jonathan Rockway wrote: functionality. If I put the functionality in the Schema::*, I will have about 400 lines of code that I need to replicate across eight or more sites and the classes won't be usable without DBIx::Class or Catalyst. No, your current solution is the one that's not usable without Catalyst and DBIC. That's a weird conclusion... I admit that the example I posted was not very descriptive of my solution. (There were even some omissions, like use Moose.) What I have done in the real applications is more something like: package TestApp::Model::Foo::Bar; use Moose; extends 'RW::Bar'; 1; Where RW::Bar is the class with the actual functionality, completely independent of DBIC or any other storage solution. If you just want some random classes, you write them: package Class; ... 1; I usually wrap the DBIC classes like this when I have operations that logically operate on a group of unrelated (in the DB) objects, or operate on two separate schemas. (What most people do in the controller I do in what I call Backend classes. It's the glue between the low-level DBIC stuff, and high-level operations.) Your example does not show how Class is being used or how an object is created/inflated, but illustrates *basically* what I want to do. If your classes depend on the structure of DBIC results, then the code needs to go in your schema classes. That is how everyone does it. (Your full_name example is just the sort of thing that you would keep inside DBIC.) My classes don't depend on the structure. I only want to initialize objects with values that sometimes happen to come from a database. I was under the impression that this initalization can easily be done with DBIC, but I still haven't seen an example of a class with more complex functionality. I guess I could just use HashRefInflator and create my objects from hashrefs, but that involves a bit more repetitious code. As I said before, the full_name example has nothing to do with my application. It was only for illustration. Regards, Alex ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] stripping path parts and then redispatch?
Just wanted to pass along some solutions...
To recap briefly:
URLs are prefixed with the page language, e.g /en/foo/bar. The
language needs to be stripped off and stashed, and the remainder of the
request processed as if the language part had not been there, e.g.
/foo/bar.
I was trying to use $c-go(/foo/bar), which works if there is a
Foo::bar() action, but which breaks if the action is supposed to be
Foo::default() with the argument bar (or Foo::Bar::default() with no
arguments).
1) Bill Moseley suggested a different approach which is seeming to work
pretty well so far (thanks Bill), it involves subclassing
MyApp-prepare_path() to tweak the path at beginning of processing,
something like this:
sub prepare_path
{
my $c = shift;
$c-SUPER::prepare_path(@_);
my @path_chunks = split m[/], $c-request-path, -1;
return unless ( @path_chunks
$valid_languages{$path_chunks[0]});
# Pull off first path chunk:
my $language = shift @path_chunks;
$c-stash-{language} = $language;
# Create a request path from the remaining chunks:
my $path = join('/', @path_chunks) || '/';
# Stuff modified request path back into request:
$c-request-path($path);
# Update request base to include whatever
# was stripped from the request path:
my $base = $c-request-base;
$base-path($base-path . $language . '/');
}
A nice side effect is that tweaking $c-request-base to include the
language means the language is automatically included when you call
$c-uri_for().
2) In the process of trying to get $c-go() to work for an arbitrary
path, I found a way that seems to make it work consistently even if the
path is supposed to hit a default action:
# Create your request path to wherever:
my $path = /foo/bar/baz;
# Stuff modified request path back into request:
$c-request-path($path);
# Create a new $c-action using $c-request-path.
# Updates $c-action and $c-request-args.
$c-dispatcher-prepare_action($c);
$c-go($c-action, $c-request-args);
This should work for any of $c-forward(), $c-detach(), $c-visit(),
$c-go().
Thanks for all the suggestions,
Larry
___
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] stripping path parts and then redispatch?
I think this solution should be put at least in a wiki if not in the POD
manual.
Octavian
- Original Message -
From: Larry Leszczynski lar...@emailplus.org
To: Bill Moseley mose...@hank.org; Catalyst Framework
catalyst@lists.scsys.co.uk
Sent: Tuesday, February 24, 2009 3:44 AM
Subject: Re: [Catalyst] stripping path parts and then redispatch?
Just wanted to pass along some solutions...
To recap briefly:
URLs are prefixed with the page language, e.g /en/foo/bar. The
language needs to be stripped off and stashed, and the remainder of the
request processed as if the language part had not been there, e.g.
/foo/bar.
I was trying to use $c-go(/foo/bar), which works if there is a
Foo::bar() action, but which breaks if the action is supposed to be
Foo::default() with the argument bar (or Foo::Bar::default() with no
arguments).
1) Bill Moseley suggested a different approach which is seeming to work
pretty well so far (thanks Bill), it involves subclassing
MyApp-prepare_path() to tweak the path at beginning of processing,
something like this:
sub prepare_path
{
my $c = shift;
$c-SUPER::prepare_path(@_);
my @path_chunks = split m[/], $c-request-path, -1;
return unless ( @path_chunks
$valid_languages{$path_chunks[0]});
# Pull off first path chunk:
my $language = shift @path_chunks;
$c-stash-{language} = $language;
# Create a request path from the remaining chunks:
my $path = join('/', @path_chunks) || '/';
# Stuff modified request path back into request:
$c-request-path($path);
# Update request base to include whatever
# was stripped from the request path:
my $base = $c-request-base;
$base-path($base-path . $language . '/');
}
A nice side effect is that tweaking $c-request-base to include the
language means the language is automatically included when you call
$c-uri_for().
2) In the process of trying to get $c-go() to work for an arbitrary
path, I found a way that seems to make it work consistently even if the
path is supposed to hit a default action:
# Create your request path to wherever:
my $path = /foo/bar/baz;
# Stuff modified request path back into request:
$c-request-path($path);
# Create a new $c-action using $c-request-path.
# Updates $c-action and $c-request-args.
$c-dispatcher-prepare_action($c);
$c-go($c-action, $c-request-args);
This should work for any of $c-forward(), $c-detach(), $c-visit(),
$c-go().
Thanks for all the suggestions,
Larry
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive:
http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] windows install issues (Was: RFC: New to Catalystquestions)
I also couldn't install DBD::mysql, even though I've also tried without cpan, because on dmake it gives some errors I don't understand I had DBD::SQLite fail the stress test that DBIx::Class runs. Any solution for that one? I also just posted about it on the Strawberry Perl mailing list: http://www.mail-archive.com/win32-vani...@perl.org/msg00103.html Dan ___ 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/
