Re: [Catalyst] CMS

2008-03-02 Thread Kieren Diment


On 2 Mar 2008, at 17:21, Yousef Alhashemi wrote:

On Sat, Mar 1, 2008 at 9:18 PM, Octavian Rasnita  
[EMAIL PROTECTED] wrote:



Hi,

Is there a CMS made with Catalyst?



websiteinabox: http://code.google.com/p/websiteinabox/





wiab is a simple website publisher.  Needs a little work, but is good  
enough for 60% of your simple website publishing needs.  I'd like to  
see someone hack static publishing onto it a la movable type.  Also  
assuming that your needs are for simple website publishing, it's also  
easy enough to bolt the extra 35% of your needs on top  becauise a.   
it's catalyst and therefore flexible, and b. I deliberately  
documented it well (at least at the code level, there are a couple of  
gotchas in the user docs apparently).


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] CMS

2008-03-02 Thread Octavian Rasnita

From: Kieren Diment [EMAIL PROTECTED]



On 2 Mar 2008, at 17:21, Yousef Alhashemi wrote:

On Sat, Mar 1, 2008 at 9:18 PM, Octavian Rasnita  [EMAIL PROTECTED] 
wrote:



Hi,

Is there a CMS made with Catalyst?



websiteinabox: http://code.google.com/p/websiteinabox/





wiab is a simple website publisher.  Needs a little work, but is good 
enough for 60% of your simple website publishing needs.  I'd like to  see 
someone hack static publishing onto it a la movable type.  Also  assuming 
that your needs are for simple website publishing, it's also  easy enough 
to bolt the extra 35% of your needs on top  becauise a.   it's catalyst 
and therefore flexible, and b. I deliberately  documented it well (at 
least at the code level, there are a couple of  gotchas in the user docs 
apparently).




I will try to test it, although I thought there may be a all in one CMS 
that uses Catalyst that's better than other CMS made in Python or PHP, 
however I don't know if there is a perl CMS better than Drupal or Ploan, or 
at least I haven't seen a comparison showing one.


Octavian


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


Re: [Catalyst] utf8 in regexes in Catalyst

2008-03-02 Thread demerphq
On 02/03/2008, Alexandre Jousset [EMAIL PROTECTED] wrote:
 Hello list,

 I'm able tu use encoding utf8 in a normal Perl program to correctly
  match regexes like this : echo 'é' | perl -e 'use encoding utf8;print
   =~ /\w/' (in an utf8 terminal), but how could I achieve the same
  result in a Catalyst application? Am I obliged to use encoding in
  every module? Is there a way to do it globally? What is the right way to
  do this?

 My goal is to check input from utf8 forms.

Make sure that your pattern and string are utf8 and you wont have
problems and will get faster runtimes.

All use encoding 'utf8' is doing in that example is forcing your input
and code to be interpreted as utf8. You could easily do the same thing
in many other ways in code. In fact its recommended you avoid use
encoding at all.

Yves

-- 
perl -Mre=debug -e /just|another|perl|hacker/

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Session Expiry

2008-03-02 Thread Ash Berlin


On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:


In the second case, it's just a bug in the Session::Store::Cache store
that can be fixed with the addition of a backend_expires configuration
key, probably set to never by default.


Not quite true. It would look like it fixes it for most cases. A cache  
is just a cache. Don't rely on them (particularly memcahced) to keep  
data around until you told it you would like it to expire at - there  
is no guarantee of this happening, especially under heavy load.


Ash

___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] Session Expiry

2008-03-02 Thread Bill Moseley
On Sun, Mar 02, 2008 at 01:31:42PM +, Ash Berlin wrote:
 
 On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:
 
 In the second case, it's just a bug in the Session::Store::Cache store
 that can be fixed with the addition of a backend_expires configuration
 key, probably set to never by default.
 
 Not quite true. It would look like it fixes it for most cases. A cache  
 is just a cache. Don't rely on them (particularly memcahced) to keep  
 data around until you told it you would like it to expire at - there  
 is no guarantee of this happening, especially under heavy load.

Yes, very true.  A cache is a cache.  And the database server could
blow up, too.

What we are talking about is a situation where the session data is
(seemingly) suppose to persist for X seconds between requests, but
it's instead persisting X seconds between updates to the session
(which may not be every request).  It appears from the design of the
Session plugin that it's suppose to persist X seconds between requests
(the expires entry).  So, it looks like a design problem.

The fact that you might be using a store that deletes entries for
other reasons than expire time is another issue.

-- 
Bill Moseley
[EMAIL PROTECTED]


___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/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] utf8 in regexes in Catalyst

2008-03-02 Thread Alexandre Jousset

Hello Yves,

demerphq a écrit :

I'm able tu use encoding utf8 in a normal Perl program to correctly
 match regexes like this : echo 'é' | perl -e 'use encoding utf8;print
  =~ /\w/' (in an utf8 terminal), but how could I achieve the same
 result in a Catalyst application? Am I obliged to use encoding in
 every module? Is there a way to do it globally? What is the right way to
 do this?

My goal is to check input from utf8 forms.


Make sure that your pattern and string are utf8 and you wont have
problems and will get faster runtimes.


How can I make sure my pattern is utf8 since it is just /\w/ ?

	My string is utf8, it comes from an utf8 form. But maybe it is not 
really? How Perl/Catalyst treats data that come from a form?



All use encoding 'utf8' is doing in that example is forcing your input
and code to be interpreted as utf8. You could easily do the same thing
in many other ways in code. In fact its recommended you avoid use
encoding at all.


OK for this.

Thanks,
--
--  \^/--
---/ O \-----
--   | |/ \|  Alexandre (Midnite) Jousset  |   --
---|___|-----

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


[Catalyst] Re: utf8 in regexes in Catalyst

2008-03-02 Thread Aristotle Pagaltzis
Hi Alexandre,

don’t use encoding.pm. It’s a confused and broken design, and the
author himself recommends against its use. Its main purpose is to
allow you to write code in some arbitrary encoding. As a side
effect it sets your input/output encoding, but it shouldn’t, and
confusing the encoding of the source with the encoding of its
input/output is utterly broken.

Think about it this way: there a byte strings, and there a text
strings. Text strings consist of Unicode characters; byte strings
consist of byte values and have no meaning whatsoever as text.
(Even if you are used to thinking of them as though they did.)
Text strings need to be encoded to become byte strings; byte
strings need to be decoded to become text strings.

So for that one-liner, you do this:

echo 'é' | perl -MEncode -e '$_ = decode 'UTF-8', scalar ; print /\w/'

Yes, this is tedious. So what you do is you find ways to get the
parts of your program that speak to the outside world to decode
input on receipt and encode output on emission. Then inside your
program, you don’t need to think about it at all. F.ex., for the
one-liner, you would declare that your STDIN and STDOUT are in
UTF-8 and then reading from and writing to them automatically
does what it should. Handily, perl has a switch for that when it
comes to UTF-8:

echo 'é' | perl -CS -e 'print  =~ /\w/'

If your input was in a different encoding, you could use the
`open` pragma:

echo 'é' | perl -Mopen=':encoding(latin-1),:std' -e 'print  =~ /\w/'

Granted, that does not look like a big win in this example, but
if you had to do several I/O operations inside the code, it would
be, because you wouldn’t need to de-/encode every time.

So to deal with Unicode with minimal hassle, the conversion from
bytes to characters should happen at the “edge” of your code
where it interfaces with the outside world.

For Catalyst, that means things like Catalyst::Plugin::Unicode
and configuring your database and template engine correctly.

Aside from the configuration, your code should then avoid dealing
with encodings at all.

See also http://use.perl.org/~miyagawa/journal/35700

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

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


Re: [Catalyst] Session Expiry

2008-03-02 Thread Jonathan Rockway
* On Sun, Mar 02 2008, Ash Berlin wrote:
 On 2 Mar 2008, at 03:50, Jonathan Rockway wrote:

 In the second case, it's just a bug in the Session::Store::Cache store
 that can be fixed with the addition of a backend_expires configuration
 key, probably set to never by default.

 Not quite true. It would look like it fixes it for most cases. A cache
 is just a cache. Don't rely on them (particularly memcahced) to keep
 data around until you told it you would like it to expire at - there
 is no guarantee of this happening, especially under heavy load.

Yeah.  I think we've covered this about 1000 times on the list, so I
didn't say anything.  I still think using a lossy storage mechanism for
data you don't want to lose is silly.

I hate it when $SITE_I_VISIT loses my login session; use.perl does this
all the time... reddit does it occasionally.  It's annoying, and at some
time you're going to have to shut off your memcached machine.  Then all
your users have to re-log-in.

Regards,
Jonathan Rockway

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