Re: [Catalyst] Encoding UTF8 ?

2011-03-28 Thread Zbigniew Lukasiak
On Mon, Mar 28, 2011 at 7:50 PM, John M. Dlugosz wxju46g...@snkmail.comwrote:

  I don't understand why

 Catalyst::Plugin::Unicode::Encoding
 is necessary, based on the writup: it takes request arguments and converts
 them from whatever they came in to Perl's native encoding, and likewise for
 the response.

 But Perl is using UTF-8 in its strings anyway.  So what's it have to do
 with the engine error I noticed before?


The point is that if they are not marked as UTF-8 then they are treated as
bytes not characters.  In fact you should never think about the internal
storage of strings - it is not part of the API - it can be changed.  You
always need to decode external data if you want to treat it as strings and
not byte streams.

http://perldoc.perl.org/perlunitut.html has all the this introductory info.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Simple literal Model

2011-03-01 Thread Zbigniew Lukasiak
On Sat, Feb 26, 2011 at 6:22 AM, John M. Dlugosz wxju46g...@snkmail.comwrote:

  On 2/25/2011 9:30 AM, Ashley Pond V apv-at-sedition.com |Catalyst/Allow
 to home| wrote:

 What t0m suggested is perfectly fine but if you want to mimic the DBIC
 API with a different engine, this example does that (superficially and
 as a tutorial only): http://sedition.com/a/2739 Log file model–Apache
 access log. The reason that example makes sense is because the
 underlying model/data is similar: searchable, sortable rows. If you're
 trying to shoehorn in something dissimilar, you might be making a
 mistake.

 -Ashley

 I'm not sure to what extent it is wise or correct.
 The whole point of models is that it abstracts the model and I can change
 where the data comes from later, right?  So don't they all have an
 underlying abstract interface regardless of how they are sourced?


The only abstraction Catalyst::Model provides is initialization.  Personally
I don't like this approach but I cannot imagine what common abstraction it
could provide for so diverse models.  Some Catalyst::Model::xxx classes do
provide some additional functionality - like Catalyst::Model::DBIC which
adds the possibility to address the resutlsets with a shortcut - but it's
their own unique additions.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] FormHandler -- pro or con?

2010-12-15 Thread Zbigniew Lukasiak
On Wed, Dec 15, 2010 at 7:49 AM, Toby Corkindale t...@dryft.net wrote:
 On 13 December 2010 21:07, Octavian Rasnita orasn...@gmail.com wrote:
 From: Toby Corkindale t...@dryft.net

...
 True, but FormFu can also use Config::General code which is much clearer (or 
 other config formats accepted by Config::Any).

 It would be OK if H::FH would allow creating custom elements and validators, 
 filters... using Moose, but only generic elements, not related with any 
 form, and then allow us to use configuration files for using those elements 
 and constraints. It is not nice at all to need writing Perl code using Moose 
 for just creating an HTML form, but each one with his preferences. :-)



 But you can do that if you want..
 If you're just doing simple stuff, like name-of-field + type-of-field,
 then you could do something like this:

  my $form = HTML::FormHandler-new(
    item = $c-model('DB::User')-find($id),
    field_list = YAML::Load(form.yaml)
  );

There is MooseX::SimpleConfig that is used by Catalyst itself and fits
here very well.  With some Moose coercions this is enough to build any
Moose object and it let's you use any config file format that is
supported by Config::Any.

If only the underlying  MooseX::ConfigFromFile was more actively maintained.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] FormHandler -- pro or con?

2010-12-08 Thread Zbigniew Lukasiak
On Thu, Dec 9, 2010 at 2:44 AM, Toby Corkindale t...@dryft.net wrote:

 (I do have some code that programmatically generates the form config
 based on the object you're editting, although I use a precreated base
 for it)

Well - there is
http://search.cpan.org/~gshank/HTML-FormHandler-Model-DBIC-0.14/lib/HTML/FormHandler/Generator/DBIC.pm

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] FormHandler -- pro or con?

2010-11-30 Thread Zbigniew Lukasiak
On Tue, Nov 30, 2010 at 4:55 PM, Sir Robert Burbridge
rburb...@cisco.com wrote:
 To mitigate the awkwardness I felt
 about the API, use a pure-module approach (every form is a separate
 package/module, that inherits from a base form that's all rigged up the way
 I want it, along with a few really helpful roles that I drop in on forms
 here and there to do common stuff.

To be fair - this is the way Gerda always used it.  The actions
attribute with the possibility of having different functionality per
form (and field) *instance* were all my additions (copied by they way
from Data::FormValidator and FormFu).   I am starting to regret coding
that - it seems that it complicates the machinery too much.

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Catalyst with HTML::FormHandler

2010-11-06 Thread Zbigniew Lukasiak
Another question is MyApp/UserInterface/Form/User.pm in one of the
directories mentioned in the error message - that is in
C:/strawberry/perl/site/lib, C:/strawberry/perl/vendor/lib,
C:/strawberry/perl/lib, or  .?

Z.

On Sat, Nov 6, 2010 at 2:50 PM, Steve st...@matsch.com wrote:
 Sounds like you've got the correct 'use' line, what about the package
 declaration line in your form module?
 It should read 'package MyApp::UserInterface::Form::User;'

 On 11/5/2010 3:11 PM, Blaine Everingham wrote:

 Sorry the error message is

 Error: Can't locate MyApp/UserInterface/Form/User.pm in @INC (@INC
 contains: C:/strawberry/perl/site/lib C:/strawberry/perl/vendor/lib
 C:/strawberry/perl/lib .)
 Resource: User.pm
 Path: /MyApp-Software/lib/MyApp/UserInterface/Controller/Admin
 Location:   line 5

 Line 5 of /MyApp-Software/lib/MyApp/UserInterface/Controller/Admin/User.pm
 is:
 use MyApp::UserInterface::Form::User;



  Date: Fri, 5 Nov 2010 14:40:37 -0400
  From: st...@matsch.com
  To: catalyst@lists.scsys.co.uk
  Subject: Re: [Catalyst] Catalyst with HTML::FormHandler
 
  The actual error message would help...
  On 11/5/2010 2:33 PM, Blaine Everingham wrote:
   I'm new to Catalyst and and trying to build a simple form.
  
   In the Catalyst controller
   MyApp/UserInterface/Controller/Admin/Users.pm I've added an 'use
   MyApp::UserInterface::Form::User', however it can not find this file.
   Meaning that it's not in the INC path.
  
   Obviously I could push this directory on to the INC stack, but none of
   the examples that I've seen have had to do this. What is the proper
   way to go about this?
  
   Below is an example of the directory structure.
  
   MyApp/UserInterface/Controller
   MyApp/UserInterface/Controller/Admin
   MyApp/UserInterface/Controller/Admin/Users.pm
   MyApp/UserInterface/Form
   MyApp/UserInterface/Form/User.pm
   MyApp/UserInterface/Model
   MyApp/UserInterface/Schema
   MyApp/UserInterface/View
  
  
   ___
   List: Catalyst@lists.scsys.co.uk
   Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
   Searchable archive:
   http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
   Dev site: http://dev.catalyst.perl.org/
 
  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive:
  http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/


 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive:
 http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: Alternatives to Catalyst ?

2010-04-27 Thread Zbigniew Lukasiak
On Mon, Apr 26, 2010 at 11:59 PM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 * Zbigniew Lukasiak zzb...@gmail.com [2010-04-26 12:25]:
 This is a fine advice - but unfortunately the -param method
 call suffers from additional problem - which is described in
 much detail in the documentation (go to the NOTE at:
 http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).

 Yeah, but the -params hash has the converse problem: if you
 write

    $c-model-insert_person( name = $c-req-params-{'name'} )

 then you may be surprised to find out there are people with name
 like ARRAY(0xDEADBEEF). Of course that’s just a relatively minor
 case of data corruption. Worse is if you legitimately expect
 a parameter to have one or more values, eg. a pile of checkboxes.
 Then you have to constantly check whether you’re getting a scalar
 or an array reference.

 So either you use the legacy method and have to protect against
 getting more values than you wanted, or you use the suggested
 method and have to protect against getting fewer values than you
 expect in the general case.

 I briefly tried to write something to stick Hash::MultiValue into
 Catalyst to end the madness, but doing it properly would require
 a plugin, plus HTTP::BodyParser (I think) was using a misdesigned
 approach that made deep integration of H::MV impossible (with
 properly preserved k/v pair order).

 Could have written a Request role… but that seemed unsatisfying.

 I wonder whether it would be possible to rip out the respective
 bits from Cat and use just H::MV, and leave the current stuff to
 a compat plugin or something like that…

Not a very concrete answer - but I remember that Miyagawa talked about
fixing that in Plack::Request (and I am not sure but I think it also
involved H::MV) - so there might be some occasion for reuse :)

Cheers,
Z.


 Regards,
 --
 Aristotle Pagaltzis // http://plasmasturm.org/

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Alternatives to Catalyst ?

2010-04-26 Thread Zbigniew Lukasiak
On Mon, Apr 26, 2010 at 10:57 AM, Ævar Arnfjörð Bjarmason
ava...@gmail.com wrote:
 On Mon, Apr 26, 2010 at 09:36, Dermot paik...@googlemail.com wrote:
 On 21 April 2010 18:01, J. Shirley jshir...@gmail.com wrote:
 __END__
 Benchmark: running all, low, sep for at least 1 CPU seconds...
       all:  1 wallclock secs ( 1.11 usr +  0.00 sys =  1.11 CPU) @
 2917341.44/s (n=3238249)
       low:  0 wallclock secs ( 1.27 usr +  0.04 sys =  1.31 CPU) @
 12930179.39/s (n=16938535)
       sep:  1 wallclock secs ( 1.21 usr +  0.01 sys =  1.22 CPU) @
 3223081.15/s (n=3932159)

 Subroutines suck, lets all use hashrefs.

 Now that it's quietened down, I can ask a question. Does this I mean
 it's preferable to use

 $c-req-{parameters}-{foo}

 rather than

 $c-req-param('foo')

 Obviously I'd rather use the faster method but if I'm breaking the
 encapsulation in some ways that's going to bite me later, I'd steer
 clear.

 Obviously.

 Unless you're doing method calls in a tight loop somewhere in your
 code you *shouldn't care about this*. Now I've written code that
 actually *did* suffer from method call overhead but since you're just
 casually asking it's very unlikely that you're doing the same.

 Don't sprinkle premature optimizations around your codebase just
 because someone produced a benchmark showing one is faster than the
 other. You should be doing *profiling* of your  entire program, not
 micro-optimizing something that's likely 0.0001% of its total runtime.


This is a fine advice - but unfortunately the -param method call
suffers from additional problem - which is described in much detail in
the documentation (go to the NOTE at:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80022/lib/Catalyst/Request.pm#$req-%3Eparam).



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Alternatives to Catalyst ?

2010-04-26 Thread Zbigniew Lukasiak
On Mon, Apr 26, 2010 at 1:26 PM, Ben van Staveren
benvanstave...@gmail.com wrote:

 Because if you are working with, say, 10 people on a team, and you will have
 everyone merrily doing direct hash accesses, sooner or later, someone's
 going to fuck it up and something will break in a spectacular  fashion.


 I take your point even though I am not in a team.



 Even if you're not, direct hash accessing is basically akin to juggling
 grenades. It might go right for a long time, but eventually the pin's going
 to come out and there will be a very messy BLAM.

 Even if it is code you just write for yourself, still doesn't hurt to make
 sure you avoid the BLAM bit :)

If using  -params-{name} (i.e. the direct hash approach) is like
juggling grenades - then what is like using the -param( 'name' ) way
of doing it?
I am asking this because your grenades analogy gives the impression
that you you are against doing direct hash access for every price -
but I think the general advice is that in this particular case using
the -param( 'name' ) is worse than using the direct hash access.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Alternatives to Catalyst ?

2010-04-23 Thread Zbigniew Lukasiak
On Fri, Apr 23, 2010 at 12:36 PM, Oleg Pronin syber@gmail.com wrote:
 Can you hear the difference between 3mln/s and 24k/s ?

 I do not say that using hashes are good. But i'm sure that developers
 MUST NOT use super-slow frameworks like Moose-shit (which tries to
 emulate perl6 on perl5:   what for???) only to get good maintened
 code. That's the own problems of developers how do they organize
 internals. Why users of Catalyst must suffer from that ?  Or you wanna
 tell that good maintened code must have a price of 100x slow down
 ??? that an absurdity can't you see it?

Well - this is not that absurd as you seem to think - the meaning of
that  100x slow down depends much on where it happens.  If it
happens in a tight loop - then it can be harmful - if it happens on
some one-off operation then it mostly does not really matter.  It is
not that using Moose slows your application 100 times - it can slow
some parts of it - but how that relates to the overall performance -
this depends on many things.  I think that most of Catalyst users
found that it's port to the Moose framework did not slow their
applications much - but there sure there will be some cases that this
change was introducing some problems.  Unfortunately it's always about
tradeoffs.  But if you have a real-life example where the port caused
a 100 times slow down - then I am sure the developers here would like
to hear about the details.

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] How to de-serialize json?

2010-01-26 Thread Zbigniew Lukasiak
On Sun, Jan 24, 2010 at 8:01 AM, Bill Moseley mose...@hank.org wrote:


 On Sat, Jan 23, 2010 at 7:20 PM, Hans Dieter Pearcey
 hdp.perl.catalyst.us...@weftsoar.net wrote:

 As far as I can tell, you missed the point of my message, which makes me
 wonder
 if I've missed the point of yours.  Are you talking about a set of
 conventions
 you'd like to be able to build for your own use on top of HTTP::Body, or a
 set
 of conventions that you expect everyone will want and so should be built
 into
 HTTP::Body, or something else entirely?

 I thought you were saying that the request might not be a normal form
 posting, and I was saying only that HTTP::Body can support that, too.
 I was not suggesting everyone should use one method over another.
 HTTP::Body seems (to me) like the natural place to deserialize.  Yet, the
 REST modules I cited use an action class to deserialize.  Thus, I was
 wondering if there was a specific reasons for that approach that I had not
 understood.  That's really all.

I cannot claim to understand all the concerns here - but to add my two
cents: it sounds like this deserialisation thing is not something
specific to Catalyst and now with other frameworks and libraries
gaining grounds - it would make sense to put that logic into something
reusable across them.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Basic CRUD example failing

2009-10-27 Thread Zbigniew Lukasiak
On Wed, Oct 28, 2009 at 6:07 AM, Jason Dixon ja...@dixongroup.net wrote:
 Hi all,

 Learning Catalyst here.  Following along with the manual and I ran into
 a weird issue.  I assume the documentation is right so it must be
 something with my installation (Catalyst packages on OpenBSD 4.6).

 Following along with the SIMPLE DELETE FEATURE example, I made changes
 to root/src/books/list.tt2.  Alas, the uri is not rendering properly.

 a href=[% c.uri_for(c.controller.action_for('delete'), [book.id]) 
 %]Delete/a

I may have not updated my view knowledge - but I would write that as:
a href=[% c.uri_for(c.controller.action_for('delete'), book.id) %]Delete/a

Why did you use the square brackets around 'book.id'?

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] How to handle development vs production, required vs recommended module dependencies

2009-09-09 Thread Zbigniew Lukasiak
On Mon, Aug 31, 2009 at 3:44 AM, Daniel Austindaniel.aus...@gmail.com wrote:
 Hello

 I'm curious how other Catalyst developers are managing their CPAN
 module dependencies.

 I see our current application as having four types of module dependencies:

 * Modules that are required for the application to run *at all*. These
 are specified using requires statements in Makefile.PL (and also,
 the all from statement which points at the main Catalyst application
 class).

 * Modules that are not required, but if present, add additional
 functionality. These are specified using recommends statements in
 the Makefile.PL.

I am against additional functionalities and recommended
dependencies.   If this additional functionality is really useful -
then you can expect someone will write something depending on it and
at that point the whole automatic install idea breaks down.

See also: http://www.mail-archive.com/module-auth...@perl.org/msg07485.html

Cheers,

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] RFC: no make install on catalyst apps

2009-08-02 Thread Zbigniew Lukasiak
On Sun, Aug 2, 2009 at 1:32 PM, John Napiorkowskijjn1...@yahoo.com wrote:




 - Original Message 
 From: Tomas Doran bobtf...@bobtfish.net
 To: The elegant MVC web framework catalyst@lists.scsys.co.uk
 Sent: Tuesday, July 28, 2009 8:28:08 PM
 Subject: Re: [Catalyst] RFC: no make install on catalyst apps


 On 28 Jul 2009, at 14:14, Marcus Ramberg wrote:

  I see catalyst apps being complete CPAN packages as a real advantage.
  Taking away the make install option seems very limiting

 +1

 I would very much support moving to a 'real' sharedir for templates / config
 etc, rather than the current hacks (given appropriate back compat) however.

 Cheers
 t0m


 I am vaguely planning something roughly based on the XDG directory 
 specification:

 http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

 for localizing configs and related.  Something like this would make is much 
 easier to have multiply versions of the same catalyst application running.  
 Like, if I had MojoMojo installed and wanted to run two seperate wikis with 
 different configs.  You can do that now but requires playing with %ENV and 
 copying some configs around.

 In my mind the way this would work is that you'd have the config and other 
 share data stuff as templates inside your dist, and than at install time we'd 
 copy to all the correct places.  Then we'd merge configurations in the 
 following order.

 $cpan/config/myapp.conf
 $home/.config/myapp.conf
 /etc/myapp.conf

 Where $cpan is where cpan stuff is installed globally, $home is your home 
 directory.  Maybe we could move around the order a bit, but this way we'd set 
 all the 'no moving parts here' config in the $cpan (stuff like when the app 
 was installed, some paths).  Then whatever user started the app, we'd read 
 from her local configuration (we'd probably need some sort of 'first time' 
 script if it's not present, which would copy from a template and prompt for 
 required values) and last we'd merge in any globally set up stuff.

 Maybe with more people using local lib this is not as important, although I 
 see local lib most as a developer tool or as a workaround for people that are 
 on shared servers.

 That's just for config, but could work as well for search paths for templates

So config is supposed to move into a 'config' subdir  (and later be
merged with the configs in home and etc)?  Am I reading that right?
Maybe we could call it 'etc' instead of config?  And now templates -
can we also move them into a 'templates' subdir?


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OpenID authentication and LWPx-ParanoidAgent

2009-07-31 Thread Zbigniew Lukasiak
On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
 On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote:
 Brad just uploaded the module to CPAN.

 Unfortunately it still fails everywhere:
 http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06

I've analyzed the failure and posted a patch at:
https://rt.cpan.org/Ticket/Display.html?id=48345

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OpenID authentication and LWPx-ParanoidAgent

2009-07-21 Thread Zbigniew Lukasiak
Sorry - OK - so this was not the really the problem, my analysis below
was wrong.  But still the tests of
Catalyst-Authentication-Credential-OpenID fail and I would like
someone to confirm that.

z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
make test 2 errors
PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e
test_harness(0, 'inc', 'blib/lib', 'blib/arch') t/00.load.t
t/live_app.t t/pod-coverage.t t/pod.t
t/00.load.t ... ok
t/live_app.t .. Dubious, test returned 5 (wstat 1280, 0x500)
Failed 5/17 subtests
t/pod-coverage.t .. ok
t/pod.t ... ok

Test Summary Report
---
t/live_app.t(Wstat: 1280 Tests: 17 Failed: 5)
 Failed tests:  9-10, 12, 16-17
 Non-zero exit status: 5
Files=4, Tests=20, 10 wallclock secs ( 0.05 usr  0.01 sys +  4.03 cusr
 0.34 csys =  4.43 CPU)
Result: FAIL
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$

The errors file is not attached - because it is above the quota and
requires moderation - but I can send it to anyone off the list.

The relevant versions prereqs:

z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$
perl Makefile.PL
Cannot determine perl version info from
lib/Catalyst/Authentication/Credential/OpenID.pm
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
[Core Features]
- LWPx::ParanoidAgent...loaded. (1.06 = 1.03)
- Test::More ...loaded. (0.86 = 0.42)
- Net::OpenID::Server...loaded. (1.02 = 1.02)
- Test::WWW::Mechanize   ...loaded. (1.20 = 1.20)
- Net::DNS   ...loaded. (0.63)
- IO::Socket::INET   ...loaded. (1.31)
- parent ...loaded. (0.221 = 0.2)
- Class::Accessor::Fast  ...loaded. (0.33)
- HTML::Parser   ...loaded. (3.60 = 3)
- LWP::UserAgent ...loaded. (5.824)
- Cache::FastMmap...loaded. (1.30 = 1.28)
- Catalyst   ...loaded. (5.80007 = 5.7)
- Catalyst::Devel...loaded. (1.17 = 1)
- Crypt::DH  ...loaded. (0.06 = 0.05)
- Net::OpenID::Consumer  ...loaded. (1.03 = 1.03)
- Catalyst::Authentication::User::Hash   ...loaded. (0)
- Catalyst::Plugin::Session::Store::FastMmap ...loaded. (0.11 = 0.05)
- Catalyst::Plugin::Session::State::Cookie   ...loaded. (0.11 = 0.08)
- Catalyst::Engine::HTTP ...loaded. (0)
*** Module::AutoInstall configuration finished.
Writing Makefile for Catalyst::Authentication::Credential::OpenID
z...@zby:~/progs/tmp/Catalyst-Authentication-Credential-OpenID-0.13$

Cheers,
Zbigniew

On Mon, Jul 20, 2009 at 9:28 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
 Next thing is that LWPx::ParanoidAgent does not set attributes from
 the call to 'new'.  It is not documented there - so I guess this is
 fair from the side of LWPx::ParanoidAgent - but in line 62 in
 Catalyst::Authentication::Credential::OpenID there is:

 ua = $self-_config-{ua_class}-new(%{$self-_config-{ua_args} || {}}),

 so there is some misunderstanding between those two modules.

 But it would be nice if LWPx::ParanoidAgent did work like this.

 Cheers,
 Z.

 On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
 On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com 
 wrote:
 Brad just uploaded the module to CPAN.

 Unfortunately it still fails everywhere:
 http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06

 Here are my results:

 perl -Ilib t/00-all.t
 .
 .
 .
 Three 1-second redirect tarpits (tolerance 2)...
  2.008 secs
 ok 25
 ok 26
 ok 27
 5 second tarpit (tolerance 2)...
 not ok 28
 #   Failed test at t/00-all.t line 180.
 3 second tarpit (tolerance 4)...
 ok 29
 Killing child pid: 7392
 # Looks like you failed 1 test of 29.

 I hope you can get in touch with Brad again.  I understand that this
 is most probably just test error - and forcing the installation is not
 a problem for people who analyze it, but if I included this in other
 module - then the dependency would hide where the problem comes from.
 So I am still not ready to add OpenID to the CatalystX::SimpleLogin
 project.

 Cheers,
 Zbigniew
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/




 --
 Zbigniew Lukasiak
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OpenID authentication and LWPx-ParanoidAgent

2009-07-20 Thread Zbigniew Lukasiak
On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote:
 Brad just uploaded the module to CPAN.

Unfortunately it still fails everywhere:
http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06

Here are my results:

perl -Ilib t/00-all.t
.
.
.
Three 1-second redirect tarpits (tolerance 2)...
 2.008 secs
ok 25
ok 26
ok 27
5 second tarpit (tolerance 2)...
not ok 28
#   Failed test at t/00-all.t line 180.
3 second tarpit (tolerance 4)...
ok 29
Killing child pid: 7392
# Looks like you failed 1 test of 29.

I hope you can get in touch with Brad again.  I understand that this
is most probably just test error - and forcing the installation is not
a problem for people who analyze it, but if I included this in other
module - then the dependency would hide where the problem comes from.
So I am still not ready to add OpenID to the CatalystX::SimpleLogin
project.

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OpenID authentication and LWPx-ParanoidAgent

2009-07-20 Thread Zbigniew Lukasiak
Next thing is that LWPx::ParanoidAgent does not set attributes from
the call to 'new'.  It is not documented there - so I guess this is
fair from the side of LWPx::ParanoidAgent - but in line 62 in
Catalyst::Authentication::Credential::OpenID there is:

ua = $self-_config-{ua_class}-new(%{$self-_config-{ua_args} || {}}),

so there is some misunderstanding between those two modules.

But it would be nice if LWPx::ParanoidAgent did work like this.

Cheers,
Z.

On Mon, Jul 20, 2009 at 4:30 PM, Zbigniew Lukasiakzzb...@gmail.com wrote:
 On Sat, Jul 18, 2009 at 9:14 PM, Tatsuhiko Miyagawamiyag...@gmail.com wrote:
 Brad just uploaded the module to CPAN.

 Unfortunately it still fails everywhere:
 http://matrix.cpantesters.org/?dist=LWPx-ParanoidAgent+1.06

 Here are my results:

 perl -Ilib t/00-all.t
 .
 .
 .
 Three 1-second redirect tarpits (tolerance 2)...
  2.008 secs
 ok 25
 ok 26
 ok 27
 5 second tarpit (tolerance 2)...
 not ok 28
 #   Failed test at t/00-all.t line 180.
 3 second tarpit (tolerance 4)...
 ok 29
 Killing child pid: 7392
 # Looks like you failed 1 test of 29.

 I hope you can get in touch with Brad again.  I understand that this
 is most probably just test error - and forcing the installation is not
 a problem for people who analyze it, but if I included this in other
 module - then the dependency would hide where the problem comes from.
 So I am still not ready to add OpenID to the CatalystX::SimpleLogin
 project.

 Cheers,
 Zbigniew
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] What do you guys use for sanitizing HTML input

2009-07-19 Thread Zbigniew Lukasiak
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

2009-07-18 Thread Zbigniew Lukasiak
On Sat, Jul 18, 2009 at 2:27 AM, Tatsuhiko Miyagawamiyag...@gmail.com wrote:
 I actually applied the same patch against its SVN repository a few
 weeks ago. I'll poke Brad to make a new release on CPAN.
 http://code.sixapart.com/svn/LWPx-ParanoidAgent/trunk/

Thanks - that's great!

While we are at it - it seems that there is also problem with the
Crypt::DH package (which is another dependency)- this is nicely
explained in DESCRIPTION in
http://search.cpan.org/dist/Crypt-DH-GMP/lib/Crypt/DH/GMP.pm and it
seems like a reasonable replacement.



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] OpenID authentication and LWPx-ParanoidAgent

2009-07-17 Thread Zbigniew Lukasiak
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?)

2009-07-12 Thread Zbigniew Lukasiak
On Sun, Jul 12, 2009 at 1:43 AM, Tomas Doranbobtf...@bobtfish.net wrote:
 Having spoken to the the author of the above mentioned module, I've gone
 ahead and converted it to an ActionRole:

 http://github.com/bobtfish/catalyst-actionrole-acl/tree/master

I just had a look there:

   sub foo
 :Local
 :Does(ACL)
 :RequiresRole(admin)
 :ACLDetachTo(denied)


Nice - I hope this formatting becomes a standard.  Stacking of more
and more attrs on the same line was driving me crazy - I did not know
that you can put a newline there.

By the way - theoretically all this could be equivalently coded as
something like:

package MyController;
use 
with ACL;

sub foo : Local {
  ($self, $c, @args ) = @_;
  $self-check_acl_role( 'admin', 'denied' );


It seems that people prefer the attributes - I guess because they are
more declarative.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] How to do pass-through login?

2009-07-09 Thread Zbigniew Lukasiak
On Thu, Jul 9, 2009 at 11:03 AM, Gunnar Strandgunnarstr...@yahoo.com wrote:

 Hi,

 I am looking for a way to send users to the login screen if they are
 trying to access a restricted path, and if the login is valid, the
 original request should just continue like this:

 1. myapp - GET /member/only
 2. myapp - /login_form
 3. myapp - POST /login
 4. myapp - /member/only

 I guess this is what is called pass-through login (and other actions)
 in the Cookbook, but I can't understand the description:

 Provide actions for these, but when they're required for something else
 fill e.g. a form variable __login and have a sub begin like so:

    sub begin : Private {
      my ($self, $c) = @_;
      foreach my $action (qw/login docommand foo bar whatever/) {
        if ($c-req-params-{__${action}}) {
          $c-forward($action);
        }
      }
    }


 Where is the data from the original request stored? Is everything stored
 in the __$action key including any values in a form submission?

 An example on how pass-through works would be very helpful.

 I would have expected something like this (pseudo-code):

 In begin for /member/only:
 unless ( $c - user_exists() ) {
  $c - delay_action();       # Saves state in Flash or Session
  $c - forward('/login_form');
 }

 In login after authentication:
 if ( $c - restore_action() ) {
  $c - continue_action();
 }

There is Catalyst::Helper::Auth that generates such a passthrough
login component, but it is rather buggy.  You can have a look at mine
ProtoWiki code at:
http://github.com/zby/CatalystX--ProtoWiki/blob/237284a35f5fd65e3d32cb5f88b81c28a47250e9/lib/CatalystX/ProtoWiki/Controller/Auth.pm
- it is copied from the code generated by Catalyst::Helper::Auth - and
then a bit modified/fixed, but it still needs a lot of work. It
redirects to an 'url' not action - so in theory it should retain
parameters etc. - but I am not sure if they are correctly encoded now.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Themes, skins, templates and componentized UI?

2009-07-07 Thread Zbigniew Lukasiak
On Mon, Jul 6, 2009 at 9:55 PM, Gunnar Strandgunnarstr...@yahoo.com wrote:

 Hi,

 I am a little new in the web design area. I'm trying to design an
 application where the view part must be simple to replace by whomever
 installs it, with elements of their own design. This would work
 comparable to themes or skins. I've done some googling, but I
 haven't got any obvious hits on this. The closest I _think_ is
 CatalystX::Usul, but I haven't really understood if that's what I'm
 looking for :-)

 Also, I would also want the person installing the application to be able
 to restructure the visual parts using components, where a component
 could for instance be a result ticker, main menu, member table or
 such. Perhaps in the way that Joomla does, but the components will be
 application specific. It's much a matter of deciding what components are
 present in which views and where.

 I imagine, for instance, a collection of widgets (button,
 drop-down-list, text field etc) which are reused in the TT templates. A
 component would then use these widgets as building blocks, populating
 them using data from the stash. A view (webpage) would be a template
 including one or more of these components. A theme could then override
 any widgets of choice to change the look-and-feel of the whole
 application instantly.

 Am I approaching this from the right direction and does anyone know if
 there exists a framework similar to this to use with Catalyst?

 Or should I perhaps go barking up the TT tree? ;-)

I am working on CatalystX::Elements with the first one being Comments
- I am not sure if it goes in the same direction - but it seems close.
  The main goal is providing Catalyst feature addons - that could be
used as kind of scaffolding - that is they should be easy to assemble,
implying they are rather simplistic, and later easy to be gradually
replaced.  For now I am not dealing with templates at all - the
Comments element lets you to stash a form which knows how to render
itself into HTML and can be inserted somewhere in the templates.
I've posted about it at my blog:
http://perlalchemy.blogspot.com/2009/06/catalystxcomments-rfc.html
(also have a look at the comment).  There is some code for it at:
http://github.com/gshank/ravlog/tree/8b7ec1493324212cde91927c15fc54cd2c9db25d/lib/CatalystX
(but now I've decided to change the name and add Elements - a play on
the chemical metaphor of Catalyst).


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] FormFu vs. FormBuilder ...

2009-06-10 Thread Zbigniew Lukasiak
On Wed, Jun 10, 2009 at 9:00 AM, Kiffin Gishkiffin.g...@planet.nl wrote:
 What are the advantages/disadvantages for choosing between
 Catalyst::Controller::FormBuilder and Catalyst::Controller::HTML:FormFu?

Those two are not the only options.  Have a look at:
http://www.perlfoundation.org/perl5/index.cgi?form_processing

In my opinion the Catalyst controllers don't server any purpose other
than documenting how to configure a form processor for Catalyst.  This
should not require a separate module - as this additional layer only
adds friction (problems like exposing not exactly full API of the
original processor, lagging after new releases of the processor and
Catalyst etc.) - but I agree that this kind of configuration should be
put somewhere and should be accompanied by tests.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Best practice: How to build app parts reusable?

2009-06-02 Thread Zbigniew Lukasiak
On Sun, May 31, 2009 at 6:06 PM, Matthias Dietrich mdietr...@cpan.org wrote:
 Hi,

 in one of my Catalyst apps I'm building application parts that I want to
 reuse in other Catalyst apps where possible.  What's the best practice to do
 that?  I mean the complete parts from controller, to model, DBIC schema
 classes and templates.

 Let's assume one part is a guestbook (no, it's not but it's a funny example
 ;)).  The integration of the controller class is very easy.  I just would
 build a new controller inside the app which uses the guestbook controller as
 base class and sets the correct namespace, where the guestbook should
 appear.  A similar procedure would get me the model and schemes into my app,
 but it requires a wrapper class for each class the guestbook brings with.
  And the templates?  The only way I know of is to copy and paste them into
 the 'root' folder of the app.

Just one idea - in the TT view there is a
http://search.cpan.org/~mramberg/Catalyst-View-TT-0.29/lib/Catalyst/View/TT.pm#DYNAMIC_INCLUDE_PATH
option.  I have never eventually used that - but when I was adding it
what I had in mind was something like template inheritance.  By
splitting the templates into separate files you can use it to override
those individual templates just like you can override methods in a
class.  The difference is that a class is a file and method is a part
of that file - here the the corresponding things are a directory and
an individual template.


 There has to be a better way.  But which?

 I'm also thinking about whole reusable applications.  For example a shopping
 system which can be extended and modified by overwriting methods while the
 base system can be upgraded seamlessly.  (I know MojoMojo as a standalone
 Catalyst app, but it's only standalone and not to be extended locally.)

There is Handel - I have never explored it but I think the design goal
was to make it extendable.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] More natural access to model?

2009-05-12 Thread Zbigniew Lukasiak
2009/5/12 Paweł Tęcza pte...@uw.edu.pl:
 Dear Catalyst users,

 It's my first post here, so I would like to say Hello to all of us! :)

 I'm writing my first Catalyst application for student registration and I
 have the following tables for details about studies at our university:

 CREATE TABLE studies (
    id integer NOT NULL,
    unit_id integer,
    status integer,
    limit_soft integer,
    limit_hard integer
 );

 'id' column is a database study identifier. It's also primary key for
 that table. 'unit_id' is an unit identifier of study, 'status' column
 says whether registration is open/suspended/closed, 'limit_soft' and
 'limit_hard' are for student number limits.

 CREATE TABLE study_data (
    study_id integer NOT NULL,
    lang lang NOT NULL,
    name text NOT NULL,
    value text
 );

 'study_id' column is database study identifier (please look at
 studies.id column), 'lang' column points language for (name, value)
 pair, for example 'pl', 'en', etc. 'name' column is for name of data,
 for example 'name', 'description', 'program', 'email', etc.
 ('study_id', 'lang', 'name') is a primary key for that table. Finally
 'value' column is for data content.

 I think it's very simple structure and fully understandable for you,
 so it doesn't need more comments. Of course, I can also define
 table 'study_data' with many columns, for example 'name', 'description',
 'program', 'email', etc. but I think that its simpler structure is
 better idea here, because it's more flexible. I can add new type of
 data, without changing table definition.

 Unfortunately, when I want to get the study details, then I need to use
 the code like below:

 my $study_name        = '';
 my $study_description = '';
 my $study_program     = '';
 my $study_email       = '';

 my @studies = $c-model('DB::Studies')-all;
 foreach my $study in (@studies) {
    my $name  = $study.study_datas.name;
    my $value = $study.study_datas.value;

    $study_name        = $value if ($name eq 'name');
    $study_description = $value if ($name eq 'description');
    $study_program     = $value if ($name eq 'program');
    $study_email       = $value if ($name eq 'email');
 }

 I hope you agree with me that it's not handy way...

 So my question is: how can I modify my model to get the study details
 in the following, more natural way?  Is it possibble at all?

 my @studies = $c-model('DB::Studies')-all;
 foreach my $study in (@studies) {
    $study_name        = $study.study_datas.name        || '';
    $study_description = $study.study_datas.description || '';
    $study_program     = $study.study_datas.program     || '';
    $study_email       = $study.study_datas.email       || '';
 }


Hmm - there is something missing there - according to your description
above $study.study_datas.program can not identify one value - but
rather an array of values (one for each language) isn't that true?

You might also want to change the '.' to '-'.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] The Netiquette thread (OT)

2009-04-28 Thread Zbigniew Lukasiak
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

2009-04-23 Thread Zbigniew Lukasiak
On Thu, Apr 23, 2009 at 11:03 PM, John Napiorkowski jjn1...@yahoo.com wrote:
 Thanks these are great additions.  I modified the wiki page with these and a 
 few other tweaks I got from reviewing several other press releases

 Lastest at: 
 http://dev.catalystframework.org/wiki/releaseannouncements/58pressrelease

... the revolutionary Moose Object system, the most advanced Object
Oriented framework for any major scripting language

I would change that to 'one of the most advanced' - less flame
igniting (and by the way Perl 6 probably does have a more advanced
Object system).


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Google summer of code proposal

2009-04-02 Thread Zbigniew Lukasiak
2009/4/2 Octavian Râsnita orasn...@gmail.com:
 From: Devin Austin

 My proposal is to refactor for the Catalyst web framework's helpers to
 make them more extensible.  Helpers date from the early days of the
 framework, but have lagged far behind in development compared to other
 aspects of Catalyst.  Current solutions are hackish, brittle, and
 inconsistent.  The goal of this project is to clean up the previous
 “API”, solidify it with tests and documentation, and then expand it to
 add features that will give them more usefulness than just “generating
 scaffolding” code.  That is, to make Catalyst helpers more useful for
 everyone rather than just beginning developers.
 Congratulations for the idea. What I think it could be helpful for having in
 the Catalyst helpers that need to use very many parameters, is the
 possibility of specifying a configuration file that contains all the needed
 parameters.
 This way it would be more simple to re-use the helper for the next time,
 without worrying that we might forget some parameters.

 For example, instead of:

 $ perl scripts/myapp_create.pl model DB DBIC::Schema MyApp::Database
 create=static components=Digest::Columns dbi:mysql:database=test user pass

 we could use:

 $ perl scripts/myapp_create.pl @db.txt

 and the file db.txt could contain:

 type=model
 name=DB
 params=DBIC::Schema MyApp::Database create=static components=Digest::Columns
 dbi:mysql:database=test user pass

I concur - and to make it perfect it should be able to generate many
components at once and not use scripts/myapp_create.pl but the
original catalyst.pl - so the whole app could be generated in one
step.  Now I need to do ugly hacks with Find::Bin to do that in
InstantCRUD.

Two more ideas (that I've already posted to the other mailing list:

1) Helpers now are completely separated - each one generates it's own
part of the application, but does not change anything else.  It would
be useful at least to be able to add the configuration to the main
application config file instead of adding config to the generated
classes (case in point Catalyst::View::TT).


2) Module::Starter - maybe we could refactor at least part of the
helper stuff as Module::Starter plugins - and have the benefit of
using something generic?


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] LEFT JOIN with AND statement

2009-03-17 Thread Zbigniew Lukasiak
On Tue, Mar 17, 2009 at 9:55 PM, Jakub Tutaj j...@wp.pl wrote:

 Hello!

 I'd like to prepare query like:
 SELECT group_tasks.*,student_tasks.*
 FROM group_tasks
 LEFT JOIN student_tasks
 ON group_tasks.id = student_tasks.group_task_id AND student_tasks.user_id =
 1
 WHERE group_tasks.group_id = 1

 I stuck at this point:

 $c-stash-{studentgrouptasks} = [$c-model('sapsDB::GroupTasks')-search(
    {
        'me.group_id' = 1,
    },
    {
        join = [qw/ studenttasks/]
    }
 )];

 I don't know where can I put 'AND student_tasks.user_id = 1' so it's
 corresponding with 'join'. I'd like to have list of all grouptasks designed
 for the student and if student already did the task (there's a studenttask
 record in DB) I also want info about it. That's why I need this 'AND' in
 JOIN .. ON statement, instead of normal JOIN .. ON .. WHERE clause. Any
 help?

 My tables are something like this:

 GroupTasks:
 id
 status
 task_id
 group_id

 StudentTasks:
 id
 status
 group_task_id
 user_id

 has_many and belongs_to :

 saps::Schema::GroupTasks-has_many(studenttasks =
 'saps::Schema::StudentTasks', 'group_task_id');
 saps::Schema::StudentTasks-belongs_to(grouptask =
 'saps::Schema::GroupTasks', 'group_task_id');

 Another question is, if I have proper query, how to distinct
 studenttasks.status and grouptasks.status using stashed 'studentgrouptasks'
 variable in TT (using FOREACH etc.)?

This is really not about Catalyst but rather about DBIC - so you might
want to redirect this question to the appriopriate list, but answering
your question I think the only way to do it is via a custom ResultSet
(http://search.cpan.org/~ribasushi/DBIx-Class-0.08099_07/lib/DBIx/Class/Manual/Cookbook.pod#Arbitrary_SQL_through_a_custom_ResultSource)
or using the from attribute
(http://search.cpan.org/~ribasushi/DBIx-Class-0.08012/lib/DBIx/Class/ResultSet.pm#from
- note the 'Use this on your own risk' warning).

Pozdr.
Zbyszek
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] In search of RESTful CRUD holy grail

2009-03-04 Thread Zbigniew Lukasiak
This might be a futile mission - but I think I learn something with
each recurrence of this discussion.  So let's restart it once again.

CatalystX::CRUD::REST has a well described RESTful URI structure:

# POST  /foo- create new record
# GET   /foo- list all records
# PUT   /foo/pk   - update record
# DELETE/foo/pk   - delete record
# GET  /foo/pk   - view record
# GET  /foo/pk/edit_form - edit record form
# GET  /foo/create_form- create record form

I think everyone will agree that this is indeed REST.  For some cases
there might be a slight problem with that URI schema - if you have a
string primary key - and it can have the value of 'create_form' - then
you will not know if the client is requesting a view on the object
with that id or if he wants the page with the form to create a new
object.

This leads to new variation:

# POST  /foo- create new record
# GET   /foo- list all records
# PUT   /foo/by_id/pk   - update record
# DELETE/foo/by_id/pk   - delete record
# GET  /foo/by_id/pk   - view record
# GET  /foo/by_id/pk/edit_form - edit record form
# GET  /foo/create_form- create record form

Of course 'by_id' could be 'instance' or whatever (perhaps the library
should let the user to choose that infix part).

Now   '/foo/by_id/pk/edit_form' needs to make a PUT request to
/foo/by_id/pk.   To get around the problem with requests outside of
the basic 'GET' and 'POST' repertoir we can use
Catalyst::Request::REST::ForBrowsers.   But it also means that for
browser requests in the case of mistakes made in the form the action
answering that PUT request to '/foo/by_id/pk' needs to render the
form again with error indicators. But for non browser requests in case
of similar errors it needs to encode those errors in some other way.
This shows that 'edit_form' is only informing us how to *render* (or
serialize) the data. In the case of GET requests it informs us that we
should render the object data inside of a form and in the case of a
PUT request with errors it informs us that we should similarly put the
error data into the form.  This leads to next variation:


# PUT   /foo/by_id/pk  - update record
or return the error encoded for non-browsers
# PUT   /foo/by_id/pk/edit_form  - update record  or
return the error encoded as HTML form
# DELETE/foo/by_id/pk  - delete record
# GET  /foo/by_id/pk  - view record
(for non-browsers encoded)
# GET  /foo/by_id/pk/edit_form  - view record encoded
as an edit form

And similarly:

# POST  /foo - create new record
# POST  /foo/create_form - create record form
# GET   /foo  - list all records
# GET  /foo/create_form   - create record form

i.e. - here we treat 'edit_form' and 'create_form' consistently as a
path info parameter informing us about the serialization method.   The
advantage of this arrangement is also that we don't need to put any
address into the 'action' parameter of the form - and let it always
submit to itself.  In another variation we could move that parameter
from path info to real parameters and have uris like:

# PUT   /foo/by_id/pk-
update record  or return the error encoded
# PUT   /foo/by_id/pk?x-view=edit_form   - update
record  or return the error encoded as HTML form
# DELETE/foo/by_id/pk- delete record
# GET  /foo/by_id/pk -
view record (encoded)
# GET  /foo/by_id/pk?x-view=edit_form- view record
encoded as an edit form


Finally we need serialisation and dispatching to different methods for
the same address (/foo/by_id/) based on the method.  This is covered
by Catalyst::Controller::REST.   What I have not yet explored is how
to add this new serialisation method (to 'edit_form') to the
configuration of a Catalyst::Controller::REST based controller.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OT: edit/add seperate actions?

2009-03-03 Thread Zbigniew Lukasiak
On Tue, Mar 3, 2009 at 7:33 PM, Peter Karman pe...@peknet.com wrote:
 Iain wrote on 03/03/2009 09:33 AM:
 Hello all,

 So we are having a discussion @work about basic add/edit functions. We
 currently have currently two lines of thoughts on handling it.

 1. Have separate actions for adding and editing e.g.

 # add
 /app/notice/add_new (POST To) /app/notice/process_add_new

 # edit
 /app/notice/*/edit (POST To) /app/notice/*/process_edit

 2. Have a shared edit action with an if ( $c-req-method eq 'POST' )
 check.

 # edit
 /app/notice/*/edit (POST Back to) /app/notice/*/edit

 There currently doesn't look like much difference in lines of code to
 manage.

 Just wondering if anybody has any thoughts/experience, pros/cons best
 practice etc of either approach.


 CatalystX::CRUD::Controller does:

  /app/notice/create   # redirect internally to 0/edit
  /app/notice/*/edit   # POST to /app/notice/*/save

 The '0' placeholder indicates it is a new object. '0' has the nice
 effect of evaluating true for defined() and length() but false
 otherwise. OTOH, it means you can't have a valid OID that == 0.

 If you use CatalystX::CRUD::REST, you can do:

    # POST      /foo                - create new record
    # GET       /foo                - list all records
    # PUT       /foo/pk           - update record
    # DELETE    /foo/pk           - delete record
    # GET       /foo/pk           - view record
    # GET       /foo/pk/edit_form - edit record form
    # GET       /foo/create_form    - create record form

 CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of
 'x-tunneled-method' param to support PUT and DELETE via POST.

And where do the forms submit?  I mean what is their action address?
Do they submit to themselves - or does edit_form submit to
/foo/pk?x-tunneled-method=PUT and create to /foo both with POST
method?  And it is the second - then what do you do when the form
parameters are incorrect and you need to redisplay the form?

--
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OT: edit/add seperate actions?

2009-03-03 Thread Zbigniew Lukasiak
On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman pe...@peknet.com wrote:
 Zbigniew Lukasiak wrote on 03/03/2009 02:53 PM:

 If you use CatalystX::CRUD::REST, you can do:

    # POST      /foo                - create new record
    # GET       /foo                - list all records
    # PUT       /foo/pk           - update record
    # DELETE    /foo/pk           - delete record
    # GET       /foo/pk           - view record
    # GET       /foo/pk/edit_form - edit record form
    # GET       /foo/create_form    - create record form

 CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of
 'x-tunneled-method' param to support PUT and DELETE via POST.

 And where do the forms submit?  I mean what is their action address?
 Do they submit to themselves - or does edit_form submit to
 /foo/pk?x-tunneled-method=PUT and create to /foo both with POST
 method?  And it is the second - then what do you do when the form
 parameters are incorrect and you need to redisplay the form?

 using the CXC REST API:

 if you GET /foo/1234, then you must PUT /foo/1234 to save it.
 (or POST /foo/1234?x-tunneled-method=PUT  -- although I always put the
 x-tunneled-method value in a hidden input body param, not as part of the
 URL).
Sure - that was just for clarification of how the PUT is done with browsers :)



 if you GET /foo/create_form, then you must POST /foo.

 When the form is redisplayed on validation error, it just retains the
 original action.

I was just thinking about the possible CRUD REST schemas and it found
that under that schema you display the same form under two addresses:
/foo/1234/edit_form and /foo/1234 (in case of the error).  And the
other day I had that idea that perhaps instead of using path part -
use another parameter so /foo/1234?x-view-method=edit_form  would
render the form and /foo/1234 would render the standard view of the
object.   This way the form would have just one address.

Both things are just different representations of the same thing - so
using a parameter to differentiate between them seems quite logical.
But on the other hand it might look too different from the traditional
ways.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OT: edit/add seperate actions?

2009-03-03 Thread Zbigniew Lukasiak
On Tue, Mar 3, 2009 at 11:35 PM, Peter Karman pe...@peknet.com wrote:
 Zbigniew Lukasiak wrote on 03/03/2009 04:18 PM:
 - Show quoted text -
 On Tue, Mar 3, 2009 at 10:27 PM, Peter Karman pe...@peknet.com wrote:
 Zbigniew Lukasiak wrote on 03/03/2009 02:53 PM:

 If you use CatalystX::CRUD::REST, you can do:

    # POST      /foo                - create new record
    # GET       /foo                - list all records
    # PUT       /foo/pk           - update record
    # DELETE    /foo/pk           - delete record
    # GET       /foo/pk           - view record
    # GET       /foo/pk/edit_form - edit record form
    # GET       /foo/create_form    - create record form

 CatalystX::CRUD::REST uses the C::R::REST::ForBrowsers feature of
 'x-tunneled-method' param to support PUT and DELETE via POST.
 And where do the forms submit?  I mean what is their action address?
 Do they submit to themselves - or does edit_form submit to
 /foo/pk?x-tunneled-method=PUT and create to /foo both with POST
 method?  And it is the second - then what do you do when the form
 parameters are incorrect and you need to redisplay the form?
 using the CXC REST API:

 if you GET /foo/1234, then you must PUT /foo/1234 to save it.
 (or POST /foo/1234?x-tunneled-method=PUT  -- although I always put the
 x-tunneled-method value in a hidden input body param, not as part of the
 URL).
 Sure - that was just for clarification of how the PUT is done with browsers 
 :)


 if you GET /foo/create_form, then you must POST /foo.

 When the form is redisplayed on validation error, it just retains the
 original action.

 I was just thinking about the possible CRUD REST schemas and it found
 that under that schema you display the same form under two addresses:
 /foo/1234/edit_form and /foo/1234 (in case of the error).  And the
 other day I had that idea that perhaps instead of using path part -
 use another parameter so /foo/1234?x-view-method=edit_form  would
 render the form and /foo/1234 would render the standard view of the
 object.   This way the form would have just one address.


 In CXC REST, /foo/1234 is analogous to /foo/1234/view in the RPC format.
 It does not return a HTML form. It just returns the object data. I.e.,
 read-only. So the URLs represent two different things.

But they do represent two views on the same object - one is as you say
'read-only' the other is the form filled with it's values.  The same
object - two different renderings.  That is what I meant.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: OT: Better TT pager?

2009-02-28 Thread Zbigniew Lukasiak
On Thu, Jan 22, 2009 at 4:48 PM, Oliver Charles
oliver.g.char...@googlemail.com wrote:
 I might as well join in with this :) Here's what we use at work:

 [% IF pager %]
    ul class=paginator
        li class=counterPage [% pager.current_page %] of [%
 pager.last_page %]/li
        lia href=[% c.req.uri_with( page = pager.first_page )
 %]laquo;/a/li
        [% IF pager.previous_page %]
            lia href=[% c.req.uri_with( page =
 pager.previous_page ) %]lt;/a/li
        [% END %]

        [% start = (pager.current_page - 3)  0 ? (pager.current_page - 3) : 1;
         FOREACH page IN [ start .. pager.last_page ] %]
            [% LAST IF loop.count  6 %]
            li[% IF pager.current_page == page; ' class=current'; END %]
                a href=[% c.req.uri_with( page = page ) %][% page %]/a
            /li
        [% END %]

        [% IF pager.next_page %]
            lia href=[% c.req.uri_with( page = pager.next_page )
 %]gt;/a/li
        [% END %]
        lia href=[% c.req.uri_with( page = pager.last_page )
 %]raquo;/a/li
    /ul
 [% END %]

 Though my colleague rightly suggested we subclass Data::Page and
 perform the sliding window in there. This shows first page, previous
 page, the current page surrounded by near-by pages. Seems to do the
 job so far!

Hi,

I've just adopted your example and replaced my pager in InstantCRUD.
I added credit note like that:

=head1 AUTHOR

Zbigniew Lukasiak  C zz bb yy @ gmail.com 
Pager adapted from example by Oliver Charles.


I hope you are satisfied.

Cheers,
Zbigniew

PS. Here is the adopted version:

[% IF pager %]
div class=pager
div class=counter
Page [% pager.current_page %] of [% pager.last_page %]
/div
div
   [% IF pager.previous_page %]
   spana href=[% c.req.uri_with( page = pager.first_page
) %]laquo;/a/span
   spana href=[% c.req.uri_with( page =
pager.previous_page ) %]lt;/a/span
   [% END %]

   [% start = (pager.current_page - 3)  0 ? (pager.current_page - 3) : 1;
FOREACH page IN [ start .. pager.last_page ] %]
   [% LAST IF loop.count  6 %]
   [% IF pager.current_page == page %]
   span class=current [% page %] /span
   [% ELSE %]
   span a href=[% c.req.uri_with( page = page )
%][% page %]/a /span
   [% END %]
   [% END %]

   [% IF pager.next_page %]
   spana href=[% c.req.uri_with( page = pager.next_page )
%]gt;/a/span
   spana href=[% c.req.uri_with( page = pager.last_page )
%]raquo;/a/span
   [% END %]
   /div
/div
[% END %]

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] CatalystX

2009-02-27 Thread Zbigniew Lukasiak
On Fri, Feb 27, 2009 at 12:35 PM, Dermot paik...@googlemail.com wrote:
 Hi,

 I saw a demo of CatX::ListFramework-builder yesterday and I was very 
 impressed.

 I'd like to be able to give admin users of a wee app access to
 something similar. The idea is just to give them and me a means of
 looking at the schema.

 There are a lot of CatX modules at cpan. Is ListFramwork-builder
 recommanded or are there other modules that are more stable?

ListFramework is focused on the task of providing such an admin
interface - so I guess out of the many other Catalyst CRUD frameworks
it must really excel at that.  But if you were looking rather for a
scaffolding (i.e. something that builds a *template* CRUD application
- which you can later modify to adjust to your needs) - then you could
have a look at mine Catalyst::Example::InstantCRUD that I've just
released in the 0.0.29 version (the new thing in this version is
handling text semantic and UTF-8 in output).

In general the authoritative page on Catalyst CRUDs is:
http://dev.catalystframework.org/wiki/crud

Cheers,
Zbigniew

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: (OT) Navigation parameters in session

2009-02-26 Thread Zbigniew Lukasiak
On Fri, Feb 27, 2009 at 4:11 AM, Aristotle Pagaltzis pagalt...@gmx.de wrote:
 Users will not be e able to use the back button, and they will
 not be able to work in multiple tabs. You will not be able to
 load-balance as effectively as you could without sessions. A lot
 of your content will be hidden from search engines. I could think
 of more, but that should be enough for a start.


Thanks for you all for the arguments.  The crazy thing is that they
believe that with some
Javascript magic we'll be able to manage the multiple tabs and back
button problem.

 If you need an argument from authority, ask why none of the
 biggest sites like Google, Amayon, etc do it that way.


:) - this has potential.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: decoding in core

2009-02-23 Thread Zbigniew Lukasiak
On Fri, Feb 20, 2009 at 6:57 PM, Jonathan Rockway j...@jrock.us wrote:

 Braindump follows.

snip
snip


 One last thing, if this becomes core, it will definitely break people's
 apps.  Many, many apps are blissfully unaware of characters and treat
 text as binary... and their apps kind-of appear to work.  As soon as
 they get some real characters in their app, though, they will have
 double-encoded nonsense all over the place, and will blame you for this.
 (I loaded Catalyst::Plugin::Unicode, and my app broke!  It's all your
 fault.  Yup, people mail that to me privately all the time.  For some
 reason, they think I am going to personally fix their app, despite
 having written volumes of documentation about this.  Wrong.)


Some more things to consider.

- 'use utf8' in the code generated by the helpers?

- ENCODING: UTF-8 for the TT view helper?

Maybe a global config option to choose the byte or character semantics?

But with the DB it becomes a bit more complex - because BLOB columns
probably need to use byte sematic.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: decoding in core

2009-02-23 Thread Zbigniew Lukasiak
On Mon, Feb 23, 2009 at 2:58 PM, Neo [GC] n...@gothic-chat.de wrote:
 Zbigniew Lukasiak schrieb:

 Some more things to consider.

 - 'use utf8' in the code generated by the helpers?


 Reasonable, but only if documentet. It took weeks for us until we learned,
 that this changes _nothing_ but the behaviour of several perl-functions like
 regexp, sort aso.

Hmm - in my understanding it only changes literals in the code ( $var
= 'ą' ).  So I looked into the pod and it says:

Bytes in the source text that have their high-bit set will be
treated as being part of a literal
UTF-8 character.  This includes most literals such as identifier
names, string constants, and con-
stant regular expression patterns.


 - ENCODING: UTF-8 for the TT view helper?

 Maybe a global config option to choose the byte or character semantics?

 But with the DB it becomes a bit more complex - because BLOB columns
 probably need to use byte sematic.


 Uhm, of course, as BLOB is Binary and CLOB is Character. ;) This is even
 more complex, as the databases have different treating for this datatypes
 and some of Perls DBI-drivers are somewhat broken when it goes to unicode
 (according to our perl-saves-our-souls-guru).
 UTF-8 is ok in Perl itself (not easy, not coherent, but ok); but in
 combination of many modules (and as far as I learned, Perl is all about
 reusing modules) it is _hell_. Try to read UTF-8 from HTTP-request, store in
 database, select with correct order, write to XLS, convert to CSV, reimport
 it into the DB and output it to the browser, all with different subs in the
 same controller... and you know, what I mean.
 Even our most euphoric Perl-gurus don't have any clue how to handle UTF-8
 from the beginning to the end without hour-long trialerror in their
 programs (and remember - we Germans do only have those bloody Umlauts - try
 to imagine this in China _).

 Maybe the best thing for all average-and-below users would be a _really_
 good tutorial about Catalyst+UTF-8. What to do, what not to do. How to read
 UTF-8 from HTTP-request / uploaded file / local file / database, how to
 write it to client / downloadable file / local file / database. What
 catalystish variable is UTF-8-encoded when and why. How to determine what
 encoding a given scalar has and how to encode/decode/whatevercode it to a
 bloody nice scalar with shiny UTF-8 chars in it.
 Short: -- Umlauts with Catalyst for dummies --


Hmm - maybe I'll add UTF-8 handling in InstantCRUD.  I am waiting for
good sentences showing off the national characters.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] New version of InstantCRUD

2009-02-18 Thread Zbigniew Lukasiak
Just one more thought on collaboration in general: let's find some
elements in each other work that we would like to collaborate on,
let's not strive to steer the other project in full into the direction
of our wishes.  Let's divide the projects so that later each of us
will be able to assemble his own ideal solution out of it.

Zbigniew

On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier
alexander.hartma...@t-systems.at wrote:
 Would be great if we could combine our efforts instead of creating even
 more choices for the users of cat in form of InstantCRUD,
 Controller::DBIC::API and so on
 (http://dev.catalyst.perl.org/wiki/crud).

 - Alex aka abraxxa


 Am Montag, den 16.02.2009, 21:44 +0100 schrieb Zbigniew Lukasiak:
 Looks like we are again discussing CRUD in Catalyst - so I decided to
 finally update InstantCRUD and release it to CPAN.

 It is still experimental.

 It is a 'scaffolding' - like the Rails one - it generates a CRUD
 application for a given dsn.

 Some more random thoughs:
 http://dev.catalystframework.org/wiki/crud/instantcrud and
 http://dev.catalystframework.org/wiki/crud/crud_and_rest (one caveat I
 completely disagree with the  Preliminary URI naming guidelines).


 --
 Zbigniew Lukasiak
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/


 ***
 T-Systems Austria GesmbH   Rennweg 97-99, 1030 Wien
 Handelsgericht Wien, FN 79340b
 ***
 Notice: This e-mail contains information that is confidential and may be 
 privileged.
 If you are not the intended recipient, please notify the sender and then
 delete this e-mail immediately.
 ***

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] New version of InstantCRUD

2009-02-17 Thread Zbigniew Lukasiak
On Tue, Feb 17, 2009 at 7:48 PM, Alexander Hartmaier
alexander.hartma...@t-systems.at wrote:
 Would be great if we could combine our efforts instead of creating even
 more choices for the users of cat in form of InstantCRUD,
 Controller::DBIC::API and so on
 (http://dev.catalyst.perl.org/wiki/crud).

Sure.  Let me only point out that InstantCRUD was one of the first
(published just after Enzyme).  But this idea of combining efforts is
what lead me when starting that wiki page.  I am open for
collaboration, I've already started figuring out what can be done with
Peter Karman (of CatalystX::CRUD).  For me his approach is a bit too
heavy - it requires too much knowledge of his libraries to extend the
controller using it - it wraps the model into it's own abstractions
(CatalystX::CRUD::Iterator, CatalystX::CRUD::Model ) - while I believe
that it should be possible to have the CRUD as an add-on and let the
user work with his original Model.   I updated my work to try out this
- and also show the others what I really mean.  I've also looked into
other CRUDs - but I have not yet found one satisfying my requirements.
For example
CatalystX-ListFramework-Builder-0.41 is great - but it is not a
scaffolding, CatalystX::ListFramework is nice but is not REST-like,
Catalyst::Controller::DBIC::API is very close to what I need - and I
plan base my future work on it but for now there is some problem with
multiple inheritance in Catalyst Controllers that make it incompatible
with my approach, I hope that when we get the Moose version of
Catalyst this problem will go away. And I hope that then the base
controller will become a Moose role instead for greater flexibility.

In short  I am open for collaboration - but I found it difficult to
express my expectations for the library without writing my own code.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] New version of InstantCRUD

2009-02-16 Thread 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/


Re: [Catalyst] Re: loading data types from Oracle DB with DBIx::Class::Schema::Loader

2009-02-12 Thread Zbigniew Lukasiak
On Wed, Feb 11, 2009 at 1:47 PM, Karl Forner karl.for...@gmail.com wrote:
 I believe I fixed the problem (cf my post bug found in and tentatively
 fixed in DBIx::Class::Schema::Loader::DBI::Oracle::_tables_list in the dbix
 mailing list).

 Here's a copy :

 We had a problem because DBIx::Class::Schema::Loader did not get the
 column_info for our Oracle database : no data_types, is_nullable, default
 etc.. attributes were set.
 We traced the problem down to DBIx::Class::Schema::Loader::
 DBI::Oracle::_tables_list, that changed the table names to lowercase.

 So just commenting the line  69 : $table = lc $table;
 seems to fix the problem.

 The test is either to call the _tables_list and check the table names,
 or to create a schema on a n oracle db using
 DBIx::Class::Schema::Loader::make_schema_at, and to check that the generated
 DBIx::Class objects have
 the column attributes such asdata_type,  default_value , is_nullable ,
 size etc...


 Here are some details:
 DBIx::Class::Schema::Loader $VERSION = '0.04004'
  perl, v5.8.8 built for i486-linux-gnu-thread-multi

 diff:
 --- Oracle.pm2009-02-11 13:35:08.0 +0100
 +++ Oracle.pm.fixed2009-02-11 13:35:04.0 +0100
 @@ -66,7 +66,7 @@
  $table =~ s/\w+\.//;

  next if $table eq 'PLAN_TABLE';
 -$table = lc $table;
 +# $table = lc $table; # removed by kf

Hmm - it was just the first version of that code that I worken on -
but I remember that there some problems when the metadata was saved
under a hash key different from the table name, because it is referred
in other places.   Not that I am sure it applies here - but this might
be something you should  check.



-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] RFC: Catalyst::Controller::RHTMLO

2009-02-03 Thread Zbigniew Lukasiak
On Mon, Feb 2, 2009 at 7:59 PM, Jason Gottshall jgottsh...@capwiz.com wrote:
 Zbigniew Lukasiak wrote:

 Maybe I am just being lazy now - but before I start digging too deep -
 did you take into accout that some forms require loading stuff from
 the DB?  It can happen in to cases:

 1) loading SELECT choices lists - this one is easy - because it can be
 done at initialisation as it does not depend on th request.

 2) loading related forms for one to many relations - where you don't
 know how many related forms you need until you have the main object -
 i.e. until request time.  See Rose::HTML::Form::Repeatable.

 Yes, I'm actually thinking of doing

  my $form = $class-new( app = $c );

 so that the form can access model-related stuff as necessary. (This is safe
 because RHTMLO automatically weakens any value passed to -app). Would
 something like that address your cases?

Hmm - I thought you mentioned something about caching the form objects
between requests?  Passing $c to the creator means you create the
forms on per request basis.   If you like the caching idea - then what
would be needed is a kind of two phase initialisation.  First you
create a prototype - and then you add the necessary repeatable
sub-forms on per request basis to it (of course this is only needed if
you use repeatable sub-forms).

Cheers,
Zbigniew
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] RFC: Catalyst::Controller::RHTMLO

2009-01-31 Thread Zbigniew Lukasiak
On Sat, Jan 31, 2009 at 12:03 AM, Jason Gottshall jgottsh...@capwiz.com wrote:
 Ok, for those of you who have been waiting with bated breath, here's my
 second attempt at a base controller for loading Rose::HTML::Form classes.
 I've completely refactored/rewritten the configuration stuff after a long
 chat with mst. I also eliminated the handling of multiple instances of the
 same form in the same action, having determined that it's just not a
 meaningful case. I did *not* implement any caching mechanism, based on my
 concern about form objects being modified beyond simple parameter
 initialization.

 I think this version is a *lot* better, and I'd appreciate any additional
 feedback before I package it up for CPAN. Thanks!

 package Catalyst::Controller::RHTMLO;

 use strict;
 use warnings;

 use base 'Catalyst::Controller';
 use MRO::Compat;# to get $self-next::method() right
 use Catalyst::Utils;

 =head1 NAME

 Catalyst::Controller::RHTMLO - Catalyst base controller for integrating
 Rose::HTML::Form objects

 =head1 SYNOPSIS

package MyApp::Controller::Books;
use base 'Catalyst::Controller::RHTMLO';

# loads MyApp::Form::Book, which should -isa('Rose::HTML::Form')
sub edit : Local Form('Book') {
my ( $self, $c ) = @_;

# form object is already init'ed with params and stashed
my $form = $c-stash-{form};

if ( $form-was_submitted ) {
if ( $form-validate ) {
# write to db or whatever
}
else {
# show errors or whatever
}
}
}

# display several search forms on same page
sub search : Local Form('ByAuthor') Form('ByTitle') {
my ( $self, $c ) = @_;

if ( $c-stash-{forms}-{ByAuthor}-was_submitted ) {
# look up books by author
}
elsif { $c-stash-{forms}-{ByTitle}-was_submitted ) {
# look up books by title, duh
}
}

 =head1 DESCRIPTION

 This base controller glues LCatalyst actions to form classes derived from
 LRose::HTML::Form, a component of John Siracusa's burgeoning LRose
 framework. Unlike some other form-loading modules (see L/PRIOR ART),
 this one does not include any mechanism for defining form structures; it
 merely loads, instantiates, and initializes pre-written form classes for use
 in your controllers.

 In order to utilize a particular form in a particular Catalyst action,
 simply declare an attribute on the subroutine:

sub edit : Local Form('Book') { }

 This will ensure that CMyApp::Form::Book is loaded and initialized,
 basically equivalent to the following:

my $form = MyApp::Form::Book-new();
$form-params($c-req-params);
$form-init_fields;
$c-stash-{form} = $form;

 The namespace used to complete the form class name is
 Lconfigurable|/CONFIGURATION, or you can specify a full package name by
 prepending a 'plus' sign:

sub edit : Local Form('+My::FormClasses::Book') { }

 To utilize more than one distinct form class in the same action, simply
 declare additional attributes:

sub search : Local Form('ByAuthor') Form('ByTitle') Form('BySubject') {
my ($self, $c) = @_;


 $c-stash-{forms}{ByAuthor}-action($c-uri_for('/search/byauthor'));
$c-stash-{forms}{ByTitle}-method('GET');
$c-stash-{forms}{BySubject}-name('bytopic');
}

 The first form listed will be stored in the stash in the usual location;
 Iall the forms (including the first) will be stored under a separate
 (Lconfigurable|/CONFIGURATION) stash key, in a hash keyed to the name used
 to load them.

 =head1 CONFIGURATION

 You can override many defaults using Catalyst's configuration mechanism:

__PACKAGE__-config(
# settings for all controllers using this base
'Catalyst::Controller::RHTMLO' = {
form_attr = 'HasForm',
form_action_class = 'MyApp::Action::RoseForm',
form_stash_name   = 'formobj',
form_stash_hash   = 'allforms',
form_prefix   = 'MyApp::RoseForm',
},
# settings for specific controllers in MyApp
'Controller::Foo' = { # or 'C::Foo' if MyApp is built that way
form_prefix   = 'MyApp::FooForms',
},
);

 =over

 =item Cform_action_class

 Default: C'Catalyst::Controller::RHTMLO::Action'

 If you want to add more functionality to the automatic form loading and
 initialization, you can create your own custom action class:

package MyApp::Action::RoseForm;
use base 'Catalyst::Controller::RHTMLO::Action';

sub execute {
my $self = shift;
my ($controller, $c, @args) = @_;

# load forms via base class
$self-next::method(@_);

# do cool stuff
$c-stash-{form}-add_fields(
secure_token = {
type  = 'hidden',
value = $c-some_cool_security_token
}
);
return;
}

 =item Cform_attr

 Default: C'Form'

 

Re: [Catalyst] mod_perl converts latin1 to utf8 !?

2008-12-29 Thread Zbigniew Lukasiak
On Sun, Dec 28, 2008 at 12:17 PM, Bjørn-Helge Mevik b...@mevik.net wrote:

snip snip

 I tried modifying Catalyst::Plugin::Unicode the following way:
 062016150213:/usr/share/perl5/Catalyst/Plugin# diff Unicode.pm.orig Unicode.pm
 3a4
 use Encode qw(encode decode);
 22c23
  utf8::encode( $c-response-{body} );
 ---
 encode('ISO-8859-1', $c-response-{body} );
 38c39
  utf8::decode($_) for ( ref($value) ? @{$value} : $value );
 ---
 Encode::decode('ISO-8859-1', $_) for ( ref($value) ? @{$value} : 
 $value );

 When running under the development server, this seemed to be a no-op:
 everything still worked perfectly.

 Under mod_perl, it was almost a no-op as well.  The only difference
 was that when entering non-ASCII letters in a form field and storing
 it, the entered characters were now correctly handled -- however, any
 _existing_ non-ASCII character now became stored in the data base as
 UTF-8.

Here is my wild guess of what happened: in some circumstances the
internal representation of Perl strings can be latin1 - and if you
don't encode it when writing to the database you'll get latin1 in the
database - but for the most common case the internal representation
will be utf8 - and that you'll have in the db when writing to it
without any encoding.  In theory you should not rely on that - because
it is *internal representation*.   You need to encode every output
(and decode every input) that comes from the Perl program to the
outside world - including the database. For each output (input) you do
it separately and you can use different encoding (like UTF-8 for the
web pages and Latin-1 for the DB).  Said that - I don't know much
about the practical side of that - for my work I just always use UTF-8
and  pg_enable_utf8.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Dispatching in Catalyst::Controller::SOAP::DocumentLiteralWrapped

2008-11-28 Thread Zbigniew Lukasiak
The POD for C::C::S::DLW says:

   A Document/Literal service is supposed to have one operation
per bind, as it's not techically possible
   to dispatch on the content of the Body. In fact, as the Body is
used as literal the dispatching should
   not even look at it, it should be based on the port that
received the request.

   RPC/Literal, on the other hand, supports the use of several
operations per bind, and the dispatching of
   this operations is based on the first and only child element of
the message body, which defines the
   operation. The arguments are set as the parts of the message in the WSDL.

   Document/Literal-Wrapped is a deviation of both, as the message
should be interpreted as Document/Lit-
   eral, but the dispatching requires an additional step of
looking at the SOAPAction HTTP header, which
   will identify the proper operation to be dispatched.

I am rather new to this SOAP affair - but according to
http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/ -
the dispaching in Document/Literal-Wrapped should be done on the first
and only child element of the message body, which defines the
operation just like in the RPC/Literal case.

Then formally you when you have a function of type A - ( B - C ) -
i.e. the RPC/Literal case - where the first parameter defines what
function is applied to the rest of arguments. Then you can always
uncurry it to (A, B) - C - that is you can have a function that takes
both parameters and returns the end result.  So if you treat the
dispatching as an internal affair in the server you can always say
that the function is of the right type for Document/Literal.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Dispatching in Catalyst::Controller::SOAP::DocumentLiteralWrapped

2008-11-28 Thread Zbigniew Lukasiak
On Fri, Nov 28, 2008 at 3:34 PM, Ian Sillitoe [EMAIL PROTECTED] wrote:
 I'm also new to this so any opinion is offered very much on a FWIW basis. I
 pretty much had this conversation the other day with ruoso on #catalyst - I
 don't have a copy of the logs but I'll provide a summary as I understood it.

 The document you pointed to (same document as I pointed to) is a good
 description of the different styles of WSDL. However, I was reminded that,
 regarding DocumentLiteralWrapped, this doc is really just an opinion since
 MS have provided no official specification for it (this is mentioned in the
 Where is doc/lit wrapped defined? section).

Yeah - but if we look at it formally: since there is no official
definition - then we should treat it as standard Document/Literal.
And, I can be completely mistaken here as I don't know the full
semantics of WSDL, but I have the hypothesis that this is possible
using the trick of treating the dispatching as an internal affair of
the server (and remembering that you can always uncurry a curried
function).  In other words,  we can pretend to have just one operation
of type:

( InternalOperation, Parameters ) - Output

and treat the the dispatching to the InternalOperations as a part of
the algorithm of this one official operation.

But if we do that - then we cannot rely on anything outside of the
Document/Literal specs (i.e. on the SOAPAction header).


 I certainly agree that it would be good to have C::C::S::DLW dispatching
 similar to RPC/Literal (name of the first child element) as that was my
 understanding of how it should work. Perhaps at least to allow this to be
 the default if no SOAPAction was explicitly provided.

 I could be wrong, but I also got the impression that the developers have
 already invested a fair amount of time providing this and maybe don't have
 tons of spare time for further development (especially supporting a style of
 WSDL that they clearly aren't very impressed by :). Basically that
 suggestions/fixes are probably best accompanied by suggested patches.


Yeah - I just hoped to first validate my understanding, before sending
any patches.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] OT: Use the CPAN, Luke? (was: Catalyst install failure due to Mouse.pm on Debian Etch)

2008-11-27 Thread Zbigniew Lukasiak
On Thu, Nov 27, 2008 at 3:55 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
 * Toby Corkindale [EMAIL PROTECTED] [2008-11-27 01:55]:
 The problem is the dependency Mouse (0.11) fails its unit tests
 there.

 That's really the sole solid argument against a flamboyant
 use-the-CPAN attitude: you end up pulling in heaps of bloat
 because none of the stuff was written to form a coherent whole:
 every author uses their own favourite way of doing some common
 thing so you get four different OO frameworks of varying heft,
 two different YAML modules, every JSON module there is, etc.,
 all loaded into the same perl process. What a waste.

 Case in point, Mouse is essentially Moose Light. Since Catalyst
 itself is becoming Moose-based, is there *any* reason to use
 Mouse instead? I suppose if it automatically stubs itself into
 a Moose loader where Moose is available, that would be not *too*
 bad, but it's still a pointlessly added dependency.

There is also Squirrel
(http://search.cpan.org/~sartak/Mouse-0.11/lib/Squirrel.pm) - it loads
Mouse unless Moose is already loaded (just citing the Synopsis).

At the operating system level I've seen sometimes 'virtual packages'
that decouple the services from packages that provide those services.
So you can have a service 'sendmail' that actually is provided by the
'postfix' package.
This level of compatibility between libraries is rather exceptional -
I think that Moose and Mouse are the only examples so far, but maybe
it is time to start thinking about that.   CatalystX::CRUD tries to
work with both RDBO and DBIC - the effect is a bit too heavyweight for
my liking, but it is a bold experiment.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] Catalyst::Controller::SOAP no operation `index' for portType error

2008-11-27 Thread Zbigniew Lukasiak
Hi,

I have a SOAP controller based on WSDL.   Maybe I confused something
but I understood that I need to add

# this is the endpoint from where the RPC operations will be
# dispatched. This code won't be executed at all.
# See Catalyst::Controller::SOAP::RPC.
sub index :Local SOAP('RPCEndpoint') {}

to the controller (as described in the Synopsis).  And then  the
client will be allowed to call the root address and be despatched to
the right action based on the SOAP message (instead of using different
addresses for each action).

But with this addition compilation fails with the error: no operation
`index' for portType {urn:calculator}SMSPortType, pick from 
Strictly speaking the message is true - there is no 'index' operation
defined in the WSDL - but I thought that this RPCEndpoint action would
be treated differently.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Water the grass roots, please

2008-11-12 Thread Zbigniew Lukasiak
On Wed, Nov 12, 2008 at 9:41 PM, Matt S Trout [EMAIL PROTECTED] wrote:
 Perlbuzz was kind enough to post an article by jshirley providing a
 different view of Catalyst; I've lobbed it at reddit:

 http://www.reddit.com/r/programming/comments/7czb5/populist_not_dictatorial_the_catalyst_web/

OK - I voted for it.  But doesn't it make us seem a bit desperate?  I
mean this direct invocation to mailing list subscribers not the
article.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Success stories please

2008-10-06 Thread Zbigniew Lukasiak
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?

2008-09-24 Thread Zbigniew Lukasiak
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?

2008-09-23 Thread Zbigniew Lukasiak
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

2008-09-13 Thread Zbigniew Lukasiak
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

2008-09-12 Thread Zbigniew Lukasiak
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

2008-08-18 Thread Zbigniew Lukasiak
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

2008-08-08 Thread Zbigniew Lukasiak
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

2008-06-17 Thread Zbigniew Lukasiak
On Sat, Jun 14, 2008 at 12:24 AM, Byron Young [EMAIL PROTECTED] wrote:
 I ran into the same problem.  But I found that adding this to my controllers 
 that inherit from multiple controller base classes works as a work around:

 use Class::C3;

 sub create_action {
my $self = shift;

return $self-maybe::next::method(@_);
 }

 It's an annoying workaround, but I didn't have time to pursue the issue any 
 further :P  Does anybody know why this might be happening?

 Anyway, I hope that helps somewhat..

Unfortunately it did not help - and I encountered one more strange behaviour.

So basically I changed the test controller to:

===
package Base;
use strict;
use warnings;

use base qw/Catalyst::Controller/;

sub basefoo  :Local { }


package Intermediate;
use strict;
use warnings;

use base qw/Catalyst::Controller Base/;  # this one does not inherit
actions from Base


package TestApp::Controller::Action::Subclassed;

use strict;
use warnings;
use Class::C3;

sub create_action {
   my $self = shift;

  return $self-maybe::next::method(@_);
}

use base qw/Intermediate/;

1;

===


But I got following error:

t/subclassed..Inconsistent hierarchy during C3 merge of class
'Intermediate': merging failed on parent 'Catalyst::Controller' at
/usr/local/lib/perl/5.8.8/Class/C3/XS.pm line 64.

So I changed that to:

===
package Base2;
use strict;
use warnings;

use base qw/Catalyst::Controller/;

package Base;
use strict;
use warnings;

use base qw/Catalyst::Controller/;

sub basefoo  :Local { }


package Intermediate;
use strict;
use warnings;

use base qw/Base2 Base/;  # this one does not inherit actions from Base


package TestApp::Controller::Action::Subclassed;

use strict;
use warnings;
use Class::C3;

sub create_action {
   my $self = shift;

  return $self-maybe::next::method(@_);
}

use base qw/Intermediate/;

1;


Mysteriously this one compiles OK - but basefoo still is not inherited.

--
Zbigniew


 Zbigniew Lukasiak wrote on 2008-06-13:
 I've tried to build a module that would merge two base controllers and
 then use it as another base controller.  Unfortunately it looks like
 only actions from the first base class in the 'use base ...' phrase are
 being inherited:

 I've created a test case for that - it is attached and I paste it
 below for your convenience.

 If someone sent me some instructions how to modify it to fit into the
 Moose model I'll test it on the Moose branch as well (I am not sure if
 they would be base controllers there at all - perhaps Roles instead?).

 Cheers,
 Zbigniew


 package TestApp::Controller::Action::SubclassedChained;
 use strict;
 use warnings;

 use base qw/Intermediate/;
 1;

 ==
 package Intermediate; use strict; use warnings;

 use base qw/Catalyst::Controller::REST Base/;  # this one does not
 inherit actions from Base
 #use base qw/Base Catalyst::Controller::REST/; # this one does

 1; ==
 package Base; use strict; use warnings;

 use base qw/Catalyst::Controller/;

 sub basefoo  :CaptureArgs(1) :Chained('/') { }
 sub baseendpoint :Args(1) :Chained('basefoo') { }
 1;



 --
 Zbigniew Lukasiak
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/



 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/





-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Actions as Moose::Role

2008-06-16 Thread Zbigniew Lukasiak
On Mon, Jun 16, 2008 at 9:52 PM, J. Shirley [EMAIL PROTECTED] wrote:
 On Mon, Jun 16, 2008 at 10:16 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
 Hi,

 I wanted to start preparing for Catamoose and thought about extracting
 some Controller code as Moose::Roles - but unfortunately Catalyst
 attributes don't compile normally:

 Invalid CODE attributes: CaptureArgs(1) : Chained('/') at t/lib/Base.pm line 
 7

 In a simple class:

 package Base;
 use strict;
 use warnings;

 #use Moose::Role;

 sub basefoo  :CaptureArgs(1) :Chained('/') { }
 sub baseendpoint :Args(1) :Chained('basefoo') { }

 1;


 --
 Zbigniew Lukasiak
 http://brudnopis.blogspot.com/
 http://perlalchemy.blogspot.com/


 Is it intentional to omit the use base 'Catalyst::Controller';?

Well - I was not sure about that - but with use base
'Catalyst::Controller'; I get:

Could not load class (Base) because : Can't locate object method
linearized_isa via package Moose::Meta::Role at
/home/zby/progs/Catalyst-Runtime/5.80/branches/moose/lib/Catalyst/ClassData.pm
line 23.


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

2008-05-16 Thread Zbigniew Lukasiak
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

2008-05-16 Thread Zbigniew Lukasiak
Hi,

I don't know what to do with this thread.

On Fri, May 16, 2008 at 6:31 PM, Dave Rolsky [EMAIL PROTECTED] wrote:
 On Fri, 16 May 2008, Zbigniew Lukasiak wrote:

 - a search

 I tend to prefer expressing searches with query parameters… hm.

 I understand that what you propose is '/cd?year=1968', is that right?
 I really don't know - but some people would prefer to do the search by
 POST, or might just like to have the uri as '/cd/search?year=1968'.

 Why would anyone care about GET vs POST? I guarantee most users don't care.

 If you mean they want to use a form, that has nothing to do with the method.
 Forms can submit GET requests.

It might need to be a POST if you need to download a file as one of
the search arguments (for example for searching for a similar
picture).


 The URI you propose could be RESTful, if you think of search as a noun,
 maybe short for search results.


OK - what I was argumenting about is that sometimes it is convenient
to have an URI like that.  The other part of the argument is that if
you have an uri '/cd/search' - then you should not use '/cd/1' to
retrieve the CD object - because then you mix data with commands (id
with actions).

 Example? I can't quite imagine what you would want to do here.

 Hmm - how about a help screen - conveniently at '/cd/help'?

 Again, could be RESTful.


Great.  I am only argumenting that sometimes you need such an uri - see above.

 One part of REST is that URIs contain nouns, period. The type of nouns, the
 path hierarchy, all that is irrelevant, the key is that the URI never
 contains a verb like submit or edit. Note that edit_form is a noun,
 and is perfectly RESTful, and _necessary_ if you plan to have browsers
 interact with a set of RESTful URIs.

As above.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

2008-05-15 Thread Zbigniew Lukasiak
Hi there,

This is a frequently recurring conversation - so I created a wiki page
to gather all the points where we reached some consensus:
http://catwiki.toeat.com/crud.  For the start I just dumped my
opinions.  I tried to be not controversial - but it is a wiki - if you
don't agree then you can edit it and make it more acceptable for you.

I am especially waiting for people with opinions on the REST and
browser REST part - I have got much knowledge in that area.

Cheers,
Zbigniew

On Sun, May 4, 2008 at 2:38 AM, luke saunders [EMAIL PROTECTED] wrote:
 I have started to write a Catalyst base controller for REST style CRUD
 via DBIC. I have noticed that a number of other people have been
 working on or are thinking about working on something similar, most
 notabley J. Shirley who seems to be creating
 Catalyst::Controller::REST::DBIC::Item
 (http://dev.catalystframework.org/svnweb/Catalyst/browse/Catalyst-Controller-REST-DBIC-Item/)
 and some chaps from a recent thread on this list (entitled
 Dispatching with Chained vs HTTP method).

 Ideally I would like to merge J. Shirley's effort into mine (or visa
 versa) along with anything that anyone else has. Basically I want to
 avoid ending up with a load of modules that all do the same thing.

 My effort is heavily based on something mst wrote a while ago, and
 since then I've ended up writing something very similar for every
 project I've worked on which indicates it's worth OSing. Essentially
 it is used like so:

  package MyApp::Controller::API::REST::CD;

  use base qw/Catalyst::Controller::REST::DBIC/;

  ...

  __PACKAGE__-config
( action = { setup = { PathPart = 'cd', Chained =
 '/api/rest/rest_base' } },
  class = 'RestTestDB::CD',
  create_requires = ['artist', 'title', 'year' ],
  update_allows = ['title', 'year']
  );

 And this gets you the following endpoints to fire requests at:
/api/rest/cd/create
/api/rest/cd/id/[cdid]/update
/api/rest/cd/id/[cdid]/delete
/api/rest/cd/id/[cdid]/add_to_rel/[relation]
/api/rest/cd/id/[cdid]/remove_from_rel/[relation]

 The full source is here:
 http://lukesaunders.me.uk/dists/Catalyst-Controller-REST-DBIC-1.00.tar.gz

 If you have a few moments please have a look, especially if you are
 working on something similar. Today I even wrote a test suite which
 has a test app and is probably the best place to look to see what it
 does.

 Note that it lacks:
 - list and view type methods which dump objects to JSON (or whatever)
 - clever validation - it should validate based on the DBIC column
 definitions but it doesn't
 - any auth - not sure if it should or not, but it's possible

 Also it doesn't distinguish between POST, PUT, DELETE and GET HTTP
 requests favouring instead entirely separate endpoints, but that's up
 for discussion.

 So, J. Shirley, do you have any interest in a merge? And others, do
 you have ideas and would you like to contribute?

 Thanks,
 Luke.

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] RFC: Catalyst::Controller::REST::DBIC

2008-05-15 Thread Zbigniew Lukasiak
On Thu, May 15, 2008 at 7:31 PM, Mark Trostler [EMAIL PROTECTED] wrote:
 You don't need 'create'  'update'  'delete' parts of your URL - those
 should be denoted by the request type - POST, PUT, or DELETE right?

Yes - you are right about REST, but what something more than that.  We
want to have is a REST interface together with something REST-like
that will work for browsers.

 Similarly you don't need 'id' in the url - so POST to /api/rest/cd will
 create a cd.  A PUT to /api/rest/cd/5 will update that CD - a DELETE to
 /api/rest/cd/5 will delete that CD...

Additionally we would like to have other non REST actions in the same
controller.  This mixing will require some separation between the
method names and the object id (which is data).  This is why I propose
/cd/instance/5 for the retrieve action.


--
Zbigniew

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: RFC: Catalyst::Controller::REST::DBIC

2008-05-15 Thread Zbigniew Lukasiak
On Thu, May 15, 2008 at 11:11 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
 * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-05-15 21:25]:
 On Thu, May 15, 2008 at 7:31 PM, Mark Trostler [EMAIL PROTECTED] wrote:
  Similarly you don't need 'id' in the url - so POST to
  /api/rest/cd will create a cd.  A PUT to /api/rest/cd/5 will
  update that CD - a DELETE to /api/rest/cd/5 will delete that
  CD...

 Additionally we would like to have other non REST actions in
 the same controller. This mixing will require some separation
 between the method names and the object id (which is data).

 You are thinking about it wrong. You don't put method names into
 the URI; you expose more of the state as things to manipulate.

 If you give an example of what you mean I can give you one of
 what I mean.

Hmm - frankly I have never thought out REST entirely - but I have the
feeling that it is always better to be cautious (and you know - be
liberal in what you receive).  Some ideas top of my head:

- a login method (the advantage would be that it does not need to redirect)

- a search

- exposing some class data (as opposed to instance data) and maybe
class methods?

Cheers,
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Dispatching with Chained vs HTTP method

2008-05-07 Thread Zbigniew Lukasiak
On Wed, May 7, 2008 at 7:57 AM, Toby Corkindale [EMAIL PROTECTED] wrote:
 Hi Adam,



  On Wed, May 07, 2008 at 03:30:12PM +1000, Adam Clarke wrote:
   On 07/05/2008, at 11:05 AM, Toby Corkindale wrote:
  
   Ah, I was thinking of transactions vs a REST API, eg:
  PUT /user/1234/account_balance?subtract=1
  POST /user/4567/account_balance?add=1
   Since those are two separate HTTP requests, and REST specifically states
   you
   cannot maintain state on the server, how would you perform those two
   operations inside a transaction?
  
   (My solution is to implement it in one request, like:
  PUT /user/1234/money_transfer?user=4567;amount=1
   However that is not CRUD-like, nor a direct mapping of DBIC functionality
   to
   REST)
  
   The solution suggested in Restful Web Services is to POST to a factory
   resource which creates you with a transaction resource. e.g. POST
   /transactions/account-transfer returns Location:
   /transactions/account-transfer/11a5, where the 11a5 is a unique
   transaction identifier.
  
   Then PUT /transactions/account-transfer/11a5/accounts/checking/11, where
   11 is the account identifier. The body carries the transaction details, in
   the example the balances are adjusted absolutely, i.e. balance=150. A
   similar PUT is sent for the other account.
  
   Once the required components of the transaction have been PUT it is
   possible to rollback by DELETEing the transaction resource or commit it by
   putting committed=true to the resource.
  
   While seeming a bit fiddly, it does keep the state on the client and allows
   the client to make (at least some of) the commit / rollback decision rather
   than (only) the server.

  I've read parts of RESTful Web Services, but not that bit.. I'll have to go
  back and look.

  I wonder how one goes about implementing such a transaction on the server
  side.. One would not want to lock DB rows indefinitely, waiting for the 
 client
  to finally complete the transaction. But if one just recorded the queries and
  then executed them all (internally) at the end, then other risks exist, eg:

  $id = POST transaction
  $amount = GET /user/1/account_balance
  $amount2 = GET /user/2/account_balance
  PUT /user/1/account_balance/$amount-1
  PUT /user/2/account_balance/$amount+1
  PUT transaction/$id?completed

How about:

$id = POST transaction
PUT /transaction/$id/payer/1
PUT /transaction/$id/receiver/2
PUT /transaction/$id/amount/1
PUT /transaction/$id?completed

or even

$id = POST transaction
PUT /transaction/$id?payer=1;receiver=2;amount=1
PUT /transaction/$id?completed


And - yeah - looks like we have differnet goals.  But I'll watch your
project proceeding :)

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Catalyst / dbix-class / mysql / REST job

2008-05-07 Thread Zbigniew Lukasiak
There were a few long threads on the subject of REST CRUD in Catalyst
here.  Maybe you would like to crowd source a bit - and make a
competition for the code pieced that you need?  Inspiration:
http://www.ddj.com/architect/207404123?pgno=1

Cheers,
Zbigniew

On Wed, May 7, 2008 at 6:52 PM, Mark Trostler [EMAIL PROTECTED] wrote:
 The job description is kinda crapy:

  http://jobs.perl.org/job/8624

  But you can work in Sunnyvale, CA or Carslbad, CA.

  The backend in Catalyst/REST/DBIx::Class/MySQL.

  Frontends are currently command line/library using Moose and lots of AJAXy
 Javascript (using ExtJS - yah should be YUI ideally...).

  Join the team!
 Mark

  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Anybody who fancies some LWP poking ...

2008-05-06 Thread Zbigniew Lukasiak
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

2008-05-05 Thread Zbigniew Lukasiak
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

2008-05-04 Thread Zbigniew Lukasiak
On Sun, May 4, 2008 at 6:06 PM, J. Shirley [EMAIL PROTECTED] wrote:
 On Sun, May 4, 2008 at 8:52 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
  

   Sorry but I don't understand your point - so maybe first I'll restate
mine.  If you have primary key in the database that is of type varchar
(or char or ...) then 'create' is a legitimage value for that primary
key.
  
If you just don't like the string 'id' in the URI - then I have not
any preference to that - it can be /foo/primary_key/ for me.
  

  My point is that you do not have to use the primary key as the record
  lookup identifier.

  A user has no control over the record lookup identifier (ID) when you
  do things like /user/{primary_key} (or /user/id/{primary_key}, which
  is just converting named params to positional in a weird way).  In a
  lot of cases, the record lookup identifier makes more sense to be
  somewhat bound to the user.  As an example, lets say registering for a
  web service where you have to have a unique login:
 POST /user/jshirley
 ---
 login: jshirley
 first_name: Jay
 last_name: Shirley
 ...

  Now, it's a simple check here - does /user/jshirley exist?  If so,
  reject the request appropriately.  If not, create the user at
  /user/jshirley.

  The primary key that the database uses is completely useless to the
  user.  /user/1634254 is silly, /user/jshirley is meaningful.

  If the ID is generated, that gets a bit trickier but I usually handle
  that with a POST to /user with the data and then let the application
  forward me to the final URL of where the resource exists.

  The other reason is that this system breaks when you no longer have
  records tied to a database.  As an example, if you use an md5 sum of a
  file as the identifier.  /file/1234 doesn't work because it isn't in a
  database under that system (think of a MogileFS cluster or something
  with hash keys rather than primary keys in the conventional sense) -
  instead /file/{md5sum} is used.

  In brief summary, over-utilization of primary keys as record lookup
  identifiers ends up diminishing the human readability and
  accessibility of your web service.   I'm not trying to win over any
  converts, because I think there is a time and a place for each (even
  in the same application, it just depends upon what each action is
  really doing).  If I'm not building something that is REST/webservice
  driven I tend to do the /user/{id or token} (with a simple regex to
  check, and if someone has a login of all numbers then screw 'em) - but
  it's a very different strategy when I work with webservices -- each
  time I always make sure if the record lookup indicator should be the
  primary key, and what cases should it not and then react accordingly.

Then we are talking about two diffrent things.  My point is that you
should not have /foo/create and foo/{id or token} - because you mix a
reserverd work 'create' with data, you can never guarantee that the
data, be it primary key or token or whatever, does not contain
'create'.

I do understand that in full REST design you would not have a
'/foo/create/' uri - but if you want to add this REST as an add-on to
a controller you'll still have other methods on the controller that
could conflict with the token/id.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Dispatching with Chained vs HTTP method

2008-04-30 Thread Zbigniew Lukasiak
Hi Toby,

I don't know if you are aware - but building a REST-like CRUD
interface to DBIx::Schema is my long term goal (started with
Catalyst::Example::InstantCRUD).  Do you think we could collaborate?

Cheers,
Zbyszek

On Wed, Apr 30, 2008 at 10:26 AM, Toby Corkindale [EMAIL PROTECTED] wrote:
 just looking for some advice on the best way to do something..

  So I wrote a controller class using Chained that basically auto-converts any
  DBIx::Schema (which includes a tiny extra base class itself) into a REST 
 API..
  Well, a simple one anyway - it supports find and search so far, and foreign
  keys in the objects get serialised into hashes of the URIs to fetch them.

  All working nicely so far, but this is all for GET queries.

  But the behaviour should be different depending upon whether you
 GET /item/1234
  or
 DELETE /item/1234
  etc.

  I was thinking something like this: (Abbreviated code below)

  
  sub item_by_id : Chained CaptureArgs(2) {
 my ($self, $c, $type, $id) = @_;
 $c-stash-{item} = $c-model(DB:$type)-find($id);
  }

  sub delete : Chained('item_by_id') Args ActionClass('MethodDELETE') {
 my ($self, $c) = @_;
 $c-stash-{item}-delete;
  }

  sub modify : Chained('item_by_id') Args ActionClass('MethodPUT') {
 my ($self, $c) = @_;
 $c-stash-{item}-update($c-request-params);
  }
  
  Then the appropriate ActionClasses would check if the $c-req-method eq 
 'GET'
  or 'DELETE' or whatever.

  But I was just wondering if you had other ideas, and if using ActionClasses
  with Chained actions is crackfuelled and going to lead to a world of misery 
 and
  pain.

  Cheers!
  Toby

  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Dispatching with Chained vs HTTP method

2008-04-30 Thread Zbigniew Lukasiak
On Wed, Apr 30, 2008 at 11:46 AM, Moritz Onken [EMAIL PROTECTED] wrote:
 Hi Zbyszek,

  do you plan FormFu support? In case the submitted values are not valid the
 response is a xml/json/whatever which includes the error messages.
  That would be really great :)

I have not yet settled down with the choice of the form processor.
I've started with FormFu - but now I am playing with Rose::HTML::Form
- and I found it much more flexible.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Sending email safely with Catalyst

2008-04-12 Thread Zbigniew Lukasiak
On Sat, Apr 12, 2008 at 1:06 AM, Dave Rolsky [EMAIL PROTECTED] wrote:
 On Fri, 11 Apr 2008, Jonathan Rockway wrote:


  In an ideal world, you should be able to dump the messages into your
  mail system's queue as quickly as you can dump them into a database
  table (adding to the mail queue is a disk write, adding to a database is
  a disk write, unless you've turned off data integrity).
 
  I could see how calculating the text of 1 mail messages during a
  request would be slow, but why would you want to do that?  Usually
  you'll just want to say Your account was created, [% name %]! and
  queue that.  The template rendering and the mail system's queue should
  be more than fast enough to handle that during a request.
 
  As for bulk emails, you probably have a process that calculates those
  outside of your Catalyst app anyway (running from cron), so calculate
  them, dump them into the mail queue, and let your mailer daemon figure
  out what to do.  Much better than putting a queue in front of a queue,
  IMHO.  This is UNIX after all.
 

  The big problem I've run into when sending lots of emails from a web app
 (just hundreds, in this case), is that it can be slow enough the browser
 times out.

  Presumably you could have a similar problem with a work queue as well.

  Ultimately, I suspect a solution that forks _immediately_ and then does its
 thing (whatever that thing may be) is going to be necessary past a certain
 scale.

  Then the trick becomes monitoring that forked process.

  Another solution might be to come up with a way to queue up the job with a
 single write and do the full email generation via cron. Either way, you have
 to add complexity to your app if you want to provide feedback on the job
 status to the user.

  I'll be working on this soon for an app I'm creating, and I suspect I'll go
 the route of doing a single insert and processing via a cron job. The upside
 of this is that for a multi-user app, I won't end up forking a whole bunch
 of email sending processes and I can exercise some control over the rate
 that email is generated.


My first approach was to do the sending in a cron job - but then came
the requirement that the emails should be sent as soon as possible.
Now I have a forking model, but I don't know if I implemented it
correctly (the mod_perl guide recommends against forking
http://modperlbook.org/html/10-2-Forking-and-Executing-Subprocessesfrom-mod_perl.html).
I am also contemplating a compromise of sending the first few emails
immediately and the rest from a cron job.



  -dave

  /*==
  VegGuide.Org
  Your guide to all that's veg
  ==*/



  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Sending email safely with Catalyst

2008-04-11 Thread Zbigniew Lukasiak
On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote:
 I see there's an Email plugin and wondered if this is enough to send
  email from a form safely  securely or whether something more involved
  like a port of NMS CGI exists?

  http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm
  http://nms-cgi.sourceforge.net/

  It's terribly easy to get this wrong so wanted some feedback from
  people who'd previously implemented something like this live before
  inadvertently turning my site into a spam conduit :-)


I've got a related question - does anyone send bulk emails with that
plugin?  Is the delay reasonable when sending let's say a hundred
emails or do I need a background mechanism for that?  I have now a
forking solution - but it is a bit complex (and for mod_perl they
recommend to do it in a 'cleanup' handler instead of a forked
process).


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Sending email safely with Catalyst

2008-04-11 Thread Zbigniew Lukasiak
On Fri, Apr 11, 2008 at 4:49 PM, J. Shirley [EMAIL PROTECTED] wrote:

 On Fri, Apr 11, 2008 at 3:51 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
   On Fri, Apr 11, 2008 at 11:42 AM, Paul Makepeace [EMAIL PROTECTED] wrote:
 I see there's an Email plugin and wondered if this is enough to send
  email from a form safely  securely or whether something more involved
  like a port of NMS CGI exists?

  http://search.cpan.org/~mramberg/Catalyst-Plugin-Email-0.08/Email.pm
  http://nms-cgi.sourceforge.net/

  It's terribly easy to get this wrong so wanted some feedback from
  people who'd previously implemented something like this live before
  inadvertently turning my site into a spam conduit :-)
  
  
I've got a related question - does anyone send bulk emails with that
plugin?  Is the delay reasonable when sending let's say a hundred
emails or do I need a background mechanism for that?  I have now a
forking solution - but it is a bit complex (and for mod_perl they
recommend to do it in a 'cleanup' handler instead of a forked
process).
  
  

  I've been dying to play with
  
 http://search.cpan.org/~btrott/Email-Send-TheSchwartz-0.01/lib/Email/Send/TheSchwartz.pm

  I like TheSchwartz because it's fairly simple, easy to get going
  and... has this module ready.  I'm hoping to have a reason to play
  with it in the next couple of months.

This is interesting - but the documentation unfortunately does not
answer following questions:

- The worker looks like a polling daemon - how often does it poll the
database?  Would it be feasible solution on an SQLite database (which
does not work very well with many concurrent connections).

- How should I run the worker process so that it does not die
unexpectedly?  Should I put it into inittab or perhaps should I run it
in a pair of processes that would fork another one if one of them
dies?


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: Catalyst-Manual-FAQ Addition

2008-04-03 Thread Zbigniew Lukasiak
On Wed, Apr 2, 2008 at 2:27 PM, Paul Makepeace [EMAIL PROTECTED] wrote:
 On Mon, Mar 31, 2008 at 7:09 PM, Aristotle Pagaltzis [EMAIL PROTECTED] 
 wrote:
   * Russell Jurney [EMAIL PROTECTED] [2008-03-31 14:30]:
  
I discovered that 'call' is a reserved word for Catalyst
 controllers, and any subroutines in a controller named 'call'
 will be ignored.
  
OK, but…
  
  
 So, attached is a patched Catalyst::Manual::FAQ indicating this
 condition.
  
… err, how is your question a frequently asked one?

  There would be some good mileage out of Catalyst::Manual::Gotchas

Just brainstorming:

How about first creating it at the wiki first - and distill it into a
POD document only after it  accumulates some more useful info.

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] not working URLS

2008-03-14 Thread Zbigniew Lukasiak
Check the new Catalyst wiki: http://catwiki.toeat.com/.   It'll become
the official one soon.

--
Zbigniew

On Thu, Mar 13, 2008 at 6:37 AM, Octavian Rasnita [EMAIL PROTECTED] wrote:
 Hi,

  On the page
  http://dev.catalystframework.org/wiki/Faq_ref#sc.1

  In the section Best practices there is a link to:
  http://home.ngmedia.net/chansen/catalyst/conf/

  that doesn't seem to display anything related to Catalyst.
  If somebody know if I could find the content of that page somewhere, please
  let me know.

  That page should contain set of web server configurations that you can
  build your environment from.
  (samples for Apache 1.3, 2.0, and lighttpd utilizing mod_perl, speedycgi,
  fastcgi, and standard cgi)

  Thanks.

  Octavian


  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-12 Thread Zbigniew Lukasiak
On Wed, Mar 12, 2008 at 12:33 PM, Kieren Diment [EMAIL PROTECTED] wrote:

  On 12 Mar 2008, at 21:50, Zbigniew Lukasiak wrote:

   After some more playing with CatalystX::CRUD I think I can formulate
   my arguments a bit more clearly.
  

  OK, bear in mind that you're competing with Reaction here.  Reaction
  has some promise, but its development is slow so far (for casual
  users anyway), and it may suffer from some of the hyperverbosity  and/
  or (superficially) excessive indirection that is endemic in
  enterprise ready™ software. I'm not qualified to comment further on
  this.

Yeah - I hope there is a room for two competitors here.




   I believe the objects that users of CatalystX::CRUD get in their
   controller should be the real things - i.e. objects from their models
   not CatalystX::CRUD::Model::Objects.  This would be the  minimal
   interface and minimal hassle for injecting CatalystX::CRUD::Controller
   actions to a legacy Catalyst controller.
  

  What I particularly like about InstantCRUD is that everything is
  spelled out nicely for the coder once they run the helper.  That is,
  mostly once you've been through the catalyst learning curve, the
  instantcrud learning curve isn't very much more at all.
  InstantCRUD's main problem is HTML::Widget, and secondarily the lack
  of many-to-many introspection.  I'm not sure how big the problem with
  the tight coupling with DBIC is - I'd like to see a shitfight between
  merlyn and mst, with zby as mediator to straighten that one out.  Or
  maybe between merlyn and zby with mst mediating ...

  I think it would be best  to be able to treat a CatalystX::CRUD
  application like any other catalyst application.  That is, minimal
  modification of $c-model('Foo') compared to an ordinary catalyst app
  so that the CRUD generator mostly gets out of the way.


Just thinking how this can be done - you need a
CatalystX::CRUD::ModelAdaptor:: and a model_adaptor_class config
option for the CRUD controller.  Then in the controller methods you
would do:

$c-stash-{object} = $self-model_adaptor-fetch( @arg );

instead of

$c-stash-{object} = $c-model( $self-model_name )-fetch(@arg);

and in places where you call methods on the object like: $obj-$method
you could do again $self-model_adaptor-$method( $obj ).

This way $c-stash-{object} could still be an unmodified object from
the model and you would have your indirection layer needed to make the
CRUD methods universal.

Cheers
Zbigniew




  For bonus points I'd like to see a REST service available by default,
  with a browser based service available on top of this.  This way we
  get the API for free and the browser UI  gets to forward to the REST
  API (with suitable massaging of the stash).




  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-12 Thread Zbigniew Lukasiak
On Wed, Mar 12, 2008 at 4:27 PM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
 On Wed, Mar 12, 2008 at 4:12 PM, Peter Karman [EMAIL PROTECTED] wrote:
  
  
On 03/12/2008 09:44 AM, Zbigniew Lukasiak wrote:
  
  So we'd have:

   sub thing : Local {
  my ($self, $c, $id) = @_;
  my $thing = $c-model('Foo')-fetch( id = $id );

 my $thing = $self-model_adaptor-fetch( id = $id );

 The model adaptor should know the model it is using (and in the case
 of DBIC also the table )
  
In my example, $self is not a CX::CRUD::Controller. Just a plain ol' 
 Catalyst::Controller.
Why must it implement a model_adaptor method then?

  OK - so that was just a misunderstanding - I thought we were still
  talking about the CRUD methods.


  
  
  

  $c-stash-{object} = $thing;  # NOT a CX::CRUD::Object
   }

  and if wanted to update $thing:

  $c-model('Foo')-update( $thing );

 $self-model_adaptor-update( $thing );

  I could live with that. Does it meet your needs? Does it make it 
 easier to implement a
  DBIC model and FormFu controller?


 Yes.  In general - my point is that let's do the wrapping only for the
 CRUD methods that need them.  Let's not force the user to use the CRUD
 wrappers as their models.

  
Users of CX::CRUD Models or Controllers don't have to use both together. 
 It's just easier
if they do. And CX::CRUD doesn't force you to only use its models.
  
You could have:
  
 lib/MyApp/Model/Foo.pm # not a CX::CRUD::Model. Just a DBIC::Schema 
 model.
 lib/MyApp/Model/FooCRUD.pm # is a CX::CRUD::Model::DBIC
  
MyApp::Model::FooCRUD can act like your ModelAdaptor. By adding yet 
 another kind of thing,
a model adaptor, into the mix, that feels more complex to me rather than 
 less.

  If you'd make them to use the same db connection than indeed this
  would be like the ModelAdaptor. But then again you should have just on
  adaptor per model type - not per table (for models with tables).

That should be: just one adaptor class per model type (class).




  
I think I'm agreeing with you that the CX::CRUD API could be simplified, 
 that the ::Object
class could go away, and that the Model class could take over the c/r/u/d 
 methods that
Object currently performs.

  Yeah - I would consider the objects on the stash as part of the
  interface so they should be the original ORM objects.


  
If you like the model_adaptor() syntax in the Controller API, how would 
 you implement a
ModelAdaptor class and how would you change the Controller API to use it?
  
--
  
  
   Peter Karman  .  [EMAIL PROTECTED]  .  http://peknet.com/
  
  
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: 
 http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
  





 --
  Zbigniew Lukasiak
  http://brudnopis.blogspot.com/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-12 Thread Zbigniew Lukasiak
On Wed, Mar 12, 2008 at 8:07 PM, Peter Karman [EMAIL PROTECTED] wrote:


  On 03/12/2008 01:24 PM, Zbigniew Lukasiak wrote:

  
   We are closing to it.  Basically the adaptor needs to store the table
   name in it's instance - that's all.
  

  So one adaptor per table? How is that different than one model per table?

It is one instance of adaptor per table instead of one class of
adaptors per table.



  --


 Peter Karman  .  [EMAIL PROTECTED]  .  http://peknet.com/


  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-10 Thread Zbigniew Lukasiak
Hi Peter,

On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman [EMAIL PROTECTED] wrote:

  Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated.


I had today another look at CatalystX::CRUD - it is promising, but I
think there is too many indirection layers in it.  For DBIC it
requires configuration of both CatalystX::CRUD::Model::DBIC and
CatalystX::CRUD::Object::DBIC.  I believe it could work with just one
- for example CatalystX::CRUD::Model::DBIC where you could configure
what methods on the object and how to call them to implement the
needed interface.

Or perhaps you could all of it move to CatalystX::CRUD::Model and add
configuration to interface it to DBIC and RDBO - they are not that
different.

What do you think?  I believe some reduction of the number of modules
used will simplify the whole thing.  Maybe we could start the
discussion with what you interface you need from the database model?

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-10 Thread Zbigniew Lukasiak
And another thought - in FormFu we have an interface to DBIC it's
called HTML::FormFu::Model::DBIC.  From reading the code it looks that
in CatalystX::CRUD::Model::DBIC you have also code for interfacing the
form library with DBIC - does that mean that HTML::FormFu::Model::DBIC
would not fit for CatalystX::CRUD?

Finally - it is all based on rather shallow reading through the
modules - sorry if I misinterpreted something.

--
Zbigniew

On Mon, Mar 10, 2008 at 1:14 PM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
 Hi Peter,


  On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman [EMAIL PROTECTED] wrote:
  
Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated.
  

  I had today another look at CatalystX::CRUD - it is promising, but I
  think there is too many indirection layers in it.  For DBIC it
  requires configuration of both CatalystX::CRUD::Model::DBIC and
  CatalystX::CRUD::Object::DBIC.  I believe it could work with just one
  - for example CatalystX::CRUD::Model::DBIC where you could configure
  what methods on the object and how to call them to implement the
  needed interface.

  Or perhaps you could all of it move to CatalystX::CRUD::Model and add
  configuration to interface it to DBIC and RDBO - they are not that
  different.

  What do you think?  I believe some reduction of the number of modules
  used will simplify the whole thing.  Maybe we could start the
  discussion with what you interface you need from the database model?



  --
  Zbigniew Lukasiak
  http://brudnopis.blogspot.com/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-03-10 Thread Zbigniew Lukasiak
On Mon, Mar 10, 2008 at 3:53 PM, Peter Karman [EMAIL PROTECTED] wrote:


  On 03/10/2008 07:14 AM, Zbigniew Lukasiak wrote:
   Hi Peter,
  
   On Wed, Feb 20, 2008 at 7:48 PM, Peter Karman [EMAIL PROTECTED] wrote:
Also look at CatalystX::CRUD::Model::DBIC. Feedback appreciated.
  
  
   I had today another look at CatalystX::CRUD - it is promising, but I
   think there is too many indirection layers in it.

  I usually fault the other direction, so that's an interesting read.


  For DBIC it
   requires configuration of both CatalystX::CRUD::Model::DBIC and
   CatalystX::CRUD::Object::DBIC.  I believe it could work with just one
   - for example CatalystX::CRUD::Model::DBIC where you could configure
   what methods on the object and how to call them to implement the
   needed interface.
  
   Or perhaps you could all of it move to CatalystX::CRUD::Model and add
   configuration to interface it to DBIC and RDBO - they are not that
   different.
  
   What do you think?  I believe some reduction of the number of modules
   used will simplify the whole thing.

  :) could be said for Catalyst in general...


   Maybe we could start the
   discussion with what you interface you need from the database model?
  

  My assumptions are:

  1. CRUD is not just databases. I have a CatalystX::CRUD::Model::SVN and 
 CatalystX::CRUD::Model::File
  (the latter as part of the core CX::CRUD dist). I'm also going to be working 
 on a ::LDAP
  implementation, which is a database but not a SQL-based ORM type one.

Ah - OK - that explains it why you need much more in the Models and
Objects than just simple renaming of methods.


  2. The Model class interacts with many Objects. The Model searches and 
 fetches, returning array or
  iterator or count. The Object is singular. It creates/reads/updates/deletes 
 one item (a db row, a
  file, etc). I know that the DBIC ResultSet combines some of those features 
 into one class, allowing
  you to update/delete/etc multiple rows at a time. I find that less simple, 
 conceptually, even if it
  is more convenient to use. Simple is not always the same as convenient, in 
 my book. Or otoh, a
  simple user interface might well be convenient to the user, but a real pita 
 (i.e. not simple) to the
  developer who must implement it.

  3. Users of a CX::CRUD::Model::* should not, in the common case, need to 
 override or configure the
  ::Object class. It's there to implement the basic create/read/update/delete 
 methods for the
  Model-specific object. But it should be, for all practical purposes, 
 invisible to the user. That's
  why there is evil AUTOLOAD hackery in the base Model.

  For a ORM like RDBO or DBIC, the Object class consists of easy pass-throughs 
 to the appropriate
  method on the delegate() object. But check out CatalystX::CRUD::Object::File 
 for
  one case where it is not so simple.

  If you need to override the behaviour of the ::Object class for any given 
 CX::CRUD::Model,
  especially for an ORM, I suspect that it should really be overridden outside 
 of Catalyst altogether,
  in the delegate class. These are thin Models.

  I do like the idea of simplifying. What I hear you saying is that getting 
 rid of the Object class
  would simplify things. I don't think it would. I think it would require 
 mixing 2 different concepts
  (the thing that gets objects, and the object itself). I tried to keep the 
 API as high-level and
  simple as I could. Individual implementations (like that for RDBO and DBIC) 
 can get more complicated
  because they have to implement an API that isn't necessarily like their own. 
 I think of it like DBI
  and the various DBD drivers.


Thanks for the explanation.

  That said, if you have specific changes you'd like to see, I'm open to 
 persuasion. I'm just not
  persuaded yet. :)


I need to play a bit with it - for the first pass I was a just a bit
overwhelmed by the many modules involved.  But if your goal is so
overarching then I understand the need for the complexity.  I'll try
to tread a path for FormFu in it.



  --
  Peter Karman  .  [EMAIL PROTECTED]  .  http://peknet.com/


  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Base controllers and multiple inheritance

2008-03-06 Thread Zbigniew Lukasiak
I would say don't use Catalyst::Controller::HTML::FormFu in that case
- the functionality it provides is rather basic.

By the way I am also working on a FormFu based CRUD Catalyst base
class (continuation of Catalyst::Example::InstantCRUD).  Looks like it
has become fashionable thing recently.

--
Zbigniew

On Wed, Mar 5, 2008 at 8:36 AM, Byron Young [EMAIL PROTECTED] wrote:
 Hi,

  I've been using Catalyst for a project and decided to make some base
  controllers for common functionality.  So far I've made two: CRUD, and
  List, for standard database operations and for sortable, paged listings
  of data.  They work fine on their own but I'm running into trouble with
  multiple inheritance.  If I have a controller for some database table
  that I want to inherit the actions from both CRUD and List, only the
  first one inherited will initialize properly.

  The inheritance looks like this:

Catalyst::Controller
 /\
/  \
   /\
  /Catalyst::Controller::HTML::FormFu
 /   |
  MyApp::Base::Controller::List   |
 \   |
  \MyApp::Base::Controller::CRUD
   \/
\  /
 \/
MyApp::Controller::SomeDatabaseTable


  Each of the controller base classes has a new() method which sets up
  config data and does error checking and whatnot.  If I inherit both of
  my base classes, only new() on the first inherited is called.  I've
  tried calling $class-NEXT::new(@_) in each, and I've also tried
  Class::C3's $class-maybe::next::method(@_), but new() is still not
  called down the second inheritance chain.  When I tried the Class::C3
  approach I called Class::C3::initialize() in MyApp.pm - I wasn't sure
  where to call it so I tried before and after MyApp-setup() - still no
  luck.

  Can somebody tell me why new() isn't called down both paths?

  Thanks,
  Byron

  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Doing work inside the DBIx::Class model

2008-02-21 Thread Zbigniew Lukasiak
On Thu, Feb 21, 2008 at 9:17 AM, Peter Sørensen [EMAIL PROTECTED] wrote:

  He meant result_source:
  
 http://cpan.uwinnipeg.ca/htdocs/DBIx-Class/DBIx/Class/ResultSet.html#result_source
  
  But this is not all and it is something that begs for a FAQ entry - I 
 always forget how to do it.  The important thing is how to add new methods 
 to the ResultSet:
  
  package ArchivedBooks;
use base qw/DBIx::Class/;
__PACKAGE__-table('books_archive');
__PACKAGE__-source_name('Books');
__PACKAGE__-resultset_class('ArchivedBooks::ResultSet');
  
  package ArchivedBooks::ResultSet;
  use strict;
  use warnings;
  
  use base qw( DBIx::Class::ResultSet );
  
  sub advanced_search {
   my ( $self, $params, $attrs ) = @_;
  
  $self now is a ResultSet - so you can use methods on it.
  ..


  I have a similar problem want -  to add some custom methods to the model. 
 I've read
  your references but still - I can't get this thing to work.

  I have generated the model using Catalyst and get the following layout:

   LogParser.pm
   LogParser
   |
   |Components.pm
   |Connectinfo.pm
   |Logtype.pm

  and if I take a look into Components it looks like:

  package LogParser::Schema::LogParserDB::Components;

  use strict;
  use warnings;

  use base 'DBIx::Class';

  __PACKAGE__-load_components(Core);
  __PACKAGE__-table(components);
  __PACKAGE__-add_columns(
   id,
   { data_type = INT, default_value = undef, is_nullable = 0, size = 11 
 },
   component,
   { data_type = VARCHAR, default_value = , is_nullable = 0, size = 32 
 },
   regex,
   { data_type = TEXT, default_value = , is_nullable = 0, size = 65535 
 },
   nvars,
   { data_type = INT, default_value = 1, is_nullable = 0, size = 10 },
   varnames,
   { data_type = VARCHAR, default_value = , is_nullable = 0, size = 64 
 },
  );
  __PACKAGE__-set_primary_key(id);


  # Created by DBIx::Class::Schema::Loader v0.04004 @ 2008-02-12 17:08:38
  # DO NOT MODIFY THIS OR ANYTHING ABOVE! md5sum:gkSc31rRGpYHxL8tAAd/kw

  # You can replace this text with custom content, and it will be preserved on 
 regeneration
  1;

  As I understand I have to add to above:

  __PACKAGE__-source_name('SomeName');

This looks like a mistake to me - I did not mention source_name
anywhere - I don't know what this is for.

  __PACKAGE__-resultset_class('Components::ResultSet');
  LogParser::Schema::LogParserDB::Components;ame
And what is this?

  and create a new package with:
I usually just add this package to the same file as the source package
- in this case to Components.pm.


  package LogParser::Schema::LogParserDB::Components::ResultSet;

 use strict;
  use warnings;

  use base qw( DBIx::Class::ResultSet );

  sub advanced_search {
   my ( $self, $params, $attrs ) = @_;
  }
  1;

  So I created Components/ResultSet.pm  with this content.

  But it fails with :

  Couldn't instantiate component LogParser::Model::LogParserDB, Cannot load 
 schema class 'LogParser::Schema::LogParserDB': Can't locate object method 
 source_name via package 
 LogParser::Schema::LogParserDB::Components::ResultSet at 
 /usr/lib/perl5/site_perl/5.8.5/DBIx/Class/Schema.pm line 301.

  I tried to remove the line:
  __PACKAGE__-source_name('SomeName');

  but still same problem.

  As I read the docs the meaning of this is to use another name than the
  default name so why use it???


see above


-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Calendar for Catalyst application?...

2008-02-20 Thread Zbigniew Lukasiak
On Feb 17, 2008 8:14 PM, Alex Povolotsky [EMAIL PROTECTED] wrote:
 Hello!

 I recall I've seen somewhere calendar plugin for catalyst applications,
 but I cannot find one. Maybe someone will point me to a missing link?...

Some very basic support you can get with
Template::Plugin::Calendar::Simple (assuming you use TT).

Zbigniew
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Instant CRUD with DBIC::Schema

2008-02-20 Thread Zbigniew Lukasiak
Are you talking about Catalyst::Example::InstantCRUD?  It uses DBIC -
see at CPAN.

It is still a bit outdated though - I have to admit that.  I have
plans to port it to use HTML::FormFu.

Cheers,
Zbigniew

On Wed, Feb 20, 2008 at 4:17 PM, Alex Povolotsky [EMAIL PROTECTED] wrote:
 Hello!

  Scaffold seems to be a good thing, but it is using CDBI. Maybe something
  like it with DBIC exists?

  Alex.


  ___
  List: Catalyst@lists.scsys.co.uk
  Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
  Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
  Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: REST - like uri design for CRUD

2008-01-22 Thread Zbigniew Lukasiak
On Jan 22, 2008 8:25 AM, Zbigniew Lukasiak [EMAIL PROTECTED] wrote:
 On Jan 22, 2008 1:30 AM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
  * Zbigniew Lukasiak [EMAIL PROTECTED] [2008-01-21 07:40]:
   While we are at that - I do understand the need to divide the
   operations into the 'indempotent' and 'non-indempotent' classes
   (because of caching and predictive link loading) - but what is
   really the practical argument for having two more classes (PUT
   and DELETE)?
 
  I don't understand this question. It sounds like you have some
  confusion about several distinct things and that you don't
  actually understand what idempotence is. Can you try to explain
  a bit more what you are trying to ask? Are you just asking why
  there are more verbs than GET and POST? Are you asking about why
  it's important to categorise verbs as non-/safe in addition to
  non-/idempotent? Is it something all together different?

 The first one.  Why you need to split the class of non-idempotent
 operations into three more categories (POST, PUT and DELETE).

Just after sending it I have realized that DELETE can be also viewed
as idempotent since a second call to it does not really change the
state (even if it can return an error to the caller).
And that shows another question - perhaps all we need is the simple
division into safe and non-safe operations?

--
Z.

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


[Catalyst] REST - like uri design for CRUD

2008-01-20 Thread Zbigniew Lukasiak
I know this has been discussed already - but I can't find it in the archives.

What I conjured is:

/class/search
/class/id//view
/class/id//update
/class/create

Update and create use really the same logic and templates - so I just
forward to a create_or_update action from them.

What are your opinions?

-- 
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] REST - like uri design for CRUD

2008-01-20 Thread Zbigniew Lukasiak
On Jan 20, 2008 10:33 PM, Thomas L. Shinnick [EMAIL PROTECTED] wrote:



 At 01:56 PM 1/20/2008, Zbigniew Lukasiak wrote:

 I know this has been discussed already - but I can't find it in the
 archives.

  What I conjured is:

  /class/search
  /class/id//view
  /class/id//update
  /class/create

  Update and create use really the same logic and templates - so I just
  forward to a create_or_update action from them.

  What are your opinions?

  --
  Zbigniew Lukasiak
  spew register=pedant

  The book RESTful Web Services has been very useful to me in understanding
 the confusion about what REST means when it comes to 'verbs'.  And that I'm
 interested in how close one can come to 'strict' REST design using Catalyst.

  One important topic in the book is that people mix 'verbs' into their URIs
 when they shouldn't, or at least when they don't _have_ to.  Using the
 book's concepts your URIs would become

  1)  GET/class?pattern=breadbox
  2)  GET/class/id/
  3)  PUT/class/id/
  4)  POST /class

While we are at that - I do understand the need to divide the
operations into the 'indempotent' and 'non-indempotent' classes
(because of caching and predictive link loading) - but what is really
the practical argument for having two more classes (PUT and DELETE)?

Cheers,
Zbigniew





  1) is your /class/search and says let me retrieve the
 representation/list of the items selected by searching for the given
 pattern, where the base URI would indicate the set/list of items, and the
 pattern is kept in the query parameters because it could be anything.  Note
 that the idea is that GET /class references the list of all items, and you
 here are just qualifying that search with the pattern.

  2) Your /class/id//view would be seen in strict REST as just a GET of
 /class/id/.  The HTTP 'verb' GET already says give me a representation
 of the item.  Done.

  3) Your /class/id//update would become a PUT of /class/id/,
 where the new representation coming from the remote client would _replace_
 the old representation/data for that item.  This strict use of the HTTP
 'PUT' verb is actually the hardest to accomplish, as it assumes that the
 remote client can receive and update a representation on the client, and
 then send it back using PUT.  It is easiest to picture this usage when the
 client completely replaces the old representation held on the server.  (see
 farther below for why)

  4) Your /class/create becomes a POST to /class.  This was another
 concept brought out by the book.  The matter of who determines the item's
 'id' is important.  Here we assume that the _server_ will determine the id
 of the new added item.  You do a POST to the base URI of the data area, and
 the server determines the new id, stores the data into the item, and does a
 redirect to tell the remote client where the new item is, that is, what is
 the new item's URI, for instance /class/id/1234.

  Why is who determines the id important?  Because it says what HTTP verb
 you should use to create a new item.  If the server, you use POST to add
 another item.  (Much discussion of that most misunderstood of HTTP
 methods: POST in the book)  But if the remote client were to determine the
 id, say because the id is a license plate number input at the client, then
 strict REST would say the client should do a PUT to /class/id/STRWBYP and
 the client would send the complete data for the item.  The server would
 create the item using the id 'STRWBYP as requested by the client.

  Creation using POST would say create a new item and tell me (the client)
 where you (the server) put it.  Creation using PUT defines where to put it
 to the server, because the client knows what the id should be.

  So under some designs it is possible that PUT will be used for both
 creation of new items and update (replacement) of existing items.  In both
 these cases (under such a design) the client knows the correct id for the
 item.

  Anyway this spew was prompted by the new pedant seeing 'REST' in the
 subject and then no mention of 'PUT', etc.  The book tries to be clear that
 it depends on both your design and the capabilities of the client
 whether you can implement using the strict REST HTTP verb set GET, PUT, and
 POST, or whether you must compromise on a REST-like set of GET and POST.
 The authors discuss how to overload POST to effect PUT-like usage, because
 we have to implement in the real world.  But they are clear about the goals
 of RESTful design, the problems it solves, and the benefits it brings in
 the real world.

  It looks to be very useful to consider URI design with a view towards how
 would I accomplish this by splitting my data objects into URI addressable
 data that can be manipulated using the full set of HTTP verbs GET, PUT, POST
 and HEAD.  (And not putting verbs into URIs that might be cached)

  /spew
 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo

Re: [Catalyst] ResultSet renderer?

2008-01-05 Thread Zbigniew Lukasiak
On Jan 4, 2008 11:20 PM, Bruce J Keeler [EMAIL PROTECTED] wrote:
 Greetings, Catalystos!

 I'm looking to find or create a canned solution for rendering
 DBIx::Class::ResultSets as paged, sortable HTML tables.  All of the
 examples I've seen do this manually, foreaching through the resultset,
 spitting out trs and tds and so on.  Seems like the sort of wheel
 that shouldn't need to be reinvented.

You might have a look at Catalyst::Example::InstantCRUD.  It is a bit
dated now - but I am working on a new versions of it (based on
HTML::FormFu instead of HTML::Widget).

Cheers,
Zbigniew
http://perlalchemy.blogspot.com

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] ASP.NET MVC#

2007-12-22 Thread Zbigniew Lukasiak
On Dec 21, 2007 10:22 PM, Daniel McBrearty [EMAIL PROTECTED] wrote:
 i'm not completely following the new syntax that you are proposing, so
 please forgive if I am wide of the mark here ... but ...

 IMO the existing syntax is really not *that* bad - the only mild crit
 I have is that Args() really means I'm an endpoint, which it doesn't
 say.

 For me, a simple improvement would be to allow an alternative name
 such as EndpointArgs that is a bit more obvious, and keep the rest
 just as it is.

My argument really is that the number of parameters an action takes is
independent from the fact that it is an end point or is not, and that
you should not have one attribute that carries both of those meanings.
  So my latest proposal is to use Args to indicate the numer of
parameters an action takes (just like you do it now, but also when you
now use CaptureArgs) and IsParent to indicate that you can attach
other actions to it.

 I worry a bit that two syntaxes, achieving the same thing but looking
 quite different to each other, and both coexisting in docs, mailing
 lists, and code, are just going to add more potential confusion than
 they clear up.

Understood.  If my proposal gets accepted I volunteer to purge
CaptureArgs from the docs (and the Ministry of Love will go after
those that mention CaptureArgs on the mailing lists).  I think my
proposal is really minimal - in fact I would say it does not introduce
more new things than your 'simple improvement' above.

Cheers,
Zbigniew Lukasiak
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] ASP.NET MVC#

2007-12-21 Thread Zbigniew Lukasiak
Or maybe a better idea would be to use IsParent (or Parent) for those
actions that can have children (logical isn't it?).  Then we could use
Args all the time instead of CaptureArgs (with EndPoint).

Z.

On Dec 20, 2007 12:31 PM, Matt S Trout [EMAIL PROTECTED] wrote:

 On Wed, Dec 19, 2007 at 02:18:17PM +, Zbigniew Lukasiak wrote:
  On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote:
   On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote:
Yeah - some time ago I proposed to add an EndPoint attribute and get
rid of the CaptureArgs one that is not very intuitive (and use Args in
both cases).
  
   I don't remember seeing the code - if you update your patch to work 
   against
   5.80 trunk we can have a look ...
 
  A proof of concept implementation is in
  Catalyst::Controller::PathPart.  It replaces the attributes at parsing
  time, I guess this would not be appropriate for the core of Catalyst.
  I am now going to port that change into
  lib/Catalyst/DispatchType/Chained.pm.  I am not sure I'll be able to
  do it though.

 Remember you can't break backcompat in the process either ...


 --
   Matt S Trout   Need help with your Catalyst or DBIx::Class project?
Technical Directorhttp://www.shadowcat.co.uk/catalyst/
  Shadowcat Systems Ltd.  Want a managed development or deployment platform?
 http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] ASP.NET MVC#

2007-12-19 Thread Zbigniew Lukasiak
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote:
 On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote:
  Yeah - some time ago I proposed to add an EndPoint attribute and get
  rid of the CaptureArgs one that is not very intuitive (and use Args in
  both cases).

 I don't remember seeing the code - if you update your patch to work against
 5.80 trunk we can have a look ...

A proof of concept implementation is in
Catalyst::Controller::PathPart.  It replaces the attributes at parsing
time, I guess this would not be appropriate for the core of Catalyst.
I am now going to port that change into
lib/Catalyst/DispatchType/Chained.pm.  I am not sure I'll be able to
do it though.

Cheers,
Zbigniew
http://perlalchemy.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] ASP.NET MVC#

2007-12-19 Thread Zbigniew Lukasiak
On Dec 18, 2007 2:00 AM, Matt S Trout [EMAIL PROTECTED] wrote:
 On Mon, Dec 17, 2007 at 08:39:29PM +, Zbigniew Lukasiak wrote:
  Yeah - some time ago I proposed to add an EndPoint attribute and get
  rid of the CaptureArgs one that is not very intuitive (and use Args in
  both cases).

 I don't remember seeing the code - if you update your patch to work against
 5.80 trunk we can have a look ...

Ok - so I attach a patch (it is against
http://dev.catalyst.perl.org/repos/Catalyst/branches/current/Catalyst-Runtime
- I hope that is the  5.80 trunk - if not tell me and I'll change it).
 It passes the tests.  In two cases when the test application uses the
original TestApp::Controller::Action::Chained::* instead of
TestApp::Controller::Action::ChainedEndPoint::* - I think this is due
to how the test application is build.  I've marked those cases in the
test file and modified the tests so that they pass.

For the tests I've copied the tests of
live_component_controller_action_chained.t and adopted it to test
TestApp::Controller::Action::ChainedEndPoint instead of
TestApp::Controller::Action::Chained.

So - what do you think?

Zbigniew
http://perlalchemy.blogspot.com/


ChainedEndPoint.diff.gz
Description: GNU Zip compressed data
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] [OT] ASP.NET MVC

2007-12-17 Thread Zbigniew Lukasiak
On Dec 17, 2007 4:03 PM, Daniel McBrearty [EMAIL PROTECTED] wrote:
 The chained thing is probably the single most useful thing in cat IMO
 (if it's possible to even make such a dumb call ;)

 The way I have come to see it (it took a while, reading discussions
 here helped me grasp this) is that the way you design your URI space
 is very very fundamental to design of a web app. Chained helps you to
 remember this and try to get it right at the start. It also makes the
 decision about what actions go in what controllers separate from
 decisions about URI namespace. (I haven't really figured out if that
 is entirely a good thing or not, but it seems helpful.)

 The syntax *is* a bit hard to get used to at first - I find that the
 important thing is to remember that Args() defines an endpoint (hope I
 am remembering that right), other than that take a good look at what

Yeah - some time ago I proposed to add an EndPoint attribute and get
rid of the CaptureArgs one that is not very intuitive (and use Args in
both cases).

-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Input/Parameter Checks

2007-12-13 Thread Zbigniew Lukasiak
You might have a look at
http://www.perlfoundation.org/perl5/index.cgi?form_processing - you'll
find there the most popular parameter validation modules.  By the way
if you use SQL queries with placeholders you don't need to fear SQL
injection attacks.

Cheers,
Zbyszek

On Dec 13, 2007 9:21 PM, Mesdaq, Ali [EMAIL PROTECTED] wrote:
 Anyone have some suggestions or references to good modules or best
 practices in this regards? This is mainly in regards to using these
 inputs in sql queries or other areas where common attacks against web
 applications happen. I wonder in the catalyst world what best practices
 are. Would it be a catalyst plugin that would best fit that role or a
 module that gets used in the controller possibly maybe just some code in
 the model? It just feels like its one of those things that has been
 solved by someone else way better than I would have done it and I am
 just not aware of it. Kinda like when I wrote my own logging module
 because at the time I didn't find a good one then I stumble accross
 log4perl and realize how badly I wasted my time!

 Thanks,
 --
 Ali Mesdaq (CISSP, GIAC-GREM)
 Security Researcher II
 Websense Security Labs
 http://www.WebsenseSecurityLabs.com
 --


  Protected by Websense Messaging Security ? www.websense.com

 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] Re: State of the art in form valid =?UTF-8?Q?ation; _opinion_poll=E2=80=A6_Model_based_forms/validation=3F?=

2007-12-06 Thread Zbigniew Lukasiak
By the way - I've created a page on Form Processing at the P5 wiki:
http://www.perlfoundation.org/perl5/index.cgi?form_processing

--
Zbyszek

On Dec 5, 2007 8:25 PM, Ashley Pond V [EMAIL PROTECTED] wrote:
 Really good food for thought from everyone. Strangely enough, at
 least when I notice, Bill's code is the most like my own of anyone on
 the list; in approach and style. I'm less certain than ever, of
 course, what I'll end up with but I'm better informed.

 Thanks everyone.


 On Dec 5, 2007, at 4:37 AM, A. Pagaltzis wrote:

  * Bill Moseley [EMAIL PROTECTED] [2007-12-05 05:45]:
  The Rose form code is very cool. That's what I based my forms
  on.
 
  Disclaimer: I haven't used Form::Processor. However from what
  I have seen so far, it seems to solve the *right* problem, with
  the right level of abstraction for common things and tweakability
  for individual needs, so it currently seems like the most likely
  validation framework to work for me.
 
  I don't find automatic form markup creation that useful -- the
  forms always seem to need customization.
 
  Template system of choice + HTML::FillInForm works for me and
  keeps things reasonably low-effort.
 
  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/
  [EMAIL PROTECTED]/
  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/[EMAIL PROTECTED]/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


Re: [Catalyst] State of the art in form validat =?UTF-8?Q?ion; _opinion_poll=E2=80=A6_Model_based_forms/validation=3F?=

2007-12-05 Thread Zbigniew Lukasiak
What I like about the FormFu approach is that it gives you a *path*
for the development.  For a quick start you just stay with the
defaults - they still are displayed OK and you can show the project to
someone.  Then when need to customise it's look and feel you generate
the templates and tickle them to submission.

--
Zbyszek

On Dec 5, 2007 9:16 AM, Carl Franks [EMAIL PROTECTED] wrote:
 On 05/12/2007, Ashley Pond V [EMAIL PROTECTED] wrote:
  What are best practices? DBIx::Class::Validation reusing your form
  package profiles? But you still have to write your own forms. I've
  searched around a lot and can't find a thorough, coherent Catalyst
  related doc about it.
 
  I really want one, final approach to this I'll use every time from
  now on instead of experimenting with packages and home rolled stuff
  over and over. If someone is there, or even close. Please kick down.

 I'm really happy with how HTML::FormFu is coming along.
 Like your example, you can define your entire form in any config file
 Config::Any supports. Although I (predictably) prefer the FormFu style
 declarations.

 It has lots of little shortcuts that make things easier, such as auto_label().
 If you set, for example, auto_label('label_%n') at the form-level,
 then all fields will automatically use localize() to set their own
 label (replacing the '%n' with their field name).
 Like many settings, this can be set at either the form-, the
 fieldset-, or the field-level, and when the method's used as a
 'getter', it traverses the field's parents, searching for a value.

 There's also an auto_error_message() which can get error messages from
 your localize() object, based on the field's name and/or type.

 (the next couple of features are currently only in svn, and will be
 released to cpan in the next week...)

 By default, the form's markup is generated internally by perl
 subroutines. However, by simply setting render_method('tt') it
 switches to using TT templates (which are installed using
 File::ShareDir) and generates the exact same markup.
 If you wish to customise the form markup, you can create a local copy
 of the templates, and change the form however you want.
 You can also use your own, single TT file, much like claco's example
 earlier in this thread, explicitly placing individual fields.

 There's also DBIC integration, which I'm currently in the process of
 documenting - again, on it's way to cpan soon.

 If you had, say, these 2 tables:

 table: user
 cols: name
 might_have: address

 table: address
 cols: user, street, city
 belongs_to: user

 Then you could create a form like so:

 ---
 elements:
   - name: name

   - type: Fieldset
 nested_name: address
 elements:
   - name: street
   - name: city

   - type: Submit

 If you then pass that form a 'user' row, it will automatically
 traverse the 'address' relationship, filling in the form fields:
 $form-values_from_model( $user_row );

 And when the form's submitted, you can save the changes back to the
 database, again, automatically following the relationship:
 $form-save_to_model( $user_row );

 It also handles has_one, has_many, and many_to_many relationships.

 To finish off, here's an example of how I'd probably write your form
 (as far as I can interpret it):

 ---
 auto_fieldset:
   legend: user

 elements:
   - name: last_name
 constraints:
   - type: Required
   - type: Length
 max: 50

   - name: suffix
 constraints:
   - type: Regex
 regex: '?-xism:\A[IVX]{1,3}\z'

   - name: email
 constraints:
   - type: Required
   - type: Email
   - type: Length
 max: 80

   - type: Submit

 If you're interested in looking further, the svn location is:
 http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu
 or you can ask any questions on the mailing list:
 http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/html-formfu

 Cheers,
 Carl


 ___
 List: Catalyst@lists.scsys.co.uk
 Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
 Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
 Dev site: http://dev.catalyst.perl.org/




-- 
Zbigniew Lukasiak
http://brudnopis.blogspot.com/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/
Dev site: http://dev.catalyst.perl.org/


  1   2   >