Re: [Catalyst] Encoding UTF8 ?
On Mon, Mar 28, 2011 at 7:50 PM, John M. Dlugosz wrote: > 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 wrote: > 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 wrote:
> On 13 December 2010 21:07, Octavian Rasnita wrote:
>> From: "Toby Corkindale"
>>
...
>> 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 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 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 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: AW: [Catalyst] User management with Catalyst (with email and URLs)
On Thu, Aug 26, 2010 at 2:27 PM, Denny <2...@denny.me> wrote: > On Thu, 2010-08-26 at 14:23 +0200, daniel.brunkho...@dataport.de wrote: >> > > Nope, there doesn't seem to be a Catalyst::Controller::Registration >> > > on CPAN. Maybe there should be. >> >> I wish there was and I definitely think there should be, because in >> my opinion this is a pretty common task. > > I'm going to need this feature soon too... I'd be happy to look at any > code you write and see if we can pull it together into a generic module > between us? I guess it would fall under the CatalystX::Elements > umbrella, if that's still happening. I don't use Catalyst much recently so I don't have time to work on that idea. But please use the CatalystX::Elements name if you like it - I conjured it just for stuff like this hypothetical Catalyst::Controller::Registration. At github there is already one prototype element: http://github.com/zby/catalystx-elements-comments -- 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 wrote:
> * Zbigniew Lukasiak [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 1:26 PM, Ben van Staveren
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 Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Apr 26, 2010 at 09:36, Dermot wrote:
>> On 21 April 2010 18:01, J. Shirley 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 Fri, Apr 23, 2010 at 12:36 PM, Oleg Pronin 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 wrote: > > > On Sat, Jan 23, 2010 at 7:20 PM, Hans Dieter Pearcey > 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] FormFu or FormBuilder
On Fri, Oct 30, 2009 at 2:56 PM, Kiffin Gish wrote: > I noticed that both FormFu and FormBuilder are mentioned in the Catalyst > tutorial, and would be interested to hear the advantages and > disadvantages of using the one or the other. Have a look at: http://www.perlfoundation.org/perl5/index.cgi?form_processing There is also a Form page at the Catalyst wiki - but FormBuilder is not mentioned there at all: http://dev.catalyst.perl.org/wiki/howtos/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] Basic CRUD example failing
On Wed, Oct 28, 2009 at 6:07 AM, Jason Dixon 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. > > Delete I may have not updated my view knowledge - but I would write that as: Delete 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] Validating single arg id
On Fri, Oct 16, 2009 at 5:24 PM, iain wrote:
> Bill Moseley wrote:
>>
>> I have a number of methods that start something like this:
>>
>> sub view : Local Args(1) {
>> my ( $self, $c, $id ) = @_;
>>
>> my $obj = $c->model( 'DB::Foo' )->find( $id )
>> || return $c->res->status( 404 );
>>
>> If $id is not valid then I might, as in that example, return with a 404
>> status.
>>
>> Of course, if $id is suppose to be an integer and a non-integer or an
>> integer out of range is provided then the the database will throw an
>> exception, which I want to prevent. I want valid ids to return an object
>> and *anything* else to return undef before hitting the database.
>>
>> This is pretty low-level validation -- just validating primary key. For
>> more complex validation I use a form validation module.
>>
>> Obviously, I could do something like
>>
>> return $c->res->status(404) unless $c->model('DB::Foo')->is_valid_id( $id
>> )
>>
>> in every method, but that's not very DRY.
>>
>> What I've done in the past is override the find() or search() method in my
>> model base class so that whatever $id is passed it is validated. Specific
>> model classes can override the is_valid_id() method if they use keys that
>> are not a common key format (i.e. different integer range or non-integer
>> key).
>>
>> What's you approach to validating that $id in situations like this where
>> there's a single id?
>>
>> Do you just let the database throw the exception? I prefer to return 404s
>> for invalid ids, regardless of their format (and likewise for ids that point
>> to valid object, but are not owned by the current user instead of a 403).
>>
>
> We did this sort of thing until we started to use chained actions.
> Now we validate once at the start of the chain e.g.
>
> sub start : Chained('/') CaptureArgs(0) {
> my ( $self, $c ) = @_;
> # your validation here
> my $obj = $c->model( 'DB::Foo' )->find( $id )
> || return $c->res->status( 404 );
>
> $c->stash->{obj} = $obj;
>
> return 1;
> }
>
> sub view : Chained('start') Args(0) {
> my ( $self, $c ) = @_;
> # do something with $c->stash->{obj}
> return 1;
> }
What is the advantage of this over:
sub view : Local {
my ( $self, $c, $id ) = @_;
$self->start( $c, $id );
# do something with $c->stash->{obj}
return 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/
Re: [Catalyst] How to handle development vs production, required vs recommended module dependencies
On Mon, Aug 31, 2009 at 3:44 AM, Daniel Austin 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] best practice for a protocol mechanism?
On Tue, Sep 8, 2009 at 10:32 AM, Jens Schwarz wrote:
> Hi,
>
> I currently have an Catalyst application with several controllers and even
> more actions. Some of those actions require that I call my protocol action
> that - surprise, surprise - does some protocol work. This action is located
> in the Root controller. Right now I accomplish this with code snippets like
> this:
>
> package MyApp::Controller::Foo
> ...
> sub some_action :Local {
> ...
> $c->forward("MyApp::Controller::Root","myProtocolAction",["some message that
> should be protocolled"]);
> ...
> }
>
> Is there some neater way to do this? (I started reading into the "Chains"
> topic but do not know if this protocolling mechanismn would be the right use
> case for chaining.)
I am not entirely sure that I understand what you mean by protocol
action - but how about a plain old method call:
MyApp::Controller::Root->myProtocolAction( $c, "some message that
should be protocolled" );
--
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 Napiorkowski wrote: > > > > > - Original Message >> From: Tomas Doran >> To: The elegant MVC web framework >> 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 Lukasiak wrote: > On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawa 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 Lukasiak 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 Lukasiak wrote:
>> On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawa
>> 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
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 Lukasiak wrote:
> On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawa 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/
Re: [Catalyst] OpenID authentication and LWPx-ParanoidAgent
On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawa 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/
[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 Miyagawa 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 Doran 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:49 AM, Zbigniew Lukasiak wrote:
> On Thu, Jul 9, 2009 at 11:03 AM, Gunnar Strand 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.
>
And by the way I think that a no-redirect login is more elegant
solution. It can be done by intercepting the dispatching in auto and
checking there if the user is authenticated and if no then also
checking if there are credential parameters in the request.
Cheers,
Zbigniew
>
> --
> 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] How to do pass-through login?
On Thu, Jul 9, 2009 at 11:03 AM, Gunnar Strand 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 Strand 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 Gish 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 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 :
> 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] Using test database with TWAM?
On Thu, Apr 30, 2009 at 5:42 PM, Jesse Sheidlower wrote: > > I assume this is more of a general Perl testing question than > a Catalyst question, but > > I finally sat down to write real tests for one of my apps, > with the hopes that I'll do this regularly for everything. I > was using the Tutorial chapter on testing, and the docs for > Test::WWW::Mechanize::Catalyst, for ideas. > > I quickly hit a wall because I couldn't figure out how to run > this with a test database. Since I need to test modification > and deletion stuff, but have real data, I can't just run this > against my actual app. So I figured I would dump the sql from > my production app and have my test program load this into a > database called "test-db" or whatever, having the same format > and schema as the real db, and then just drop the test db at > the end of the test. > > Unfortunately I don't know how to do this from a test script, > and I don't know how to tell TWAM to run a particular app but > with a different DBIC schema (in this case, the identical one > but with a different name, pointing to the test db) instead. > Or how to do the same thing, but with TWAM hitting the app > with the external-server method (so I can test the Apache > deployment). > > Would be grateful for any pointers. Hmm - first question why a different DBIC schema? Why not use the same schema only connected to a different dsn? And if you go that path - then you can move the connection details (dsn) from the Catalyst model code into a config file. The final step would be to use different config files for the tests and for the real app. -- 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 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 : > 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] Announce: HTML::FormHandler
On Mon, Mar 23, 2009 at 9:07 PM, Gerda Shank wrote: > HTML::FormHandler is an HTML form class written in Moose. It allows you to > define HTML form fields and validators. It can be used for both database and > non-database forms, and will automatically update or create rows in a > database. > > One of its goals is to keep the controller interface as simple as possible, > and to minimize the duplication of code. In most cases, interfacing your > controller to your form is only a few lines of code. > > You can split the pieces of your forms up into logical parts and compose > complete forms from FormHandler classes, roles, fields, collections of > validations. You can write custom methods to process forms, add any > attribute you like, use Moose before/after/around. FormHandler forms are > Perl classes, so there's a lot of flexibility in what you can do. > > http://search.cpan.org/~gshank/HTML-FormHandler-0.19/ I think you forgot the most important part which is that there is a mailing list for FormHandler: http://groups.google.com/group/formhandler?hl=en and an IRC channel is created: #formhandler at irc.perl.org. The code repository is by the way at: http://github.com/gshank/html-formhandler/tree/master -- 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 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/
Re: [Catalyst] Re: In search of RESTful CRUD holy grail
On Wed, Mar 4, 2009 at 9:12 PM, Aristotle Pagaltzis wrote: > * Zbigniew Lukasiak [2009-03-04 13:30]: >> CatalystX::CRUD::REST has a well described RESTful URI >> structure: [â¦] I think everyone will agree that this is >> indeed REST. > > URI structures and REST are completely ortogonal. That statement > is about as meaningful as saying that a URI structure is Perlish. OK - does that mean that you agree that someone can build a RESTful CRUD with that URI structure? -- 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] 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/ -> update record # DELETE/foo/ -> delete record # GET /foo/ -> view record # GET /foo//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/ -> update record # DELETE/foo/by_id/ -> delete record # GET /foo/by_id/ -> view record # GET /foo/by_id//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//edit_form' needs to make a PUT request to /foo/by_id/. 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/' 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/ -> update record or return the error encoded for non-browsers # PUT /foo/by_id//edit_form -> update record or return the error encoded as HTML form # DELETE/foo/by_id/ -> delete record # GET /foo/by_id/ -> view record (for non-browsers encoded) # GET /foo/by_id//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/-> update record or return the error encoded # PUT /foo/by_id/?x-view=edit_form -> update record or return the error encoded as HTML form # DELETE/foo/by_id/-> delete record # GET /foo/by_id/ -> view record (encoded) # GET /foo/by_id/?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 11:35 PM, Peter Karman 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 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/ -> update record >>>>> # DELETE /foo/ -> delete record >>>>> # GET /foo/ -> view record >>>>> # GET /foo//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/?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] OT: edit/add seperate actions?
On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman 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/ -> update record >>> # DELETE /foo/ -> delete record >>> # GET /foo/ -> view record >>> # GET /foo//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/?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 7:33 PM, Peter Karman 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/ -> update record > # DELETE /foo/ -> delete record > # GET /foo/ -> view record > # GET /foo//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/?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] Re: OT: Better TT pager?
On Thu, Jan 22, 2009 at 4:48 PM, Oliver Charles wrote: > I might as well join in with this :) Here's what we use at work: > > [% IF pager %] > > Page [% pager.current_page %] of [% > pager.last_page %] > « > [% IF pager.previous_page %] > < > [% END %] > > [% start = (pager.current_page - 3) > 0 ? (pager.current_page - 3) : 1; > FOREACH page IN [ start .. pager.last_page ] %] > [% LAST IF loop.count > 6 %] > > [% page %] > > [% END %] > > [% IF pager.next_page %] > > > [% END %] > » > > [% 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 C<< <> >> Pager adapted from example by Oliver Charles. I hope you are satisfied. Cheers, Zbigniew PS. Here is the adopted version: [% IF pager %] Page [% pager.current_page %] of [% pager.last_page %] [% IF pager.previous_page %] « < [% 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 %] [% page %] [% ELSE %] [% page %] [% END %] [% END %] [% IF pager.next_page %] > » [% END %] [% 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 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 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/
[Catalyst] (OT) Navigation parameters in session
Here at work we have this rule that the page urls should not contain any parameters (think page number, sorting order etc) - but that everything should be hidden in the session. I think I can have some fighting chance to counter that trend if I feed the bosses with some authoritative enough documents. Do you guys know something fitting? Or maybe it is me who is mistaken - and this is a great idea indeed? -- 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] 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 trial&error 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
On Fri, Feb 20, 2009 at 6:57 PM, Jonathan Rockway 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] New version of InstantCRUD
On Sat, Feb 21, 2009 at 10:08 AM, Oliver Gorwits wrote: > -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...?). Have you thought about a REST-like inteface? What do you think about http://search.cpan.org/~lsaunders/Catalyst-Controller-DBIC-API-1.001000/lib/Catalyst/Controller/DBIC/API.pm ? I would like to have something like that but more lightweight and I am really waiting for the Moose port - so that instead of base controller or plugin this could be a role. -- 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: New to Catalyst questions
On Tue, Feb 17, 2009 at 9:18 PM, Rodrigo wrote: >> >> > 3) Walkthrough of creation of a simple app end to end. >> >> Yes please, a full example tutorial is just what we need! > > And example apps! > You might try Catalyst::Example::InstantCRUD - it is a scaffolding (ala Rails) - but you can also treat it as an example generator. It generates example applications with CRUD operations on the tables from your database (or if you don't provide a DSN - from the example database it can generate). It is a work in progress. -- 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 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 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] RFC: The paradox of choice in web development
On Sun, Feb 15, 2009 at 10:04 AM, Dan Dascalescu wrote: > > I think I can agree with that. What I'm saying is that there's simply > too much useless choice. Random example: > > Data::Dumper > vs. > Data::Dump. > > I've just discovered Data::Dump but it appears to beat the crap out of > Data::Dumper. Yet does it say anywhere "Hey, if you're getting started > with Perl and need to dump variables, use Data::Dump, and don't waste > your time investigating other modules"? If I were the author of > Data::Dumper, I'd somehow retire the module, or plaster a note in the > POD redirecting people to Data::Dump. Imagine a programmer new to Perl > picks up an example that uses Data::Dumper. Will they find out about > Data::Dump? No. There is also: http://search.cpan.org/~jmcnamara/Data-Dumper-Perltidy-0.01/lib/Data/Dumper/Perltidy.pm And frankly I think this naming convention is the way to go - this is much better findable than Data::Dump. And there is also Data::Dumper::HTML, that just recently I found very useful for debugging in web context. And to complicate the things - I cannot say for sure that this is the reason, but it is quite probable that Data::Dumper would have much better interface now if it was not in the Core. Modules that get into the Core generally get frozen and stop evolving because too many things rely on them. This is a complex matter and I lean towards the 'steady release cycles plus rigorous deprecating' proposed by chromatic in his recent Modern Perl blog notes (http://www.modernperlbooks.com/mt/). 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: The paradox of choice in web development
On Sun, Feb 15, 2009 at 10:00 PM, Ashley wrote: > On Feb 15, 2009, at 12:31 PM, Octavian Râsnita wrote: >> >> "The list of CPAN modules you shouldn't use because they are not good:" I've once tried to start a discussion at PerlMonks about that: http://perlmonks.org/?node_id=515728 > > Everyone should consider writing more reviews on the CPAN reviews site too. > It's directly connected with them. It wouldn't carry the same sort of > "authority" as a formal list from a group but I make my choices of > what to at least try first based on reviews somewhat often. > > See also: > http://www.perlfoundation.org/perl5/index.cgi?recommended_cpan_modules To add to this - I've also started a page for comparing Form Processing modules at this same p5p wiki: http://www.perlfoundation.org/perl5/index.cgi?form_processing I've tried to start from the little, well designed tasks - and later go to the bigger more difficult fields like comparint full web frameworks, but sure enough there is also a web framework page at the p5p wiki: http://www.perlfoundation.org/perl5/index.cgi?web_frameworks But there is one even more important point that I would like to make - I think it is time that we all start writing reviews. It is not an easy task - and only with practice we'll learn how to do it right, how to do it so that the whole community will benefit instead of starting a fight. I personally find it very difficult to write a good critique without hurting the authors feelings, but it also goes the other way - if we have more critical reviews the authors (and thats all of us n'est ce pas?) the authors will learn to treat them as tips how to improve their software rather as something attacking 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] Re: loading data types from Oracle DB with DBIx::Class::Schema::Loader
On Wed, Feb 11, 2009 at 1:47 PM, Karl Forner 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 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 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 L actions to form classes derived from
> L, a component of John Siracusa's burgeoning L
> framework. Unlike some other form-loading modules (see L),
> 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 C 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
> L, 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;
> I the forms (including the first) will be stored under a separate
> (L) 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 C
>
> 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
>}
>);
>ret
Re: [Catalyst] mod_perl converts latin1 to utf8 !?
On Sun, Dec 28, 2008 at 12:17 PM, Bjørn-Helge Mevik 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/
Re: [Catalyst] OT: Better TT pager?
On Tue, Dec 23, 2008 at 12:34 PM, Jesse Sheidlower wrote:
>
> Some time ago, I developed or stole a TT pager that I now use
> in all of my Cat apps. It looks like this, though occasionally
> with minor CSS tweaks:
>
> ---
>
>
> [% IF pager.last_page > 1 %]
>
> [% IF pager.previous_page %]
>[previous>]
> [% ELSE %]
>[previous]
> [% END %]
> [% FOR page IN [1..pager.last_page] %]
>[% IF page == pager.current_page %]
> [[% page %]]
>[% ELSE %]
> [[% page %]]
>[% END %]
> [% END # FOR...%]
>
> [% IF pager.next_page %]
>[next]
> [% ELSE %]
>[next]
> [% END %]
>
> [% END # IF... %]
>
> ---
>
> However, a frustration is that when I have excessively large
> result sets (such as might generate dozens or hundreds of
> pages), it takes a long to generate and looks like hell. So
> I'd like to change this to one that only shows, say, 10 pages,
> and then has a "previous ten/next ten" and/or "first"/"last"
> or something like that, whatever the standard is now.
>
> Does someone have a model I can steal from?
>
In my very old code I have:
sub pages_links {
my ( $c, $pages_count, $valid ) = @_;
my $curr_page = $valid->{page} || 1;
my $result = '';
if ( $curr_page > 12 ){
$result .= create_param_link ( $c, 'page', 1, $valid ) . ' ... ';
}
for my $page ( max ( 1, $curr_page - 10 ) .. min ( $curr_page +
10, $pages_count ) ){
$result .= create_param_link ( $c, 'page', $page, $valid );
}
if ( $curr_page < $pages_count - 11 ){
$result .= ' ... ' . create_param_link ( $c, 'page',
$pages_count, $valid );
}
return $result;
}
This was before I discovered uri_with (or perhaps even before that was
introduced) and create_param_link is what I wrote instead. $valid is a
hash ref of the rest of the parameters.
--
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/
[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] Catalyst::Controller::SOAP "no operation `index' for portType" error
On Thu, Nov 27, 2008 at 10:10 PM, Ian Sillitoe <[EMAIL PROTECTED]> wrote:
> I've been playing with this recently. What have you actually defined your
> endpoint to be in the WSDL?
>
>
>
> ...
>
>
>
>http://example.com/service"/>
>
>
>
>
Here is the definition:
gSOAP 2.7.12 generated service definition
http://localhost:1234/sms/"/>
>
> I think the example in the synopsis shows you how to set up an endpoint for:
>
>/service/index
>
> Which then dispatches to, e.g.
>
>/service/operation1
>/service/operation2
>
> Did you mean that? The usual behaviour is for the endpoint to be set to the
> root path - e.g.
>
>/service
>
> If this is what you meant then:
>
>sub index :Path('') SOAP('RPCEndpoint') {}
>
> or just use one of the subclassed controllers which sets this default
> behaviour for you (depending on your style of WSDL)
>
>use base qw/C::C::SOAP::RPC/;
># or
>use base qw/C::C::SOAP::DocumentLiteralWrapped/;
>
Hmm - the subclassed controllers work, but the original one with 'sub
index' does not, no matter what I try (:Local, :Path('')).
When I read the code for C::C::SOAP::DLW it has:
sub rpc_endpoint :Path('') :ActionClass('SOAP::DocumentLiteralWrapped') { };
instead of index.
--
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] 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/
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] Catalyst, MVCs and other MVCs
On Tue, Nov 4, 2008 at 9:46 PM, J. Shirley <[EMAIL PROTECTED]> wrote: > On Tue, Nov 4, 2008 at 12:23 PM, Jonathan Rockway <[EMAIL PROTECTED]> wrote: >> * On Mon, Nov 03 2008, Jacinta Richardson wrote: >>> I know that Catalyst is about dispatch more than about CRUD, but I'd love >>> pointers to a tutorial about how to get a basic system with working CRUD up >>> and >>> working within minutes. >> >> I'm not sure that this will tell you anything valuable. What's good for >> quickly hacking something together in five minutes is rarely good for an >> application that needs to be maintained over many years. >> >> Regards, >> Jonathan Rockway >> > > The value is in "marketing". Showing what is possible in comparison > to other frameworks, which tend to show CRUD applications has value in > establishing convention. It's not only marketing: establishing conventions is one, quick learning is another benefit. And if you subscribe to the Agile way of doing software - then you should also see the benefit of having a quick prototype. -- 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] Catalyst, MVCs and other MVCs
On Tue, Nov 4, 2008 at 4:25 AM, Jacinta Richardson <[EMAIL PROTECTED]> wrote: > G'day everyone, > > I've just joined and am looking forward to learning more about Catalyst. I > run > a business called Perl Training Australia, which - imaginatively - teaches > Perl, > in Australia. ;) > > I'm writing a conference paper comparing a number of Perl's popular MVCs. > I'm > somewhat familiar with Catalyst and have attempted (unsuccessfully) to use it > in > a couple of projects. Fortunately my paper is from a beginners point of view. > > If anyone has anything they'd like to share about Catalyst vs Jifty, Gantry, > CGI::App, Maypole, Mojolicious etc, I'm certainly open to insights. I don't > have enough time to learn all of these frameworks properly so I'm very > dependent > - at this stage - on information from the users and creators. > > My paper (and findings) will be available in December. I'm rating MVCs on: >* community participation >* ease of installation >* flexibility >* quality of documentation >* ease in creating a particular sample program (with CRUD) > > I know that Catalyst is about dispatch more than about CRUD, but I'd love > pointers to a tutorial about how to get a basic system with working CRUD up > and > working within minutes. When I first tried Catalyst (about a year ago) I > worked > through the tutorial but it did not cover all aspects of CRUD (I've forgotten > what was missing) and I later found that the modules it recommended were > deprecated. So I'd really, really love advice here. There is a CRUD page at the Catalyst wiki: http://dev.catalystframework.org/wiki/crud My project is Catalyst::Example::InstantCRUD - that generates a CRUD scaffolding (ala Rails). It is now a bit dated - and rather a big pile of spaghetti - so I work on a new version (unfortunately I wait for new release of underlying libraries - so I don't know if it can be ready by December). See my ideas at: http://dev.catalystframework.org/wiki/crud/instantcrud. I need to add that my primary goal for InstanCRUD is to make it a learning resource. I believe that having a working example, tailored to the DB structure, that can be tweaked and experimented with is the quickest way to learn. -- 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] Change the default view
On Mon, Nov 3, 2008 at 2:59 PM, Dermot <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I have a small subroutine/method that checks if a file exists. The
> method is being called by an Ajax function. Unlike the other functions
> in it's Class, this method doesn't need to render a tt template, it
> should simply return 1 or 0. .Catalyst is complaining that is can't
> render the template for this method but I don't want to render a
> template. I'm sure this is something to do with RenderView/end but I
> can't get it to stop doing -> Motion::View::TT->process.
>
>
> Any tips please?
> TIA,
> Dp.
>
>
> sub fileExists : Local {
> my ($self,$c) = @_;
> my $type = $c->request->param('type');
> my $number = $c->request->param('number');
> my $path = getPathFromNumber($number,$type);
> if (-e $path) {
>return 1;
replace this with $c->response->body( 1 ). If the response body is
set then RenderView does not call the view to generate it.
> }
> else {
>return 0;
> }
> $c->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/
>
--
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] ANNOUNCE: SimpleDB - Auth configuration made easy
Hi,
I've looked at the documentation:
The SimpleDB Realm class configures the Catalyst authentication system
based on the following:
* Your user data is stored in a table that is accessible via
$c->model('User');
* Your passwords are stored in the 'password' field in your users
table and are not encrypted.
* Your roles for users are stored in a separate table and are
directly accessible via a DBIx::Class relationship called 'roles' and
the text of the role is stored in a field called 'role' within the
role table.
* Your user information is stored in the session once the user is
authenticated.
For the above usage, only one configuration option is necessary,
'user_class'. user_class should contain the class name of your user
class. See the "PREPARATION" section for info on how to set up your
database for use with this module.
There seems to be some mismatch there - in the first point above you
mention that there is a default user class - 'User' - but then you say
that user_class is a required config option. Or maybe I am mistaken?
It is not clear what really the first point above means.
Another question - have you thought about using
http://search.cpan.org/~groditi/DBIx-Class-EncodedColumn-0.2/lib/DBIx/Class/EncodedColumn.pm
(or the older DigestColumn) to simplify the interface?
Cheers,
Zbigniew
On Mon, Oct 27, 2008 at 1:36 AM, Jason Kuri <[EMAIL PROTECTED]> wrote:
> Hey all,
>
> Catalyst authentication configuration just got a whole lot easier.
>
> I just released two updates to CPAN that will make Auth configuration
> much much easier for the 'average' case where you have user data
> stored in an SQL database and you are using passwords for
> authentication.
>
> Now, the 'basic' config using plaintext passwords looks like this:
>
>__PACKAGE__->config->{'Plugin::Authentication'} =
>{
>default => {
>class => 'SimpleDB',
>user_class => 'MyApp::User',
>}
>}
>
> For the 'basic' config using a hashed password - just a bit more
> complex:
>
>__PACKAGE__->config->{'Plugin::Authentication'} =
>{
>default => {
>class => 'SimpleDB',
>user_class => 'MyApp::User',
>password_type => 'hashed',
>password_hash_type => 'SHA1'
>}
>}
>
> Hopefully, people will not find this config overwhelming. :-)
>
> For those who are interested, the custom configuration is accomplished
> by using a custom Realm, SimpleDB, which is part of the most recent
> Catalyst::Authentication::Store::DBIx::Class dist. A lot of
> flexibility can be gained in configuration and functionality by
> creating custom Realms. This is just one example.
>
> The modules are available (or will be soon) at:
>
> http://search.cpan.org/~jayk/Catalyst-Authentication-Store-DBIx-Class-0.108/lib/Catalyst/Authentication/Realm/SimpleDB.pm
>
> ( A preview of the docs are available here: http://scsys.co.uk:8001/19881
> )
>
> and
>
> http://search.cpan.org/~jayk/Catalyst-Plugin-Authentication-0.10008/
>
> If anyone has any questions or comments, please reply to this email,
> or find me on #catalyst.
>
> I am also soliciting anyone who is willing to take a crack at
> simplifying the Auth section of the Catalyst tutorial by using this
> module, as I think most users are looking to do exactly this type of
> config when they first approach Catalyst and are reading the
> Tutorial. Any volunteers?
>
> JayK
>
> ___
> 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] 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
Hmm, Maybe this: http://perlalchemy.blogspot.com/2008/06/dbixclass-gotchas.html - would be a better intro into the subject. Z. On Mon, Aug 18, 2008 at 3:20 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote: > 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/ > -- 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] Catalyst site design drafts feedback thread
Just one idea - how about using some CSS framework? This way we can get some nice colour and layout with minimal effort. There is a discussion at http://news.ycombinator.com/item?id=218597 about CSS frameworks. Z. On Tue, Jun 17, 2008 at 8:59 AM, Gabriel Vieira <[EMAIL PROTECTED]> wrote: > On Tue, Jun 17, 2008 at 3:15 AM, Tobias Kremer <[EMAIL PROTECTED]> wrote: >> I've incorporated some of the suggestions into the next version of the >> mockup which can be found here: >> >> http://funkreich.de/catalyst/v2.png >> >> I'm still trying to figure out what goes where. The texts and navigational >> elements aren't final either. >> >> Any feedback is greatly appreciated! > > Okay. > I still vote #1 and I still think it would be really nice with the > suggestion I've made. Buuut, this new candidate can be a good one. > > Let's go: > 1) I suggest you start develop the HTML/DHTML code instead of drawing > it. It's easier, cleaner, more beautiful and we finally can see how it > will be. > 2) The Catalyst logo is to small, it needs to be impressive, needs > to be memorized by the visitor, it's beautiful, so show it! > 3) The red/orange banner is too big, there is no needs, you are giving > attraction to it instead of the logo or something that attracts to > Catalyst. > 4) There is NOTHING in the top. Waste of space. > 5) The bottom will be really fine, will see when you start to generate > HTML code. > > That's all folks, > > -- > Gabriel Vieira > > ___ > 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/
[Catalyst] Actions as Moose::Role
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/
___
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] Multiple inheritance of controllers
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/
Index: t/sublcassed_chained.t
===
--- t/sublcassed_chained.t (revision 0)
+++ t/sublcassed_chained.t (revision 0)
@@ -0,0 +1,34 @@
+#!perl
+
+use strict;
+use warnings;
+
+use FindBin;
+use lib "$FindBin::Bin/lib";
+
+our $iters;
+
+BEGIN { $iters = $ENV{CAT_BENCH_ITERS} || 1; }
+
+use Test::More tests => 2;
+use Catalyst::Test 'TestApp';
+
+#
+# This is a simple test where the parent and child actions are
+# within the same controller.
+#
+{
+my @expected = qw[
+ TestApp::Controller::Action->begin
+ TestApp::Controller::Action::SubclassedChained->basefoo
+ TestApp::Controller::Action::SubclassedChained->baseendpoint
+ TestApp->end
+];
+
+my $expected = join( ", ", @expected );
+
+ok( my $response = request('http://localhost//basefoo/1/baseendpoint/2'), 'subclassed chained + local endpoint' );
+is( $response->header('X-Catalyst-Executed'),
+$expected, 'Executed actions' );
+}
+
Index: t/lib/TestApp/Controller/Action/SubclassedChained.pm
===
--- t/lib/TestApp/Controller/Action/SubclassedChained.pm (revision 0)
+++ t/lib/TestApp/Controller/Action/SubclassedChained.pm (revision 0)
@@ -0,0 +1,9 @@
+package TestApp::Controller::Action::SubclassedChained;
+
+use strict;
+use warnings;
+
+use base qw/Intermediate/;
+
+1;
+
Index: t/lib/Intermediate.pm
===
--- t/lib/Intermediate.pm (revision 0)
+++ t/lib/Intermediate.pm (revision 0)
@@ -0,0 +1,10 @@
+package Intermediate;
+
+use strict;
+use warnings;
+
+use base qw/Catalyst::Controller Base/; # this one does not inherit actions from Base
+#use base qw/Base Catalyst::Controller/; # this one works
+
+1;
+
Index: t/lib/Base.pm
===
--- t/lib/Base.pm (revision 0)
+++ t/lib/Base.pm (revision 0)
@@ -0,0 +1,11 @@
+package Base;
+
+use warnings;
+
+use base qw/Catalyst::Controller/;
+
+sub basefoo :CaptureArgs(1) :Chained('/') { }
+sub baseendpoint :Args(1) :Chained('basefoo') { }
+
+1;
+
___
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] 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
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] 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] 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] 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] 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] RFC: Catalyst::Controller::REST::DBIC
On Mon, May 5, 2008 at 11:36 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>
>
> > > To me the /foo/{token} URI is only acceptable if it is understood that
> > > no further custom object level URIs can then be added
> > > (/foo/{token}/disable for example) and that lookup can only ever be by
> > > {token} rather than {name} or something else. For REST I can see that
> > > this is possible but I do feel that putting something between the base
> > > and the token to clearly identify it as object level is generally the
> > > safest option.
> >
> > I like to map my URLs out in a definitive hierarchy. If people want
> > an implicit create action, a /foo/-/create looks better to me than
> > having /foo/create, because I have the level of /foo to be the plural,
> > /foo/{id} to be the singular (in a simple CRUD example).
> > /foo/-/create is fine, because you can have a rule that "-" is never
> > an acceptable record identifier.
>
> I think that's a pretty reasonable suggestion. It doesn't solve the
> different object lookup methods point, but I think it's reasonable for
> that to justify a subclass.
>
> However, I do still have a nagging feeling that having /foo/create and
> /foo/-/{token} is preferable because it's easier to not make an action
> with a PathPart of "-" than it is to not have a record whose identifer
> is "-". But I accept that your method would mean that the "-" is only
> seen if you want non-standard methods.
How about /foo/instance/{token} ? This way it would be clear that
'foo' is just the name of the object class and that the object for
REST operations is in /foo/instance/{token}.
--
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] RFC: Catalyst::Controller::REST::DBIC
On Sun, May 4, 2008 at 3:54 PM, J. Shirley <[EMAIL PROTECTED]> wrote:
> On Sun, May 4, 2008 at 1:52 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> > On Sun, May 4, 2008 at 7:05 AM, J. Shirley <[EMAIL PROTECTED]> wrote:
>
> > >> > On a side note about REST - REST doesn't mean human readable URLs.
> > It
> > > means representative URLs. The bit about cd/id/{CDID}/ smells like
> > > named parameters going into positional parameters. What is the real
> > > difference between cd?id={CDID}&action=delete, aside from different
> > > characters? Where as with REST, /cd/{id} is a unique identifier for
> > > that object and hence a full representation.
> >
> > The problem I see with /cd/{id} is that when you have a primary key
> > that is 'create' - this would clash with the 'create' action.
> > /cd/id/{id} let's you separate the reserved words from the user data.
> >
> >
>
> A pet peeve of mine is that people seem to have this weird idea that
> primary key == id. An id can just be some human readable mechanism to
> looking up the item, where as the primary key is what is actually used
> by the database to determine the relations.
>
> They do not have to be the same field but often times they are out of
> convenience. In cases like this, they simply shouldn't be though.
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.
>
>
>
> ___
> 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 Sun, May 4, 2008 at 1:28 PM, luke saunders <[EMAIL PROTECTED]> wrote: > > > > I think we can still make it compatible, if we agree on some kind of > > internal API. > > > > As in make this module compatible with your new module? Perhaps as a > base class without form generation? Yes - I am thinking about something where you have a separate methods for validating the parameters and updating/creating the object in the database - so that I could override them in my sub-class. > > > > It is I think quite common convention to use '.' dot for that: > > > > param1.some_relation.field_value > > > > or > > > > some_param.some_multi_relation.1.field_value > > > > Makes sense. I prefer that to the add_to_rel action, especially if > this is to remain a REST module rather than an RPC module. > It does not bother me if you leave those actions. > The piece of functionality I always wanted but didn't see a clean > solution to was specifying complex conditions to the 'list' action, > for example only CDs which have a track called 'Badgers', which > requires specifying a join and a related condition. I wonder if it > makes sense to represent that this way too. > Well - this is in my plans as well - as search in InstantCRUD :) I am thinking to base it on the technique I described in my Advent article: http://catalyst.perl.org/calendar/2007/16 -- 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 12:23 PM, luke saunders <[EMAIL PROTECTED]> wrote:
>
> On Sun, May 4, 2008 at 10:20 AM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> >
> > 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.
> >
> > I've been planning for a more REST-like update to InstantCRUD for a
> > long time. My approach is a bit different because for validation and
> > for generating form's HTML I use HTML::Widget. I believe validation
> > is important and separate enough to have a separate package (and I
> > don't want to reinvent the wheel - so I use what is available at
> > CPAN). I also choose to generate the HTML - because I believe there
> > is too much logic (classes for errors, options from the database,
> > subforms from the database - see below) in it for the simplistic
> > Template::Toolkit language - an elegant solution for that could be
> > also a TT plugin.
> >
> > Now I am working on porting Instant to use Rose::HTML::Form instead of
> > HTML::Wiget - it will give it much more solid base.
> >
>
> I thinking generating the form is a step too far for this sort of
> thing, normally I just want the API. In some cases I'll be generating
> the form HTML with Jemplate for example.
I think we can still make it compatible, if we agree on some kind of
internal API.
>
>
> > One more difference in my approach is that the 'update' action will be
> > able to edit not just one row from the DB - but all the interrelated
> > records that together make a full object. This means also adding and
> > removing the related records - so I'll not have the add_to_rel
> > remove_from_rel actions.
> >
>
> Interesting. How are you representing the related objects in the request?
>
It is I think quite common convention to use '.' dot for that:
param1.some_relation.field_value
or
some_param.some_multi_relation.1.field_value
>
>
> > There is also an effort by Peter Carman:
>
Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC
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.
I've been planning for a more REST-like update to InstantCRUD for a
long time. My approach is a bit different because for validation and
for generating form's HTML I use HTML::Widget. I believe validation
is important and separate enough to have a separate package (and I
don't want to reinvent the wheel - so I use what is available at
CPAN). I also choose to generate the HTML - because I believe there
is too much logic (classes for errors, options from the database,
subforms from the database - see below) in it for the simplistic
Template::Toolkit language - an elegant solution for that could be
also a TT plugin.
Now I am working on porting Instant to use Rose::HTML::Form instead of
HTML::Wiget - it will give it much more solid base.
One more difference in my approach is that the 'update' action will be
able to edit not just one row from the DB - but all the interrelated
records that together make a full object. This means also adding and
removing the related records - so I'll not have the add_to_rel
remove_from_rel actions.
There is also an effort by Peter Carman:
http://search.cpan.org/~karman/CatalystX-CRUD-0.25/lib/CatalystX/CRUD/REST.pm
- and I more or less agreed with Peter on some basics - so that
hopefully our code will be compatible and maybe even will form
together just one solution.
Finally I am waiting for the Moose port of Catalyst - so that all the
CRUD functionality could be just a Role instead of forcing the user to
'use base'.
>
> 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 Sun, May 4, 2008 at 7:05 AM, J. Shirley <[EMAIL PROTECTED]> wrote:
>
> On Sat, May 3, 2008 at 9:29 PM, Patrick Donelan <[EMAIL PROTECTED]> wrote:
> >
> > > 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]
> >
> > Those URLs don't strike me as very RESTful.
> >
> > Patrick
> >
>
> That is my first impression. My work is an enhancement from
> Catalyst::Action::REST, which is a great module already out on CPAN
> and used by other people (holoway++).
>
> I'm all for collaboration, but my work is mostly tied to have exposed
> webservices (in addition to a web-browser compatibility layer) via
> REST. By that I mean that I expect, and require, that I can do a PUT
> /api/rest/cd/[cdid], DELETE /api/rest/cd/[CDID]
>
> On a side note about REST - REST doesn't mean human readable URLs. It
> means representative URLs. The bit about cd/id/{CDID}/ smells like
> named parameters going into positional parameters. What is the real
> difference between cd?id={CDID}&action=delete, aside from different
> characters? Where as with REST, /cd/{id} is a unique identifier for
> that object and hence a full representation.
The problem I see with /cd/{id} is that when you have a primary key
that is 'create' - this would clash with the 'create' action.
/cd/id/{id} let's you separate the reserved words from the user data.
>
> I understand the limitations of /cd/id/{id} vs. /cd/name/{id}, but a
> lookup and redirection service is a better solution that polluting
> your absolute unique representative URL spaces.
>
> You can catch me on IRC next week, as I'm actively working on this for
> $work and it's getting real dev time (finally). My work is
> functionally complete, but lacking test cases; it is just a refactor
> of existing code in production.
>
> -J
>
>
>
> ___
> 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/
