Re: [Catalyst] what is the type of $context?
On 09/06/06, Yuval Kogman [EMAIL PROTECTED] wrote: On Fri, Jun 09, 2006 at 11:25:40 +0100, Carl Franks wrote: I'd be surprised if there *was* a way to do intropection with perl5. WTF? Perl is possibly the most lax and free minded language there is WRT inrospection. You can even hack in meta classes if you try hard enough. What other language lets you poke around the instance's structure, know it's class at runtime, and has a hash as a symbol table? Daniel defined introspection as: dump a list of all the subs it supports. As I said, how can there be a *reliable* way of doing that? I know I've used autoload in the past to provide getter/setters without having to copy/paste subs - they would never show up in the symbol table. Okay, we've now got cool modules such as Class::Accessor::Fast which are easer to use than autoload, and which do insert the subs into the symbol table, but there must be a lot of modules out there that still do it the old way. Would using Class::C3 effect the possible methods, or just the order of method-calls? Is it not possible that if a class uses something other than plain @ISA / SUPER, then simply looking at the symbol table for everything in @ISA may not be correct? btw, I don't know the proper definition of introspection with regard to programming - if it's broader than I was using it, then sorry for any confusion. Cheers, Carl ___ Catalyst mailing list [EMAIL PROTECTED] http://lists.rawmode.org/mailman/listinfo/catalyst
Re: [Catalyst] YAML vs. *
Wow, this is a long thread for only 4 hours! I dislike YAML, but I still prefer it to the other options you suggested. The main reason I dislike it is everytime I need to add an array to a cat config file, I need to either find a previous application that had an array in it's config file, or start up a shell and dump an array, because I can never remember the syntax. I think what would make me happy would be to simply have the auto-generated yaml config file have a half-dozen or so lines of comments at the top, containing a brief overview of the syntax and any vital reminders such as Don't use tabs! Good idea? Carl ___ Catalyst mailing list [EMAIL PROTECTED] http://lists.rawmode.org/mailman/listinfo/catalyst
Re: [Catalyst] YAML vs. *
On 09/06/06, Matt S Trout [EMAIL PROTECTED] wrote: Carl Franks wrote: I think what would make me happy would be to simply have the auto-generated yaml config file have a half-dozen or so lines of comments at the top, containing a brief overview of the syntax and any vital reminders such as Don't use tabs! I like. And I think with the amount of already-extant documentation using YAML, this is probably the lowest-friction answer as well. Fancy putting together a quick cheatsheet as a Catalyst::Helper patch? My initial estimate of a half dozen or so lines of comments was wildly inaccurate. To keep it readable, it's currently at 30 lines. Any suggestions of what could be trimmed out? Different layout suggestions? (Lines are currently limited to 78 chars) # Lines starting with # are comments. # Indent each new level with an equal number of space characters. # Tab characters cannot be used to indent. # A plain key/value pair ( ensure there is a space after the : ) #key: value # An empty value #key: '' # A List ( ensure there is a space after the - ) #key: # - value 1 # - value 2 # Nested key/values #key: # nested key 1: value # nested key 2: value # With a single-quoted value, use 2 quotes to represent a literal quote #key: 'single quote '' with a value' # Double-quoted values can contain escaped characters, such as newlines \n #key: line 1\n line 2 # Multiline values start with the character. Line-folding is applied. #key: # After processing, the linebreak between these 2 lines # will be removed. --- ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Alien-Dojo / HTML-Dojo merger suggestions
message cc'd to Dominique in case you're not still on the cat list. Further to the discussion a couple of weeks ago, I suggest deprecating HTML-Dojo (of which I'm the author), and merging it's functionality into Alien-Dojo, with the following changes. Backwards compatabilty shouldn't be an issue, as there's only been 1 release of Alien-Dojo, and it's broken as it doesn't include all files necessary for the dojo JS to work. So I'm pretty sure no-one's using it ;) Currently, HTML-Dojo comes with the dojo distro bundled. Alien-Dojo doesn't include the dojo code at all, it downloads it from the internet. I suggest Alien-Dojo includes the dojo code, but is capable of downloading and installing other versions from the internet. Advantages: The Alien-Dojo distro can be updated with each dojo release, meaning cpan clients will know of the upgrade. We'll have a permanent archive of dojo versions on cpan. The Alien-Dojo distro number will match the dojo version number, meaning the `use Alien::Dojo 0.3` idiom to ensure a minimum working version will work. Alien-Dojo currently isn't aware of the different dojo editions (customized builds) available. This capability will have to be added. By default, we should use the ajax edition, as that's the prefered dojo edition. Alien-Dojo should include all files from the dojo distrobution, not just the src directory. Alien-Dojo-new() allows a single argument, interpreted as the minimum version of dojo required. I suggest it's changed to be a named argument, to allow for expansion. Also, with experience of using dojo, I suggest it should instead mean the *exact* version you want, rather than minimum. (the dojo library changes a lot between releases). If you really want a minimum version, you can do `use Alien::Dojo x.x` Also, rather than dumping the js library directory into perl/site_lib, I'd rather the library is dumped into a single .pm file such as HTML-Dojo does. Like HTML-Dojo, the intended use is that the module is used by something such as Catalyst-Helper-Dojo to dump the library into an application directory, and so Alien-Dojo should not be used by general programs (such as for serving files live). To handle versions not already installed, I'm thinking it should first try using CPAN.pm, and if the version/edition isn't available there, to try downloading the library from the dojo website, building a .pm from it, and then installing it with ExtUtils::Install. Does that sound sane? Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] PPM vs CPAN
You may want to look into Vanilla / Strawberry perl as an alternative to ActivePerl. It includes the mingw (gcc) compiler and nmake, and the perl included is compiled from scratch with mingw, rather than ms compilers. http://win32.perl.org/wiki/index.php?title=Vanilla_Perl The files are here (get the .exe) : http://sourceforge.net/project/showfiles.php?group_id=158775package_id=178164release_id=393299 Vanilla Perl is officially experimental because until a few months ago some of the core modules were a bit flakey on windows, but I use it full time for development and running catalyst under fastcgi / apache and have no problems. The quite recent site http://win32.perl.org has a news item added today by Adam Kennedy, saying he's hoping to get a new release of Vanilla Perl and also an initial alpha of Strawberry Perl both out today. Strawberry perl in just Vanilla Perl, but with an up-to-date Bundle::CPAN, and IO / LWP modules - so it's considered a more realistic 'basic' version, rather than vanilla, which is really targeted at people wanting to do CPAN testing. http://win32.perl.org/wiki/index.php?title=Strawberry_Perl Anyway, as I said, I use Vanilla Perl, and have had very little trouble getting everything installed using CPAN.pm - no more trouble than occasionally crops up with other platforms - and the problems that exist have been getting fixed with-a-vengence these last few months. It doesn't come with PPM.pm, but I've written a script that will download PPM's from Kobes' repository and install them for me - I think the only modules I need to do that for are DBD::mysql and Image::Magick. PPM's are just archive files though, so it's easy enough to extract the files from. The next distribution will be Chocolate Perl, which will include a lot more useful modules, including everything that comes with ActivePerl (including PPM.pm) - hopefully we'll get an alpha of this out this year. On 29/06/06, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: Also, unless it's something absolutely necessary, I'd suggest you against deploying it in a Windows server. It's somewhat of a hassle to get mod_perl or FastCGI working correctly under Windows, the best I've got so far is running Catalyst under Apache::Registry, since mod_perl crashes when using PerlModule directives and I can't manage to even compile FastCGI and it's related Perl module and the built-in server becomes really slow if you need to support IE clients directly connecting thanks to the necessary -k switch. I use a binary fastcgi apache module which I downloaded from the fastcgi website. I can't remember whether I had problems compiling FCGI.pm - maybe that's one of the few I had to get a PPM for. If you use PPM.pm, make sure you add Randy Kobes' cpan mirror repository. If anyone has problems with compiling/installing modules on windows, it'd be really appreciated if you could report the problem on rt.perl.org, and post a note on the Compatibility List of Perl Modules wiki page, so people know to chase it up. http://win32.perl.org/wiki/index.php?title=Compatibility_List_of_Perl_Modules Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forms and Plugins and Tutorials, oh my!!
On 18/08/06, Kevin Monceaux [EMAIL PROTECTED] wrote:
That would certainly work. But, imagine if a form plugin took care of the
dirty work for the developer. Let's pretend for a moment. Imagine, if you
will, that someone integrated the FCKEditor with HTML::Widget. One might be
able to create an FCKEditor textarea field by doing something like:
$w-element('FCKEditor', 'description' )-label('Description')-rows(20)-
columns(40);
There's work in this direction already with HTML::Widget::Dojo.
Work has currently stalled, partly because dojo seemed to be going
through a lot of changes, and partly because it's slipped down my
priority list.
Currently, HTML::Widget::Dojo provides elements for WYSIWYG textarea,
auto-complete text fields, and a popup date selector.
If you don't want to manually download the dojo library, it needs
Catalyst::Plugin::Dojo which currently uses HTML::Dojo, but will be
changed to use Alien::Dojo once that's merged with HTML::Dojo. - see
the previous discussion on this list, titled Alien-Dojo / HTML-Dojo
merger suggestions
If you're able to help at all with developing these, it'd be most welcome.
The first priority is probably rewriting Alien::Dojo, along the lines
mentioned in the Alien-Dojo / HTML-Dojo merger suggestions email.
The svn locations are:
http://oook.de/svn/trunk/HTML-Widget-Dojo/
http://dev.catalyst.perl.org/repos/Catalyst/trunk/Catalyst-Plugin-Dojo/
http://dev.catalyst.perl.org/repos/Catalyst/trunk/HTML-Dojo/
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forms and Plugins and Tutorials, oh my!!
On 18/08/06, Jonas Alves [EMAIL PROTECTED] wrote: On 18/08/06, Carl Franks [EMAIL PROTECTED] wrote: If you don't want to manually download the dojo library, it needs Catalyst::Plugin::Dojo which currently uses HTML::Dojo, but will be changed to use Alien::Dojo once that's merged with HTML::Dojo. - see the previous discussion on this list, titled Alien-Dojo / HTML-Dojo merger suggestions If you're able to help at all with developing these, it'd be most welcome. The first priority is probably rewriting Alien::Dojo, along the lines mentioned in the Alien-Dojo / HTML-Dojo merger suggestions email. Hi Carl, I would like to help developing these modules. Could you give some guidance in what needs to be done. I really need HTML::Widget::Dojo for the future versions of InstantCRUD. At the moment, there's only been 1 release of Alien::Dojo, and it's broken. The author is happy to hand over maintenance of it. The message mentioned above is here: http://lists.rawmode.org/pipermail/catalyst/2006-June/008222.html This is Yuval's resonse: http://lists.rawmode.org/pipermail/catalyst/2006-June/008225.html It seems a bit over-engineered to me, but Yuval is the man when it comes to design, so I bow to him. Unfortunately, I don't have the time to work on it - it's a minor issue for me, as it's so easy to manually download the dojo-ajax release from the website. As HTML-Widget-Dojo stands, I think the latest in subversion worked ok with dojo v0.3. Dojo v0.3.1 has since been released, so we need to check whether the widgets we use have had incompatable changes. I had posted a few bug reports - I'll need to search for them and see if they've been addressed. This thread also mentions a couple of issues that might still be outstanding. http://lists.rawmode.org/pipermail/html-widget/2006-May/thread.html#2 Feel free to ask anything else. Anything specific to HTML-Widget-Dojo should probably be on the H-W list though. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forms and Plugins and Tutorials, oh my!!
On 18/08/06, Kevin Monceaux [EMAIL PROTECTED] wrote: On Fri, Aug 18, 2006 at 01:48:06PM +0100, Carl Franks wrote: If you're able to help at all with developing these, it'd be most welcome. The first priority is probably rewriting Alien::Dojo, along the lines mentioned in the Alien-Dojo / HTML-Dojo merger suggestions email. Since I'm asking for such features I certainly should put my money where my mouth is. I'm willing to help in any way I can. Unfortunately at my current skill level I doubt I could be of much help. I'm very new to Catalyst. I tinkered with perl years ago but not a great deal. Catalyst has rekindled my interest in perl. So, what can someone with my limited skills do to help? All contributions will help! Working on HTML-Widget-Dojo might be suitable, and of immediate value to you. You'd just need a basic controller and template to try it out. Download the latest dojo and put it in your static directory http://download.dojotoolkit.org/release-0.3.1/dojo-0.3.1-ajax.zip Make sure your html has a script tag pointing to the library, for example script type=text/javascript src=/static/dojo/dojo.js/script If you're testing this through catalyst, you'll probably need to set static-simple to not ignore any extensions - make sure all the files in static/dojo/ can be served, including .html files. Then you can just try adding a widget to a page, with elements from H-W-Dojo. See if you come across any errors. Have a look through the dojo library to see if there's any other widgets you'd like to add to H-W-Dojo. You can get H-W-Dojo from here using subversion: http://oook.de/svn/trunk/HTML-Widget-Dojo/ Incidentally, I submitted a patch for C-P-Static-Simple that helped with serving the files, but it hasn't been applied. You might find it useful: http://lists.rawmode.org/pipermail/catalyst/2006-May/007266.html Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] automatic CRUD (was: how to get started?)
On 21/08/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: fireartist wrote: Many modules, particularly DBI / DBD::SQLite, include C code which needs to be compiled on the target machine. Ok, now I realize Catalyst isn't what I'm looking for. I need something more lightweight. I'm doing this for fun in my spare time and wanting something I can host on a cheap web hosting provider that only supports perl/CGI/PHP and MySQL but doesn't allow compiling and installing my own C software. Or if there's nothing that does what I want in perl or PHP, I could pop for a slightly more expensive hosting service that would support Python or Java or Ruby on Rails, but still not installing new C software. You can get even very cheap webhosting with SSH included - if you don't have SSH, then installing anything will be hard. In my experience, there's very few hosting packages that don't support C compilation. Just log in and type `which cc` or `which gcc` to check whether there's a C compiler. If there is, then it's very much harder to install XS perl modules, than it is pure-perl. Either way, you'll need to create your own library folder, and set CPAN.pm to install there. To make sure that any Module::Build based modules install properly, first use CPAN.pm to install ExtUtils::CBuilder, and everything should go smoothly. What I want should be simple: a utility written entirely in Perl or PHP that I'd run once to query the schema of an existing MySQL database, which would output a set of new scripts (also entirely in Perl or PHP) that would let a user perform basic web-based CRUD operations on the tables in the database, preferably using a nice, simple MVC design. Then I could customize those scripts as needed. Does such a utility exist? I think you'll find very few module's authors avoid XS modules - in which case it's up to you to check the dependencies. If you search cpan, there are sometimes pure-perl variants of modules, e.g. DBD::mysqlPP, DBD::PgPP I recently installed Fedora Core 5, and was pleasantly surprised that I just had to type sudo cpan cpan install ExtUtils::CBuilder cpan install Catalyst::Runtime cpan install Catalyst::Devel cpan install Task::Catalyst and everything installed with no problems. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: How to redirect before some code excute
On 26/10/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Fayland Lam [EMAIL PROTECTED] wrote:
Lee Standen wrote:
It's a subroutine, right?
Tried a return?such as:
$c-res-redirect('http://www.yahoo.com');
return undef;
Indeed I want to run the 'while' loop in backend. 'return' would not run
the loop I think.
Why do you want to run the loop in the background?
What purpose will it serve?
If we can learn your motivation, we can try to find you
At Least One Way To Do It.
It's not that unusual to want to send a response before doing
expensive operations, so that the user doesn't have to wait.
Does fork() play well with catalyst? (I've not yet had a need to try it myself)
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Where should constraints go
On 03/11/06, Ian Docherty [EMAIL PROTECTED] wrote: Carl Franks wrote: I made on very basic start [1] on being able to automatically create constraints from the database column types. At the moment it only supports mysql, and it's also probably very out-of-sync with the current svn trunk - but I'd /really/ like to see it finished, and I /really/ don't have any time to work on it, so if you want to take a look and do something with it, that'd be great. My primary goal was to get it working with HTML::Widget as H-W-Constraint-DBIC [2], but there's no reason it couldn't be integrated with any other validation package. [1] http://dev.catalyst.perl.org/repos/bast/branches/DBIx-Class/columns_info_for [2] http://dev.catalystframework.org/repos/Catalyst/trunk/HTML-Widget-Constraint-DBIC/ Carl Carl Creating the constraints is not really the problem. Your approach certainly helps and one that any ORM should include. I can see that it would take a fair amount of work to cover all bases. Putting these sort of constraints is the duty of either the database level (where they naturally go anyway) or perhaps in the business logic layer. My problem is finding a clean way of getting these constraints out of the Model and into the View so that I can generate meaningful error messages without hard-coding them in the templates. By 'clean' I mean not having to code the Controller to act as the middle-man and just pass them from the Model to the View. The purpose of the columns_info_for branch code is to mark columns with such flags as 'data_type', 'size', 'length_in_bytes', or for integers... 'is_unsigned', 'range_min', 'range_max' Then you just need to tell the validation/form package which DBIC column corresponds to the CGI parameter, and the validation/form package should be smart enough to check the input against the flags set, and set an appropriate error message if it fails. So if your 'username' column is varchar(16), DBIC would mark it data_type = 'varchar', size = 16, and if the input is longer than that, then the validation package can set the message must be no longer than 16 characters. The HTML::Widget equivalent would be: $w-constraint( String = 'username' ); $w-constraint( Length = 'username' )-max( 16 )-message( 'must be...' ); If your 'age' column is the mysql column unsigned tinyint, then DBIC would mark it data_type = 'tinyint', is_unsigned = 1, range_min = 0, range_max = 256. Again, the validation package can set appropriate error messages if the input doesn't match those specs. The HTML::Widget equivalent would be: $w-constraint( Integer = 'username' )-message( 'must be an integer' ); $w-constraint( Range = 'username' )-min( 0 )-max( 256 )-message( '...' ); Which should be entirely possible to automate. For example, if a constraint was put on a DATE field such that it could not be later than NOW and no earlier than NOW - 20 Days. (for example). I don't get your example. Is this 'constraint' something that's defined in the database as a Stored Procedure or Function? If so, then no, I don't see any way of automatically getting that specification into the View, unless you use a database that lets you use native perl-code functions, and you can use the exact same code in the View, and you use some sort of mechanism to ensure that the database function stays in sync with the View. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst vs Rails vs Django Cook off
On 16/11/06, Christopher H. Laco [EMAIL PROTECTED] wrote: Carl Franks wrote: On 16/11/06, Cory Watson [EMAIL PROTECTED] wrote: On 11/16/06, Carl Franks [EMAIL PROTECTED] wrote: On 16/11/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Essentially, according to his test, which doesn't take into account ORM performance, Rails Django knock the socks of Catalyst. snip The first thing I noticed was that the content length of the document served by catalyst was longer than that served by rails. He doesn't seem to have tried very hard to test apples for apples (his words) Also see the very good comment by JayK as to why it's not a very good real-world test at all. http://letsgetdugg.com/view/Catalyst_vs_Rails_vs_Django_Cook_off I'm not saying Catalyst's performance couldn't be improved, or that it's not slower than Rails - just that a bad benchmark is worthless. I agree with all your points Carl. I have not been present in teh IRC for a few days to see any discussions related to this thread. I'm (me either) sure some optimizations were discussed and some things will be implemented because of it. So with the precondition that I haven't kept up with the state of affairs I'd like to thank victori for spending his time and effort to create _something_. It's more than his naysayers have to done to show us how fast Catalyst is. I respectfully suggest that those who criticize his work should use their energies to /improve/ his test rather than merely dismissing it as worthless. Using his code as a base, couldn't one create a test that was more fair? Then someone would have a test that shows results that are more 'real' and give potential users more information with which to make a decision. From the off-list discussion I've already had, I know my use of the word 'worthless' will haunt me ;) If a benchmark reveals something in the framework core which could be optimised, then that's great. If it helps teach more effective idioms, or highlights something that shouldn't be used, then that's great. But other than that, I don't think any application benchmark will have much worth other than for that specific application. If I wanted to serve static pages (as the benchmark did), I wouldn't use a framework and then pipe them through TT. The reason I use a framework, is because I want to write a big application with lots of pages, and have things like sessions, ORM, templates. I don't see /how/ the benchmark can be improved. Once you start getting into something that complicated, all you're testing is the way 1 person writes the application in perl compared to how they write it in ruby. Someone else might use a different session storage-backend, which would have different results, and your 'fastest' framework now isn't. Catalyst doesn't have to be the fastest in such a test. That's probably never been the One True Goal of the core devs. But providing people with information as to why Catalyst is good (or bad) should be high on the list. Carl /me puts on flame suit. I agree overall. However... I think the fact still remains that new end users will see three frameworks [all of which were destined for serving more than static pages] where 2 of them serve the static content fast, and one doesn't [Catalyst]. Regardless of whether the test is 'real world', and regardless of whether the frameworks 'were meant to serve more complicated things', Catalyst is slower in this instance. All things being unequal, if I tell my boss we have 3 frameworks to choose from, and one is flexible, and the others are fast, he's going to choose fast every time...even knowing the testing may be faulty. Yes, I know better. He probably does too. But that's how the world works. I always fall on the side of the non majority it seems, and this is another example. [The list, not you specifically] Stop being defensive that the test is bogus. It's not. I agree with everything up to here. It shows that in one circumstance, Catalyst is sadly slow. Let's fix that. Matt has just pointed out that Cat's optimised for large applications with lots of paths, and for flexible programming. Only fix it if that doesn't compromise this, which is more important than looking good in one flawed benchmark. Explaining why the test may be invalid, or why it's bunk still won't change that fact that in this circumstance, it sucks. Catalyst sucks because it doesn't come with a pony, so let's hope the next benchmark to hit the web doesn't benchmark against that ;) /me removes suit and goes back to writing tests Um, shouldn't you leave the suit on until you've received the replies? I hope it wasn't needed anyway Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] HTML::Widget and Unicode
On 26/11/06, Alejandro Imass [EMAIL PROTECTED] wrote: Hi, HTML::Widget is translating my UTF-8 characters into presumably ISO LATIN-1. Can I stop HTML::Widget from doing this? I looked into enctype but I don't think is for that, and if it is could someone kindly offer an example? if so (supposing that enctyle is the answer) what happens to filenames that use Unicode characters in an upload field? Can you give an example of what's actually happening and when? If you're talking about the output of $result-as_xml, the characters are being HTML-encoded. Upgrade to the latest cpan release of HTML::Element to fix it. If that's not the problem, can you post more details to the HTML::Widget mailing list: http://lists.rawmode.org/cgi-bin/mailman/listinfo/html-widget Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How to use HTML::Widget::Constraint::Date
On 27/11/06, Andrew Peebles [EMAIL PROTECTED] wrote: Michele Beltrame wrote: Hello Alejandro! I decided to create my own class in my controller namespace but I think it can be contributed to HTML::Widget::Constraint namespace if anyone here has acces to that. I have several constraints as well which I think might be useful, so I was interested in creating and CPANning a distribution maybe named HTML::Widget::MoreConstraints which would collect them all. However, I still have to do that as, chatting with Carl and (especially) with mst, it seems that we'll be moving away from HTML::Widget soon enough... So, I'm waiting some days by the window to see what to do. ;-) If you are interested in getting this done, however, please let me know. Michele. What is the up-n-coming alternative to HTML::Widget? reaction ;) Well, maybe longer term, yes. But for now, a replacement is in active development. See the html-widget mailing list for discussion, and lets move any further discussion over there. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Browser window/tab independent sessions
On 08/01/07, Octavian Rasnita [EMAIL PROTECTED] wrote: Well, it seems that Internet Explorer doesn't work that way. Here are the steps: I have opened a window with the main page of the site. No cookie file was created. I have logged on. No cookie file was created, even though it was sent, and the login was successful. I have opened another window with the same main URL. It asked again for the username and the password, so the session was not available to the second window. I have logged on using another username. No session file was created but the login was successful this time also. To see better what's happening, try using a browser plugin that will let you view current cookies, or use javascript to display the current cookies. IE might not be creating the actual cookie file immediately on each page view. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] HTML to plain text conversion
On 08/01/07, Xavier Robin [EMAIL PROTECTED] wrote: Hello, Do you know a (catalyst plugin|perl module|external tool) that converts HTML to plain text? I mean, keeping some formatting (especially lists and links...), not just stripping HTML tags... I tried Template::Plugin::HtmlToText that fits well into TT, but the links are lost. Lists are well rendered, though. Something like this should work: my $scrubber = HTML::Scrubber-new( allow = [qw/ a ul ol li /] ); my $text = $scrubber-scrub( $html ); Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Browser window/tab independent sessions
On 08/01/07, Perrin Harkins [EMAIL PROTECTED] wrote: On Mon, 2007-01-08 at 23:34 +0200, Octavian Rasnita wrote: And I think this is what is wanted, because I can't see other needs for having 2 separate sessions on the same computer. Go back and read the original post again. The problem is with storing non-global information, like the current search term, in global storage, i.e. a cookie or something tied to a session ID in a cookie. If you try opening multiple windows on amazon.com, with separate searches in each, they will not interfere with each other. You can page through each separately, and your search terms are maintained. This is true regardless of how you opened the window. That's what this person is trying to achieve. Can you describe how to replicate this behaviour? I opened the amazon.com link in a new window. I right-clicked the homepage graphic, and selected open in new window. In the first window I did a couple of searches and viewed a couple of books. In the second window I did a couple of different searches and viewed a couple of different books. I couldn't see any search history (I wasn't logged in; does that matter?). When I clicked the View edit your browsing history link in each window, they both displayed all the books I had viewed in /both/ windows - which as far as I understand, isn't the desired behaviour. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] creating binaries
On 17/01/07, Joe Landman [EMAIL PROTECTED] wrote: That is unless you have your in-memory image also encrypted with on the fly decryption/execution. I am not aware of any one doing this for any language. Though I could be wrong. I've heard of this being used in pc/console games, but even this can still be cracked, as it has to be unencrypted at some point during runtime. ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Hair-pulling over YAML config
On 29/01/07, Carl Vincent [EMAIL PROTECTED] wrote: Hi everyone, I've just spent an inordinate amount of time debugging a problem which was actually caused by my Yaml config file not parsing properly. Catalyst isn't helping much - all it does is skip out the line of debug that says [debug] Loaded Config ... and that's easy to overlook. I discovered that when the file is loaded in Config::Any, if there's an error with the parsing it just skips it and doesn't bother to alert anyone. Is there a smart way to test for your config file failing to parse? I've patched my Config::Any (attached below) so it throws a warning. Not sure if this would cause problems if it was included in the distributed module... I've had the same troubles today too! How about a Test::YAML, in the same vein as Test::Pod, providing a all_yaml_files_ok() rountine which accepts a list of files or directories to check? Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FormBuilder question
On 29/01/07, Marc Logghe [EMAIL PROTECTED] wrote:
Hi all,
I am lost.
In my conf I have:
# configuration of FormBuilder
Controller::FormBuilder:
method_name: form
template_type: Mason
stash_name: form
obj_name: fb
form_suffix: fb
attr_name: Form
form_path: __path_to(forms)__
In the mason template:
% $form-render %
%args
$form = undef
/%args
The error I get:
Couldn't render component /moe/mol_3D_conv_form - error was Can't call
method render on an undefined value ...
I was convinced that C::C::FormBuilder automagically sets
$c-stash-{stash_name}, but it seems not to be the case (btw: calling
$c-stash-{form} gives the same error).
Do you have to assign your fb object manually in the controller ? And if so,
what is the purpose of the 'stash_name' conf setting ??
I am afraid I am missing something teriibly.
I was just looking at this last week, as I was using the code as a
basis for a new controller. I suspect that it's never been tested,
because as far as I can tell, it incorrectly reads the config from the
controller object, rather than the application object.
in sub new,
$self-__setup();
should be
$self-__setup($c);
and in sub __setup,
my $self = shift;
my $config = $self-config-{'Controller::FormBuilder'} || {};
should be:
my ( $self, $c ) = @_;
my $config = $c-config-{'Controller::FormBuilder'} || {};
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] C::C::FormBuilder question
On 30/01/07, Matt S Trout [EMAIL PROTECTED] wrote:
On 30 Jan 2007, at 08:48, Carl Franks wrote:
I was just looking at this last week, as I was using the code as a
basis for a new controller. I suspect that it's never been tested,
because as far as I can tell, it incorrectly reads the config from the
controller object, rather than the application object.
That's what it's supposed to do! This is a feature, not a bug - and
the fact that all the plugin-style ones (HW, DFV etc.) use global
config if frankly a bug in *them* since it makes code re-use much
harder.
If you need common defaults, use a controller base class. Works
beautifully.
ok, that's cool.
I still tend to keep all config in a single external config file, so I
hadn't come across that.
Would best practise then be something like this?...
my $config = $self-config-{'Controller::MyApp'}
|| $c-config-{'Controller::MyApp'}
|| {};
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Using C::C::FormBuilder With DBIC
On 18/02/07, RA Jones [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
Hi Everyone,
I have been experimenting with Catalyst::Controller::FormBuilder. I'm
trying to provide an edit form for objects read from and written to the
DB via DBIx::Class. Have FormBuilder automatically load the data from
DBIC into the form seems pretty easy with something like:
my $widget = $c-model('MyAppDB::Widget')-find($id);
my $form = $self-formbuilder;
$form-values($widget-get_columns);
However, an elegant way of writing the data back out is not jumping out
at me. I know I could manually copy each field out of the $form object
to my $widget object, but it seems like there should be simple way to do
it all in one line like I got with the
$form-values($widget-get_columns); above.
Any suggestions? What are other folks doing for C::C::FormBuilder and DBIC?
I'm pretty new to this, but this is what I did:
sub edit : Local Form {
# get data into form pretty much as above, then:
if ( $form-submitted $form-validate ) {
$c-stash-{user} = $user;
$c-forward('do_edit');
}
sub do_edit : Private {
my ($self, $c) = @_;
my $form = $self-formbuilder;
my $fields = $form-field;
$c-stash-{user}-update($fields);
$c-flash-{status_msg} = 'User updated';
$c-response-redirect( $c-req-base . 'users/view/' .
$c-stash-{user}-id );
}
Not sure if it's the 'best' way, but it works. Will be interesting to
see what other suggestions you get.
It might be worth looking at the code for DBIx::Class::HTMLWidget for some ideas
http://search.cpan.org/src/ANDREMAR/DBIx-Class-HTMLWidget-0.09/lib/DBIx/Class/HTMLWidget.pm
When you're populating the form from the database, would your
$form-values($widget-get_columns);
correctly set select menus?
Also, (for all browsers that I'm aware of) no value is sent back to
the server for unchecked radioboxes - so it'd be worth checking
whether the $fb-field solution handles this properly.
(I don't know, as I've only read the formbuilder docs, I've never used it).
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] L10N + FormBuilder/HTMLWidget
Chris,
On 19/02/07, Christopher H. Laco [EMAIL PROTECTED] wrote:
Is anyone doing complete localization using FormBuilder or HTML::Widget?
I'm stuggling with probably the same things everyone struggles with when
it comes to forms.
FormBuilder is nice when it comes to localizing the messages via
messages.$lang. It totally sucks when it comes to localizing the form
labels themselves. It looks like I either have to manually loop through
teh fields and localize the labels, or use a different .frm config for
each language...which means duplicating major parts of the config.
HTML::Widget seems to be even worse at getting its config from an
external source rather than creating forms in code.
What is the sanest way people have found to do localization without
having to do it in 2-3 different places (code to alter labels,
messages.$lang, etc)?
It seems that forms suck, and form tools really haven't quite gotten
over the hurdle yet in situations like this.
I haven't yet publicised this anywhere than the html-widget list, but
I've been working on a html-widget replacement, named HTML::FormFu.
The main reason I've been quiet is mainly because, of the little
documentation there is, some is now incorrect and most still refers to
html-widget. - So consider the code and test suite the primary
documentation for now.
I've just added L10N to it, using Locale::Maketext, but you can
provide your own L10N object or class if you wish.
At the moment, it only has an en.pm locale file.
To localise labels, comments etc, I would suggest using the same
technique as you would to localise anything else:
$field-label( $c-loc('name') );
instead of:
$field-label('name');
To organise the L10N texts, you could either let formfu localise error
messages, etc from it's own locale files and set your own labels using
`$c-loc`.
Or you could merge the contents of formfu's own locale files into your
own, then tell formfu to use Cat's own localize() method. (assuming
you're using the Catalyst-Plugin-I18N).
The catalyst controller has an option for handling this automatically
`localize_from_context`.
If you want formfu to use it's own L10N files, you can set the
controller option `localize_from_context` to tell it to get the
language from `$c-languages`.
The formfu code should be considered alpha, as it's still changing to
an extent, but it is working and I'm using it in a few different
projects and enjoying using it.
The code is in svn at:
http://html-formfu.googlecode.com/svn/trunk/
The Cat controller / actions
http://catalyst-controller-html-formfu.googlecode.com/svn/trunk/
DBIx::Class integration (replacement for DBIx::Class::HTMLWidget)
http://dbix-class-formfu.googlecode.com/svn/
A couple of extra form elements which use the Dojo library:
http://html-formfu-dojo.googlecode.com/svn/trunk/
There's also an application which lets you test different css
stylesheets again forms, to quickly prototype different layouts:
http://www.fireartist.com/html-formfu-cssapp/
In a very quick summary, I would describe it's main advantages over
html-widget as being:
* uses TT templates, so you can easily change the rendered xhtml on a
per-project basis
* set $field-filename() to override the rendering on a per-field basis
* the old result objects are broken out into seperate result + render
object to allow a backend other than TT to be used
* more seperation of form fields and other non-field 'elements', such
as fieldsets
* load form settings / elements / constraints / filters from config
files, allowing easy setting of global defaults, and allows forms to
be changed without touching code
* cleaner xhtml, more customisable dom id generation, cleaner css classnames
* can set element default values, form-wide, for individual field types, e.g.
$form-element_defaults({ Textarea = { cols = 20 }, Text = {
size = 20 } });
will automatically pass these defaults when the relevant element type
is created.
And of course, these can be set via a config file.
...well, that's all I can think of off-hand
If you're interested in experimenting with it, you're welcome to ask
questions on the html-widget list.
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Performance
On 09/03/07, Nilson Santos Figueiredo Junior [EMAIL PROTECTED] wrote: On 3/8/07, Jim Spath [EMAIL PROTECTED] wrote: URI is next up at around 14% of time. Is there anything that can be done about this one? Wherever is reasonably possible, instead of actually using calls to $c-uri_for() for every item, call it only once and then build the rest of the URI manually. By making this kind of changes throughout an entire Catalyst application I've been able to get 15-20% better performance. This has been really bugging me, but I haven't had the time to look into it further. A URI object is a blessed string. A blessed uri-escaped string! So any method that changes a uri, or extracts info from it must be having to parse the string each time. And I'm sure there must be a lot unescaping/escaping going on. The only thing that's optimised for is printing! I'm sure it the uri components were kept in a blessed hash, and not combined and escaped until necessary, it would make a difference. Does anyone have the spare time to consider refactoring URI? Please? Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] assigning vars to $c-stash
On 12/03/07, Octavian Rasnita [EMAIL PROTECTED] wrote:
I have a $hash hash reference and I want to add all its elements to the
stash. How can I do this? Do I need to use a loop and assign each element
one by one?
I have seen that it is not possible to use $c-stash = $hash;
%{ $c-stash } = ( %{ $c-stash }, %$hash );
would also work, which combines both hashes.
This is very much a perl references problem - not something cat-specific.
See `perldoc perlref` for more info.
Cheers,
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Help needed with Unicode
On 20/03/07, Mario Minati [EMAIL PROTECTED] wrote: - text with german umlauts from lexicon style pm files is currupted, it is Does your .pm file have use utf8; ? It's necessary for when you have UTF-8 in perl source files. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] html escaping question
On 21/03/07, Mario Minati [EMAIL PROTECTED] wrote:
Am Mittwoch 21 März 2007 12:42 schrieb Carl Franks:
In which case you may be double-escaping.
But how can I circumvent this. Actually it's not a clever question.
Is it usefull to circumvent that.
My current problem:
As the part of my project I am working on at moment deals with companies I
have to deal with GmbH Co. KG which is a quite popular type of company in
Germany.
If a users types that in a form field everything is fine until it comes to
editing. The string is escaped - of course. But the user is confused when he
sees GmbH amp; Co. KG.
Find out which part of your app is double-escaping, and stop it.
If your template has just [% form %] there shouldn't be any problem.
By default, a field with:
default_value('GmbH Co')
will render as:
value=Gmbh amp; Co
the user will see the value as:
GmbH Co
and when it's submitted, the server will see:
GmbH Co
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 22/03/07, Alejandro Imass [EMAIL PROTECTED] wrote: Hello, I wrote a complete backend in HTML::Widget a couple of months ago, and now I'm adding new functionallity to another part of the site. The question is: a - Stick with HTML::Widget and wait for FormFu ? b - use C::C::FormBuilder ? If you're just adding new functionality to the site, but not necessarily needing new features - I would suggest sticking with HTML-Widget, so it's at least consistent throughout the site. I'm currently using FormFu extensively in several projects, and am really happy with how simple it is to use, but also how extensible and powerful it is. As I've already said though, anything in it is still subject to change at this point - but once there's been a cpan release every effort will be made to maintain backward compatability. I see it being several weeks at the very least before a cpan release. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 22/03/07, Doran L. Barton [EMAIL PROTECTED] wrote: I am currently developing my first app using C:C:FormBuilder too, having done previous Catalyst projects with HTML::Widget. I think FormBuilder may become the de facto way to develop Catalyst apps in the future, especially seeing there is a DBIx::Class::FormBuilder module on the horizon that will marry FormBuilder to DBIx::Class like DBIx::Class::HTMLWidget does for HTML::Widget. Well, if mts has anything to say about it, it'll be Reaction that becomes the Cat de-facto ;) Have I missed something? What's FormFu? Discussion of FormFu has generally been limited to the html-widget mailing list so far. FormFu is similar to html-widget, but tries to get everything right this time ;) It's main selling points are: * You can define your forms using external config files (using any format supported by Config::Any) * Instead of having a simple idea of 'constraint' - it has several stages that can process each form field. Filters - Constraints - Inflators - Validators - Transformers. Filters are intended to do basic cleanup of data input, such as removing trailing whitespace, or removing spaces in a creditcard number. Constraints are low-level data validation, such as, is this an integer, is this in bounds, etc. Inflators are similar to DBIC's - they expand the input into an object of some sort, so there's one which creates a DateTime object, and there's one which turns a file upload into an Imager object. Validators are for 'business logic' - more complex validation, possibly relating multiple fields, which will usually require a custom class created for each check. The only validator written as of yet is Imager::Size which checks a picture's pixel size is within bounds. And Transformers are to manipulate the (possible inflated) input data before using it. The ony transformer written so far is Imager, to edit Imager objects (scale, crop, etc). There are also Deflators, so you can pass $field-default($value) an object and make sure its value is printed properly. * Instead of using HTML::Element to generate the xhtml, it uses TT templates. Every project will have it's own copy of the template files, so you can customise them if you wish. * It's gotten rid of html-widget's seperate $result object - simplifying usage greatly. * Integration with Catalst and DBIx::Class See `svn log` for more - there's lot's there! The code is currently available from: http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/DBIx-Class-FormFu/ http://html-formfu.googlecode.com/svn/trunk/Catalyst-Controller-HTML-FormFu/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Dojo/ http://html-formfu.googlecode.com/svn/trunk/HTML-FormFu-Imager/ I've started adding some TODO's to the issue tracker: http://code.google.com/p/html-formfu/issues/list What would be most helpful though for anyone wishing to help, would be documentation, as what's there is quite out-of-date. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Form Module Dichotomy
On 23/03/07, Alejandro Imass [EMAIL PROTECTED] wrote: From the comments, my conclusion is that if you already developed with HTML::Widget it would probably be better to stick with it and wait for FormFu (or use FormFu from svn), because it's more backward compatible with legacy HTML::Widget code. One last thing to keep in mind is though FormFu looks similar to html-widget, it isn't backwards compatible and html-widget code would definitely need syntax changes. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] $c-detach and $c-action
On 01/02/07, Matt S Trout [EMAIL PROTECTED] wrote: On 1 Feb 2007, at 02:05, Michael Reece wrote: is there something like detach that will also set the current 'action' to the one being detached to? Not until 5.80 but there's no reason you can't simply set $c-action - it -is- an accessor. I don't see this implemented in current yet. I've had a go, but don't understand the dispatcher well enough. If someone could give some pointers as to what it'll entail, I'd be willing to spend some time and have another go at implementing it. Also - is the plan that forward() and detach() will do this by default, or will there be a new method to get this effect? Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Forms: Chapter 1647
On 24/05/07, Christopher H. Laco [EMAIL PROTECTED] wrote:
One of the never ending topics for Catalyst seems to be forms: how to
build them, validate them, localize them and generally just live with
them without hating the toolset or wanting to strangle someone.
I don't have a solution for everyone, but I did create a solution for
me. I offer it here as yet another piece of the puzzle for those in need
of another path. Feel free to steal the code as you see fit.
In general, I like FormBuilder for building forms, but I hate its
validation. I like FormValidator::Simples ability to accept yaml profile
configs (ProfileManager::YAML). I hate that it can't also take messages
from yaml, or both in the same shot. And most of all, I hate having to
have at least 3 configs: FB, Profile, Messages) and nothing localizing
everything in the same way. This is a marriage of all three.
The config file format is simple. The root data is FB options. The
fields collection holds FB field config and constraints (FVS options)
and messages (FVS messages)
---
name: form_name
method: POST
javascript: 0
stylesheet: 1
sticky: 1
submit: LABEL_CREATE
fields:
- sku:
type: text
size: 25
maxlength: 25
constraints:
- NOT_BLANK
- LENGTH, 1, 25
- UNIQUE
messages:
- NOT_BLANK: sku may not be blank
- name:
type: text
size: 25
maxlength: 25
constraints:
- NOT_BLANK
- LENGTH, 1, 25
If you don't specify a message for a constraint, it defaults to
FIELDNAME_CONSTRAINT. If you don't label a field, it defaults to
LABEL_FIELDNAME. In my case, I use those as keys to a %Lexicon in a I18N
module...they could just as well be real names/messages.
If you won't want to use yaml, you can just pass the same data structure
to parse/new
{
name = 'form_name',
method = 'POST'
fields = [
sku = {
type = 'text',
constraints = [
'NOT_BLANK',
'LENGTH, 1, 25'
]
}
]
}
When the form is validated/rendered, the labels and messages are all
passed to an I18N sub you specify for localization...
The api mostly mimics FB usage:
my $form = Mango::Form-new({
source = 'path/to/some/config.yml',
values = $object-get_columns,
localizer = sub {MyI18N-localize(@_)},
params = $c-request
});
$form-field(name = 'someselect', options = [EMAIL PROTECTED]);
$form-render;
if ($form-submitted) {
my $results = $form-validate;
if (!$results-success) {
print @{$results-errors};
};
};
The code isn't the greatest under the covers and does some evil , but it
works for me and at least separated my form handling from my controllers
with an API.
You can steal the form code from here:
http://svn.mangoframework.com/CPAN/Mango/trunk/lib/Mango/Form.pm
Here's a real config:
http://svn.mangoframework.com/CPAN/Mango/trunk/share/forms/admin/products/create.yml
It'll change. It'll evolve. It works for me, for now. Have fun with it
if you need it, or parts of it. :-)
The syntax, the usage, the I18N, it all seems strangely familiar...
http://html-formfu.googlecode.com/svn/
;)
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] OT: Re: Catalyst hosting: the wiki page
On 12/08/07, Francesc Romà i Frigolé [EMAIL PROTECTED] wrote: Catalyst application with DBIx::Class and TT which uses 5.2MB of space but the .cpan directory uses 37M more. btw, once you've installed everything, you can delete the contents of the .cpan directory (except the CPAN directory, which contains your config settings). Likewise, you can delete the contents of any .cpanplus directory, except the lib directory. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Catalyst Unicode woes ...
On 13/08/07, Tatsuhiko Miyagawa [EMAIL PROTECTED] wrote: Try $YAML::Syck::ImplicitUnicode = 1? Thanks, that solved the problem. From reading the docs, I had thought that option did the opposite of what I was wanting, but then obviously I still have a lot to learn about unicode ;) Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] improving usability / doc
On 17/08/07, Jonathan Rockway [EMAIL PROTECTED] wrote: Sucks is somewhat hurtful to the many contributers... ... (search.cpan.org's navigation sucks). hmm? ;) ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] About output in a browser
On 28/08/2007, lanas [EMAIL PROTECTED] wrote:
Hi folks,
In understanding how Catalyst work and how to work with , I'm making
very simple stuff, like having a model that only returns a directory
listing. I found something curious before starting to make a view.
Every line of the directory listing, obtained with 'ls -l', will be
chomped if I do not put a print String ! just before it in the
model, like this:
prints chomped lines, which results in unstructured output in the
browser:
MyApp01/lib/MyApp01/Model/MyApp01Model.pm
sub getFiles()
{
my ( $self, $c ) = @_;
@{$c-stash-{files}} = `ls -l /home/user/`;
}
prints neatly, every line of the directory listing on a separate line
in the browser:
sub getFiles()
{
my ( $self, $c ) = @_;
print getFiles() !;
@{$c-stash-{files}} = `ls -l /home/frodo/`;
}
'getFiles()!' will also get printed in the browser, but I presume this
is OK.
The output is in the following. There are no view defined at the
moment.
MyApp01/lib/MyApp01/Controller/Root.pm
sub end : ActionClass('RenderView')
{
my ( $self, $c ) = @_;
if (defined $c-stash-{files}) {
$c-response-body( @{$c-stash-{files}} )
}
else {
$c-response-body(NO DATA !);
}
}
Can someone tell me why the output of the directory listing is not the
same due to, apparently, the poresence of a print statement ?
Are you setting this anywhere...?
$c-res-content_type('text/plain');
If not, I think if you view the page source in the browser, you'll see
that the linebreaks are there - but the browser is ignoring them
because it's treating it as HTML.
If you change your output line to:
$c-response-body( join br, @{$c-stash-{files}} )
then I think you'll find it looks as you expect.
(Not that I'm recommending this as a solution - I definitely recommend
using a templating View for most common uses).
If you run the scripts/myapp_test.pl file from a command line, you
can easily see the exact output that would be sent to your browser.
Carl
___
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Re: uri_for() not working under lighttpd fastcgi
I discovered that if instead of hitting: http://my-domain/amazon I hit: http://my-domain/amazon/ ... then uri_for() started working as expected. I added a rewrite rule to my lighttpd config: url.rewrite = ( ^/amazon$ = /amazon/ ) and everything is now working again. I don't know if this is the best solution though. Cheers, Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Catalyst-View-TT-Alloy v0.00001
I've uploaded a new module to cpan - Catalyst-View-TT-Alloy. It's essentially a copy of Cat-View-TT (attributed!), but uses Template::Alloy instead of Template. It only provides the TT emulation interface - not all the other interfaces that Template::Alloy provides. Hope someone else might find it useful too. Carl ___ List: Catalyst@lists.rawmode.org Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/ Dev site: http://dev.catalyst.perl.org/
