Re: [Catalyst] autocrud/ExtJS question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/09/2010 16:21, Peter Karman wrote: Oliver Gorwits wrote on 09/24/2010 07:47 AM: If anyone does have any suggestions for how this might be done better in the user interface, please let me know. CatalystX::CRUD::YUI handles many-to-many (and one-to-many) selection through a livegrid (ExtJS extension) widget, so that there is no need to know or care how many possible combinations there might be. Thanks Peter, I will check this out! regards, - -- Oliver Gorwits, Network and Telecommunications Group, Oxford University Computing Services -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkylfPwACgkQ2NPq7pwWBt6RtQCglVFJpAHn+X9iu0k757D/0DT5 qdwAoNPOoKe8Se76RYMsg5DKajaRBCob =yzEs -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/
Re: [Catalyst] Re: Returning to referer - which action to take?
On Thu, 30 Sep 2010 22:36:36 +0200 Ekki Plicht (DF4OR) wrote: Well, yes. And put the language in every other link on that page, if I don't keep it in a session. Feasible, but I am not sure about the performance penalty with hundreds of links in my menu tree, which have to be prepared dynamically. You don't - if you use C:P:I18N::PathPrefix, Catalyst's $c-uri_for() will do it for you, and will do it without any extra cost (it does not change uri_for() at all, just it makes sure $c-req-base ends with the language prefix - and that's a one-time cost per request). (I assume you already use $c-uri_for() for link generation.) norbi ___ 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] Working with C::P::I18N::Request and C::P::I18N::PathPrefix at the same time?
On Thu, 30 Sep 2010 22:32:03 +0200 Ekki Plicht (DF4OR) wrote: Am I right that this combination (see subject) does not work well together? Dunno, never tried them, but if they don't work together it's a bug that should be fixed. AFAICS C::P::I18N::Request modifies the path very early in the request cycle, before the dispatcher and C::P::I18N::PathPrefix can kick in, right? Yup, but if you swap the order of these two plugins, ::PathPrefix can act before ::Request (and, BTW, ::PathPrefix also acts before the dispatcher, these two modules hook to the same method:-). Can you try if it works if you simply change the order of loading ::Request and ::PathPrefix? (If it works then I'll update the documentation to mention it.) IOW: Regardless of what path prefix (language) I use, C::P::I18N::Request only looks at the 'accept-language' header parameter, right? That makes this combination unusable... too bad. Nope, ::Request uses $c-localize(), and that uses $c-languages(), and C:P:I18N::PathPrefix sets that to the language from the path prefix. So they should work together smoothly (given that ::PathPrefix has the first turn). I would love to have localized path names (like I18N::Request offers), but also the possibility to let the user change languages at will (like I18N::PathPrefix + session mgmt offers). That includes letting her select a different language than what her browsers header 'accept-language' is set to. You can achieve that using C:P:I18N, C:P:I18N::PathPrefix and C:P:I18N::Request together. Also you don't need a session for that: if the user uses an URL to your site with a language code path prefix, that language will be used throughout the site until (s)he switches language, if (s)he uses an URL without a language code path prefix then it will be set from the 'accept-language'. Alternatively you can set a plain cookie if you want to remember the preferred language from the previous browsing session and if (s)he uses an URL without a path prefix you can use the value of this cookie to override the language detected from 'accept-language'. norbi ___ 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] Moose/Object error in Catalyst
I have a Catalyst app that started life in version 5.7 and has been upgraded to work with the 5.8 Moose version of Catalyst along the way. Recently I also upgraded my version of DBIx::Class::Schema::Loader, which added some Moose stuff to the top of all my table classes, like this: use Moose; use MooseX::NonMoose; use namespace::autoclean; extends 'DBIx::Class::Core'; After that, I started getting this error message with every single request to the server: dev server on OSX: Odd number of elements in anonymous hash at /Library/Perl/5.8.8/darwin- thread-multi-2level/Moose/Object.pm line 39. or on Linux under apache: [Thu Sep 30 19:57:59 2010] [warn] [client 208.93.49.4] mod_fcgid: stderr: Odd number of elements in anonymous hash at /usr/lib64/perl5/ site_perl/5.8.8/x86_64-linux-thread-multi/Moose/Object.pm line 39. Any ideas what is causing it? I've tried to debug it but haven't managed to figure it out myself yet. If I roll back to the previous version of the table classes without the Moose stuff the error goes away - but I don't want to do that! ___ 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: Moose/Object error in Catalyst
[Thu Sep 30 19:57:59 2010] [warn] [client 208.93.49.4] mod_fcgid: stderr: Odd number of elements in anonymous hash at /usr/lib64/perl5/ site_perl/5.8.8/x86_64-linux-thread-multi/Moose/Object.pm line 39. Any ideas what is causing it? I've tried to debug it but haven't managed to figure it out myself yet. If I roll back to the previous version of the table classes without the Moose stuff the error goes away - but I don't want to do that! I just discovered that if I keep the Moose stuff at the top of the table classes, but comment out the line: __PACKAGE__-meta-make_immutable; at the bottom of all of them, the Odd number of elements error stops happening. I still don't know why, or if this is a BAD THING to do - if anyone can offer any advice I'd be grateful. ps I've posted this to the Catalyst list rather than DBIx::Class, because I can use the Moose-ified schema outside of Catalyst without getting any errors. I'm not sure if this really is therefore a Catalyst error, but as that's the only place I see the error it seemed like the best place to start asking for help. ___ 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] Has anyone read the book Catalyst 5.8 : The Perl MVC Framework yet?
I recently received a copy of the book Catalyst 5.8 : The Perl MVC Framework for review, have read it and tried out the examples. Before I make my judgments public, I'd first be curious to hear from others in the Catalyst Community about what their views are on the book. Those that have actually read the book, that is. I've already seen a couple blog entries and they tend to be fairly negative (we sure prefer to rant). -- Kiffin Gish kiffin.g...@planet.nl Gouda, The Netherlands ___ 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] Working with C::P::I18N::Request and C::P::I18N::PathPrefix at the same time?
Am Freitag 01 Oktober 2010, 12:13:44 schrieb BUCHMULLER Norbert:
On Thu, 30 Sep 2010 22:32:03 +0200 Ekki Plicht (DF4OR) wrote:
Am I right that this combination (see subject) does not work well
together?
Dunno, never tried them, but if they don't work together it's a bug that
should be fixed.
AFAICS C::P::I18N::Request modifies the path very early in the request
cycle, before the dispatcher and C::P::I18N::PathPrefix can kick in,
right?
Yup, but if you swap the order of these two plugins, ::PathPrefix can act
before ::Request (and, BTW, ::PathPrefix also acts before the dispatcher,
these two modules hook to the same method:-).
Can you try if it works if you simply change the order of
loading ::Request and ::PathPrefix? (If it works then I'll update the
documentation to mention it.)
Doesn't work, sorry.
Ok, here goes:
in wshop.pm:
# sequence of I18N::PathPrefix and I18N::Request changed order
use Catalyst qw/
-Debug
ConfigLoader
Static::Simple
I18N
I18N::PathPrefix
I18N::Request
Authentication
Authorization::Roles
Session
Session::State::Cookie
Session::Store::FastMmap
Email
/;
in Root.pm:
sub egalwie :Path('/target') :Args(1) {
my ( $self, $c, $testparam ) = @_;
}
in de.po:
msgid PATH_delocalize_dogerman
msgstr target
in en.po:
msgid PATH_delocalize_doenglish
msgstr target
So both paths, 'doenglish' and 'dogerman' should point to the same action
'target'.
In header 'accept-language': en
URI requested: /en/doenglish/1
Result: 200
$c-language as displayed in template: en
URI requested: /de/doenglish/1
Result: 200
$c-language as displayed in template: de
URI requested: /en/dogerman/1
Result: 404
$c-language as displayed in template: en
URI requested: /de/dogerman/1
Result: 404
$c-language as displayed in template: de
In header 'accept-language': de
URI requested: /en/doenglish/1
Result: 404
$c-language as displayed in template: en
URI requested: /de/doenglish/1
Result: 404
$c-language as displayed in template: de
URI requested: /en/dogerman/1
Result: 200
$c-language as displayed in template: en
URI requested: /de/dogerman/1
Result: 200
$c-language as displayed in template: de
The results are understandable and logical - only a path for the current
language _as_ _defined_ _by_ _the_ _accept-language_ _setting_ is localized
and found. The PathPrefix language is ignored at this point in the request
cycle, only later it is properly set, as the $c-language var in the template
shows. And that seems to be independent of the order of the plugins in the use
statement. Yup, just tested the old sequence, same result.
So the header setting of 'accept-language' always takes over for path
localizations. When set to 'en' english localizations are used, when set to
'de' german localizations are used. Regardless of the path prefix.
That's not what I expected or want. I want the PathPrefix to override the
'accept-language' setting in the browser much earlier, at a place where path
localizations done by C::P::I18N::Request.
Feasible? Maybe, but wouldn't it break the behaviour of PathPrefix when used
in conjuntion with I18N::Request?
Localized paths are nice to have, but not a must at this moment. So I could
live with out using I18N::Request.
Thanks Cheers,
Ekki
___
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] Has anyone read the book Catalyst 5.8 : The Perl MVC Framework yet?
I actually read the first 2 chapters and tried the examples. I haven't had time to finish the book. I haven't read any other books on Catalyst, but I do like the Sitepoint books better (Build Your Own Ruby On Rails Web Applications). From: Kiffin Gish kiffin.g...@planet.nl To: catalyst@lists.scsys.co.uk Sent: Fri, October 1, 2010 3:15:47 PM Subject: [Catalyst] Has anyone read the book Catalyst 5.8 : The Perl MVC Framework yet? I recently received a copy of the book Catalyst 5.8 : The Perl MVC Framework for review, have read it and tried out the examples. Before I make my judgments public, I'd first be curious to hear from others in the Catalyst Community about what their views are on the book. Those that have actually read the book, that is. I've already seen a couple blog entries and they tend to be fairly negative (we sure prefer to rant). -- Kiffin Gish kiffin.g...@planet.nl Gouda, The Netherlands ___ 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: Returning to referer - which action to take?
Am Freitag 01 Oktober 2010, 02:39:40 schrieb Aristotle Pagaltzis: * Ekki Plicht (DF4OR) e...@plicht.de [2010-09-30 22:40]: Am Dienstag 28 September 2010, 23:09:49 schrieb Aristotle Pagaltzis: Ultimately you should not need any session storage for anything. Yes, for session tracking. I would like to see what my visitors do on our site :-) You definitely don’t need sessions for user tracking. Hm. Would you care to elaborate on that a little? How would you identify a returning customer (returning within a few seconds to a few minutes in one browser session)? Browser fingerprinting in an auto action? Cheers, Ekki ___ 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: Returning to referer - which action to take?
* Ekki Plicht (DF4OR) e...@plicht.de [2010-10-02 00:15]: How would you identify a returning customer (returning within a few seconds to a few minutes in one browser session)? Browser fingerprinting in an auto action? For personalisation or analytics? For personalisation you pretty much have to use a cookie. That has nothing to do with a session though. For analytics I would not do this inside the app at all. You can use referrers to stitch a trail of requests into a click stream. If you tack a short random sequence of characters onto all your links as an ignored request parameters, and you follow the trail backward, you will get near-perfect accuracy for click streams even for visitors with cookies off, as long as they send referers. (Many more people block cookies than referers. You can use both methods of course, possibly using detection to select one.) 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/
