[Catalyst] Catalyst::Controller::HTML::FormFu
Hi, Is there a way i can add each individual form fields within an tag. i am talking about some configuration in the yaml config file for Catalyst::Controller::HTML::FormFu Pl. reply , i need help urgently -- Thanks and kind Regards, Abhishek jain ___ 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] Paradigm question: how to use ResultSet level security based on $c->user?
> "will" == will trillich writes:
will> Question: when a user logs in to our Catalyst app, he/she
will> should only see the items he/she is allowed to see. But the
will> only way we can figure how to do this is to pass $c->user
will> either to the ResultSet methods or to the FormHandler methods,
will> making the app more and more interdependent... Is there a
will> better paradigm in the context of a Catalyst app?
That is perfectly fine as long as you define an API for user and stick
to it so you can replace it via duck typing afterwards.
will> Right now we're working this via DBIC ResultSet like so:
will> package Incident::Schema::DB::ResultSet::Incident;
will> use base 'DBIx::Class::ResultSet';
will> sub security {
will> my $rs = shift;
will> my $user = shift;
will> $user = $user->obj
will> if ( $user->can('obj') );
will> if ( $user->is_admin ) {
will> return $rs; # everything is visible to admins
will> }
will> my %visible_teams = map { $_ => 1 }
will> $user->corp_team_ids; # method from Incident::User schema
will> $rs = $rs->search(
will> { 'me.team' =>
will> { -in => [ keys %visible_teams ] }
will> },
will> { order_by => ['created'] }
will> );
will> return $rs;
will> }
will> Then...
will> package Incident::Web::Controller::Ticket;
will> BEGIN { extends 'Catalyst::Controller'; }
will> sub base : Chained('/auth') PathPart('ticket') CaptureArgs(0) {
will> my ( $self, $c ) = @_;
will> my $rs = $c->model('Incident::Ticket')->security( $c->user );
will> $c->stash( incident_rs => $rs );
will> }
will> Is this Kosher? In this context it's a DBIC resultset
will> depending on another DBIC object, so it may not be as big an
will> issue as, say, when we have HTML::FormHandler popup menus that
will> should only show the user options based on the user's role
will> and/or organization.
will> Is there a canonical way to approach this both in ResultSets
will> and in FormHandler forms?
You might want to look at
Catalyst::TraitFor::Model::DBIC::Schema::WithCurrentUser
--
Eden Cardim
Code Monkeyhttp://www.shadowcat.co.uk/catalyst/
Shadowcat Systems Ltd. Want a managed development or deployment platform?
http://blog.edencardim.com/http://www.shadowcat.co.uk/servers/
http://twitter.com/#!/edenc
___
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] OAuth 2.0 for a RESTful API?
Hi all, Has anyone done this yet or wish to work together on a plugin? Cheers. -- http://www.suretecsystems.com/services/openldap/ http://www.surevoip.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/
RE: [Catalyst] Localisation
I’ve exchanged emails with Clinton Gormley (Locale::Maketext) and Guido Flohr (Locale::TextDomain). Both are definitely still maintained. From: Duncan Garland [mailto:duncan.garl...@motortrak.com] Sent: 13 October 2011 09:36 To: The elegant MVC web framework Subject: RE: [Catalyst] Localisation >>> That is mainly what I was referring to, and it is something that Maketext >>> needs to do. Agreed. Definitely. The good news is that it doesn’t look like is should be too difficult. From: Stephen Clouse [mailto:stephenclo...@gmail.com] Sent: 12 October 2011 22:37 To: The elegant MVC web framework Subject: Re: [Catalyst] Localisation On Wed, Oct 12, 2011 at 8:20 AM, Duncan Garland mailto:duncan.garl...@motortrak.com>> wrote: >>> Now, the article has some valid points about how Maketext does it wrong >>> (like not being able to handle a verbatim gettext PO), so let's fix >>> Maketext. Maketext does handle PO files. I know it won’t handle the plurals construct. Is there anything else it trips up on? That is mainly what I was referring to, and it is something that Maketext needs to do. quant is pretty much useless for its intended purpose, for the reasons cited in the article. -- Stephen Clouse mailto:stephenclo...@gmail.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:9
David wrote: .Your sex life will be back! http://www.mfi.es/html/friends.page.php?wishowtopic=58o5 I sure hope David doesn't have anything important post. I'm putting him into my sieve filter with a discard. \\||/ Rod -- ___ 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/
[Catalyst] Localisation
Hi, Duncan Garland pointed me to this discussion. Please don't flame me if I missed some obvious points from the previous discussion. Pipermail messed up all mails encoded in base64. See for example http://lists.scsys.co.uk/pipermail/catalyst/2011-October/027720.html I didn't bother to decode them, sorry. I am the author of libintl-perl aka Locale::TextDomain, and of the Perl backend of GNU gettext. 3-4 years ago I have experimented with Catalyst, always with - it's my hobbyhorse, after all - i18n/l10n in mind. I haven't touched Catalyst since then; if I missed any recent developments, sorry again, and correct me. For obvious reasons I used GNU gettext for localisation for these experiments, with minimal pain. For the Perl side (model and controllers) I just used libintl-perl, and it is a piece of cake, it just works. For the views I wrote a plug-in for Template Toolkit which exported the gettext API into TT templates. If anybody volunteers to maintain that plug-in, drop me a line. I didn't upload it to CPAN because I felt that I'm not good enough with TT and Catalyst. But it basically works. When you endeavour to internationalize a web project nowadays, the runtime-aspect is negligible. It doesn't matter how you look up translations for messages, even with a gettext implementation without contexts or the ngettext plural API, even with catgets. In reality, you can always workaround those run-time problems. The real problems are: 1) You must be able to create translation files that are accepted by professional translators. Most professional translators for software expect formats used by applications for MS-DOS/Windows. More and more translators accept PO files. In that other world, where unicorns excrete rainbows, sunshine and butterflies, they will also happily subclass from your localization handle. 2) Except for one-shot projects, your translation files should be mergeable (mergable?). Portable object (PO) files are pretty much mergeable. Some proprietary frameworks maybe offer similiar functionality. But I'm only positive for PO files. 3) In an MVC environment, every translatable message in a model or controller is a potential bug or flaw, at least according to yours truly. Views are nowadays template based. The challenge is to extract messages from your templates. With Perl (Python, Ruby, ...) this is actually easy-going because you can usually (ab)use your template processor for extracting messages, dump it into a .pot file, (msg)merge it with your old po file, and your translators are happy, see 1). 4) At run-time: GNU gettext selects translations based on the currently selected locale, on “the currently selected locale”. That makes sense for desktop applications but not for client-server applications, leave alone threaded applications. Switching locale is never thread-safe and potentially slow. I hope that I will be able to improve the situation a little bit with libintl-perl 2.x. As far as 4) is concerned, I plan to provide functions that look up translations without switching locale. Instead, you can provide the name of a language or even the name of a file containing translations. The show stoppers are modules/libraries/external applications that use the native gettext framework, most notably the system libc. They will still select the translation based on the user locale, resulting in ugly language mixes, and even uglier charset mixes. Actually, in a web application you should strive to hide such messages from the user, for usability or merchantability. Yet, this is an open issue. For 2), with libintl-perl 2.x you will have functions that can read, filter, and write PO (and also MO) files. If you want to gettextize your proprietary best-template-system-in-the-world-format files, just write an extractor for that format, feed it into Locale::Catalog::Format::PO, write a .pot file, and msgmerge it with the other .pot files from your project. You can follow the progress here: git://git.guido-flohr.net/perl/libintl-perl.git git://git.guido-flohr.net/perl/pgettext-tools.git Check out the POD of lib/Locale/Catalog/Format/PO.pm, lib/Locale/Catalog/Format/MO.pm and lib/Locale/Catalog.pm as starters. Please don't expect any production code from the above sources before the end of the year. Guido -- Империя ООД | Imperia OOD ул. „Княз-Борис-I“ № 86, София 1000 | ul. "Knyaz-Boris-I" № 86, Sofia http://www.imperia.bg/ ___ 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/
