From nicg@noslogan.org Wed Sep 1 09:17:59 2004 From: nicg@noslogan.org (Nic Gibson) Date: Wed, 1 Sep 2004 09:17:59 +0100 Subject: [Maypole] Using custom TT filters/plugins from Maypole? In-Reply-To: <20040831201040.GA17290@panix.com> References: <20040831201040.GA17290@panix.com> Message-ID: <20040901081758.GC72059@blue.amorality.net> On Tue, Aug 31, 2004 at 04:10:40PM -0400, Jesse Sheidlower wrote: > > Perhaps this is entirely a Template Toolkit question. > > I'd like to use custom filters and/or plugins from within > a Maypole application. However, there's no way to specify > these in Maypole::View::TT. > > Is there another way to declare these such that Maypole can > find them? Or would it make sense to extend Maypole::View::TT > so that the Template->new call will look for filters/plugins > in a Maypole configuration file? Or is there some other way > of doing this? > > Thanks. > > Jesse Sheidlower I did this by writing a replacement for Maypole::View::TT. I needed to pass custom configuration data and needed to add a filter. I can give you my code but it's really very trivial. I'm in the process of seeing if I can write something a little more sophisticated in that I want to see if I can write a new version of Template::Provider that uses the Maypole::View::Base->paths method to work out the include path on the fly - this would allow me to keep a single Template object in memory for the life of an Apache child process (this would obviously be in the context of Apache::MVC). There are definite performance benefits available there. In fact, the original rewrite of the Maypole::View::TT object was to support a compiled template cache. Anyone interested if I get this working? nic -- they were brought up on strange propaganda they have been trained to hate and destroy From sri@oook.de Wed Sep 1 11:16:39 2004 From: sri@oook.de (Sebastian Riedel) Date: Wed, 01 Sep 2004 12:16:39 +0200 Subject: [Maypole] Should additional_data() and authenticate() get called for plain templates? Message-ID: <4135A187.8060603@oook.de> Hi, In the current version of Maypole the only way to have session handling for plain templates (like the frontpage) is overloading parse_path(), which IMHO is horrible illogical. Here is a patch that changes that. http://files.oook.de/patches/Maypole.patch I sent this patch to Simon but he is not sure if he wants it... So please tell him that authentication and additional_data handling for plain templates makes sense. :) Cheers, Sebastian From veljko.vidovic@canadair.ca Fri Sep 3 15:32:32 2004 From: veljko.vidovic@canadair.ca (Veljko Vidovic) Date: Fri, 3 Sep 2004 10:32:32 -0400 Subject: [Maypole] Paged search results: first steps Message-ID: <001d01c491c2$d972f850$1d1213ac@dyn.cit.canadair.ca> Hi, all Was there any progress on getting pager working properly with search? Problem was that links created are generated for full result set and not searched results. Regards, Veljko From sri@oook.de Sat Sep 4 01:24:55 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 04 Sep 2004 02:24:55 +0200 Subject: [Maypole] Paged search results: first steps In-Reply-To: <001d01c491c2$d972f850$1d1213ac@dyn.cit.canadair.ca> References: <001d01c491c2$d972f850$1d1213ac@dyn.cit.canadair.ca> Message-ID: <41390B57.6030407@oook.de> Veljko Vidovic schrieb: >Hi, all > >Was there any progress on getting pager working properly >with search? >Problem was that links created are generated for full result >set and not searched results. > > Well, it's not that simple, main problem is that Maypole handles POST and GET data different. ($r->query, $r->{params}) So you can't just modify the template, unless you want forms instead of links... These two patches should make it work: This one is for Maypole::Model::CDBI. (again something I think Simon won't accept) http://files.oook.de/patches/Maypole-Model-CDBI.patch This one is for the pager template, it's a bit messy but works fine. http://files.oook.de/patches/pager.patch P.S.: Hope Simon will spend some more time for Maypole or finds a good Maintainer to do it, there are so many patches flying around but nothing happens. :( >Regards, >Veljko > > >_______________________________________________ >maypole mailing list >maypole@lists.netthink.co.uk >http://lists.netthink.co.uk/listinfo/maypole > > > Cheers, Sebastian From sri@oook.de Sat Sep 4 15:25:18 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 04 Sep 2004 16:25:18 +0200 Subject: [Maypole] Paged search results: first steps In-Reply-To: <41390B57.6030407@oook.de> References: <001d01c491c2$d972f850$1d1213ac@dyn.cit.canadair.ca> <41390B57.6030407@oook.de> Message-ID: <4139D04E.4060109@oook.de> > These two patches should make it work: > > This one is for Maypole::Model::CDBI. (again something I think Simon > won't accept) > http://files.oook.de/patches/Maypole-Model-CDBI.patch > > This one is for the pager template, it's a bit messy but works fine. > http://files.oook.de/patches/pager.patch Like I expected, Simon didn't liked the patches, so a new one is on the maypole-dev list. Cheers, Sebastian From sri@oook.de Sat Sep 4 20:36:56 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 04 Sep 2004 21:36:56 +0200 Subject: [Maypole] Todo Message-ID: <413A1958.3000009@oook.de> Hi, As of today I am the new maintainer of Maypole. First I would like to thank Simon for his great work and wish him good luck for his missionary future! (btw. do we have to call you Father Simon then? ;) These are some things I would like to see in the near future, post any additions or complains right here. Todo: * fix all open bugs (pager and search results, pager and list order...more?) * put POST and GET data in $r->{params} and deprecate $r->query * call additional_data() and authenticate() for plain templates * make the templates valid XHTML * better documentation and more complex examples Patches are very welcome! Cheers, Sebastian From nicg@noslogan.org Sun Sep 5 12:44:35 2004 From: nicg@noslogan.org (Nic Gibson) Date: Sun, 5 Sep 2004 12:44:35 +0100 Subject: [Maypole] Todo In-Reply-To: <413A1958.3000009@oook.de> References: <413A1958.3000009@oook.de> Message-ID: Congratulations Sebastian :) I've got quite a few bits and pieces that I will take a good long look at - some of them may be useful patches. I also have a couple of suggestions that I'll mail to the developer list - they are mostly to do with breaking up some of the existing code into smaller chunks to make inheritance easier. I don't have a great deal of time at the moment but I'll try to get you a couple of patches within a couple of weeks (for some reason selling house + buying house + 1 month old son + finally getting divorced from ex so I can marry my partner + full time job + part time job seems to be filling my days, dunno why). On 4 Sep 2004, at 20:36, Sebastian Riedel wrote: > Hi, > > As of today I am the new maintainer of Maypole. > > First I would like to thank Simon for his great work and wish him good > luck for his missionary future! (btw. do we have to call you Father > Simon then? ;) > > These are some things I would like to see in the near future, post any > additions or complains right here. > > Todo: > * fix all open bugs (pager and search results, pager and list > order...more?) I'm about to start work in a pager for my current project. I will see if I can make it generic. > * put POST and GET data in $r->{params} and deprecate $r->query Yes! I think that this needs to be examined rather carefully - I'm not sure that it handles situations where multiple parameters have the same name correctly (nor am I sure what 'correctly' means in this situation). > * call additional_data() and authenticate() for plain templates I agree :) > * make the templates valid XHTML > * better documentation and more complex examples I mailed the list about the idea of introducing Template caching a while back - the idea of creating a Template object and re-using it. I've had some further ideas about this and would appreciate some feedback before writing the code. The basic problem with caching Template objects here is that we are in a 'disconnected' environment. TT2 gives us a very useful tool - the INCLUDE_PATH parameter to Template->new can have code references and objects as part of it. However, the current include path depends on Maypole's concept of which table is current. That concept changes from request to request. It may also depend on which Maypole application is making the request - clearly the cache should allow a single web server instance to serve multiple Maypole instances. Finally, the caching mechanism needs to be simple enough that it doesn't add too much overhead if used without the sort of semi persistence that comes from running under mod_perl. Oh, and it probably shouldn't rely on mod_perl. I guess that this could be handled by simply supplying a new Maypole::View::XXX rather than replacing Maypole::View::TT. Having said all that then, the problem comes down to 'how do I communicate a change in the path to TT2 without creating a new TT2 object?' As I said above the code reference and objects that can be part of the TT2 INCLUDE_PATH parameter are going to be our friends in this exercise. I think the best approach is to create a small module to allow us to communicate with TT2. I am planning to do the following: add a class attribute to my View class that stores a reference to a hash. This hash will store references to a two item list. It will be keyed on the package name of the driver class (ref($r), that is). The values stored will be a reference to an object in our intermediary class and a reference to the paired Template object). There are reasons for not storing a single Template object that I'll explain later. when the template method is called on this View class it checks for a cached template object. If found it calls a method on the intermediary object to supply it the request object. If not found, it instantiates a new intermediary object and a new TT2 object, passing the intermediary object to the TT2 object as part of the INCLUDE_PATH parameter. Having obtained references to the intermediary and to the TT2 object, the template method will then call a method (let's call it request) on the intermediary object, allowing the intermediary to gather data from the request. The intermediary object must also provide a method called 'paths'. This should respond with the appropriate paths (no suprises there). For paranoia's sake it should probably delete all the data it used to generate that path immediately afterwards. I'm suggesting a per application hash of intermediary and TT2 objects to that these can differ between Maypole applications - in my own applications, for example, I've been customising the TT2 object via configuration to a fairly large degree on a per application basis (using pre processed templates and wrappers, for example). I have a feeling that this is probably not necessary under most circumstances. Dunno. So... the question is... does that all sound sane? nic From sri@oook.de Sun Sep 5 21:12:20 2004 From: sri@oook.de (Sebastian Riedel) Date: Sun, 05 Sep 2004 22:12:20 +0200 Subject: [Maypole] Todo In-Reply-To: References: <413A1958.3000009@oook.de> Message-ID: <413B7324.2060807@oook.de> > I've got quite a few bits and pieces that I will take a good long look > at - some of them may be useful patches. I also have a couple of > suggestions that I'll mail to the developer list - they are mostly to > do with breaking up some of the existing code into smaller chunks to > make inheritance easier. As long as it doesn't break existing applications... > > I don't have a great deal of time at the moment but I'll try to get > you a couple of patches within a couple of weeks (for some reason > selling house + buying house + 1 month old son + finally getting > divorced from ex so I can marry my partner + full time job + part time > job seems to be filling my days, dunno why). And you managed to write this message, wow! :) >> * put POST and GET data in $r->{params} and deprecate $r->query > > > Yes! I think that this needs to be examined rather carefully - I'm > not sure that it handles > situations where multiple parameters have the same name correctly (nor > am I sure what > 'correctly' means in this situation). There i am also not sure, would it be enough to put both in an array? Or use query param only if POST param is not available? > I guess that this could be handled by simply supplying a new > Maypole::View::XXX rather than replacing Maypole::View::TT. Agreed. > > So... the question is... does that all sound sane? Everything that makes us more flexible is sane in my eyes. ;) Cheers, Sebastian From gabor@perl.org.il Mon Sep 6 08:42:02 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 10:42:02 +0300 (IDT) Subject: [Maypole] cookies and other headers in CGI::Maypole Message-ID: Hi, I am new to Maypole and to the list. Trying to put together a CGI::Maypole application. I was trying to send cookies but could not find a way so far so I override function of CGI::Maypole in order to be able to do so. Here is the new function: sub send_output { my $r = shift; print $r->{cgi}->header(-type => $r->{content_type}, -content_length => length $r->{output}, -cookie => $r->{cookie}, ); print $r->{output}; } This works but maybe I just missed the existing way to set the cookie ? In any case it would be nice if I could change all the headers (e.g. I am sure I'll want to change the charset parameter in some of my applications) without overriding this function. Maybe to prepare the additional parameters for the header like this $r->{header} = {-charset => 'utf8', cookie => $cookie}; and then replace the function in CGI::Maypole with this one: sub send_output { my $r = shift; my %header = { -type => $r->{content_type}, -content_length => length $r->{output}, }; %header = %{$r->{header}}; print $r->{cgi}->header(%header); print $r->{output}; } Gabor From gabor@perl.org.il Mon Sep 6 09:02:02 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 11:02:02 +0300 (IDT) Subject: [Maypole] SQLite problem ? Message-ID: In another case I am trying to put a web front-end to CPANTS - an already existing SQLite database. http://cpants.dev.zsi.at/cpants_paper.html Once I a access the thing using Maypole I get the following error in the apache log file: SQL ERROR: 'BIGINT' is not a recognized data type! I tried deleting the tables[1] with the BIGINT fields but then I get: SQL ERROR: Unknown column constraint: 'unsigned'! deleteing these tables too I still get: SQL ERROR: Unknown column constraint: 'default'! Then Maypole can already display the list of the tables but it is still crashing when I try to access either one of them. Deleting the remaing two tables elimitae the crashes but having an empty database is not that much fun. Does anyone have an idea why does this happen ? [1] I am using the command line interface of SQLite v2.8.14 and it can read the database. perl -MDBD::SQLite -e'print $DBD::SQLite::VERSION' 0.31 AFAIK this is the latest version of DBD::SQLite using the 2.8.* database structure and I assume the file is of that version if the command line tool can read. Gabor From sri@oook.de Mon Sep 6 10:45:09 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 11:45:09 +0200 Subject: [Maypole] cookies and other headers in CGI::Maypole In-Reply-To: References: Message-ID: <413C31A5.9050203@oook.de> Gabor Szabo: >Hi, > >I am new to Maypole and to the list. >Trying to put together a CGI::Maypole application. > >I was trying to send cookies but could not find a way so far so I >override function of CGI::Maypole in order to be able to do so. >Here is the new function: > > >sub send_output { > my $r = shift; > > print $r->{cgi}->header(-type => $r->{content_type}, > -content_length => length $r->{output}, > -cookie => $r->{cookie}, > ); > print $r->{output}; >} > >This works but maybe I just missed the existing way to set the cookie ? > > Well, there are two nice modules at CPAN, Maypole::Authentication::UserSessionCookie and Maypole::Authentication::Abstract, but both require Apache::Cookie at the moment. It should be easy to make them usable with both CGI::Maypole and Apache::MVC. When i get some time i will see what i can do for my Maypole::Authentication::Abstract. Btw. Who is the new maintainer of Maypole::Authentication::UserSessionCookie? > > >In any case it would be nice if I could change all the headers (e.g. I >am sure I'll want to change the charset parameter in some of my >applications) without overriding this function. >Maybe to prepare the additional parameters for the header like this > > $r->{header} = {-charset => 'utf8', cookie => $cookie}; > >and then replace the function in CGI::Maypole with this one: > >sub send_output { > my $r = shift; > > my %header = { > -type => $r->{content_type}, > -content_length => length $r->{output}, > }; > > %header = %{$r->{header}}; > > print $r->{cgi}->header(%header); > print $r->{output}; >} > > > Yes, a simple header interface would be nice. It's now on the todo list... > > >Gabor > >_______________________________________________ >maypole mailing list >maypole@lists.netthink.co.uk >http://lists.netthink.co.uk/listinfo/maypole > > > Cheers, Sebastian From simon@simon-cozens.org Mon Sep 6 11:01:40 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 11:01:40 +0100 Subject: [Maypole] SQLite problem ? In-Reply-To: References: Message-ID: <20040906100140.GA18452@alibi.simon-cozens.org> Gabor Szabo: > SQL ERROR: 'BIGINT' is not a recognized data type! Sounds like Class::DBI::Loader is unhappy with your schema. Do you have the latest Class::DBI::SQLite? -- > This job is heavily NDA'ed, You will be at the bo'nenkai, won't you? Full house (beers over nihonshu) beats a pair of NDAs with an ace kicker any time. I'll even buy.... ;-) - Stephen Turnbull From sri@oook.de Mon Sep 6 11:08:58 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 12:08:58 +0200 Subject: [Maypole] Todo In-Reply-To: <413A1958.3000009@oook.de> References: <413A1958.3000009@oook.de> Message-ID: <413C373A.1080707@oook.de> Some additions based on feedback: > Todo: > * fix all open bugs (pager and search results, pager and list > order...more?) > * call additional_data() and authenticate() for plain templates > * make the templates valid XHTML > * better documentation and more complex examples * mod_perl 2.0 compatibility * simple header interface $r->{header} (and maybe a send_header() method to overload?) > * put POST and GET data in $r->{params} and deprecate $r->query This one is kind of funny, everybody wants it and everybody has a different solution for it. So this will have to wait until we find a good solution we all like. Cheers, Sebastian From simon@thegestalt.org Mon Sep 6 11:19:56 2004 From: simon@thegestalt.org (Simon Wistow) Date: Mon, 6 Sep 2004 11:19:56 +0100 Subject: [Maypole] Access to the Apache::Request object Message-ID: <20040906101956.GC28947@thegestalt.org> I currently have a Maypole app that does something like this ... sub view :Exported { my ($self, $r, $att) = @_; eval { my $a = Apache->request; $a->headers_out->set("Content-Disposition" => "inline; filename=".$att->filename) if $a; }; $r->{content_type} = $att->content_type; $r->{output} = $att->payload; } which seems, well, clunky. Am I missing something from the Maypole docs? cheers, Simon -- i try not to let pedantry get in the way of a glib remark From sri@oook.de Mon Sep 6 11:28:49 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 12:28:49 +0200 Subject: [Maypole] Access to the Apache::Request object In-Reply-To: <20040906101956.GC28947@thegestalt.org> References: <20040906101956.GC28947@thegestalt.org> Message-ID: <413C3BE1.6060005@oook.de> Simon Wistow: >I currently have a Maypole app that does something like this ... > > sub view :Exported { > my ($self, $r, $att) = @_; > > > eval { > my $a = Apache->request; > $a->headers_out->set("Content-Disposition" => "inline; > filename=".$att->filename) if $a; > }; > > $r->{content_type} = $att->content_type; > $r->{output} = $att->payload; > } > >which seems, well, clunky. Am I missing something from the Maypole docs? > > No, a simple header interface is on the todo list! :) >cheers, >Simon > > > > Cheers, Sebastian From sf@flacks.net Mon Sep 6 11:34:02 2004 From: sf@flacks.net (Simon Flack) Date: Mon, 6 Sep 2004 11:34:02 +0100 Subject: [Maypole] [PATCH]: decouple param parsing from parse_location (was: Re: Todo) In-Reply-To: <413C373A.1080707@oook.de> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> Message-ID: <20040906102115.M84890@flacks.net> This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.0749536862867934 Content-Type: text/plain; charset=iso-8859-1 On Mon, 06 Sep 2004 12:08:58 +0200, Sebastian Riedel wrote > Some additions based on feedback: > [snip] > > * put POST and GET data in $r->{params} and deprecate $r->query > > This one is kind of funny, everybody wants it and everybody has a > different solution for it. > So this will have to wait until we find a good solution we all like. Ok, but in the meantime, can we make it easier to override for v1.8? I've attached a patch to that effect. Another minor TODO would be to fix the indenting in CGI::Maypole. Everything else looks ok (4 space indent). Yes, I'm slightly anal, but it's helpful to keep the code clean and have some loose standards for people providing patches. It might be worth pinching the Slash style guide and modifying the bits you don't like: http://www.slashcode.com/docs/slashstyle.html --simonflk ------=OPENWEBMAIL_ATT_0.0749536862867934 Content-Type: application/octet-stream; name="Maypole-parse_args.diff" Content-Disposition: attachment; filename="Maypole-parse_args.diff" Content-Transfer-Encoding: base64 LS0tIC4vbGliL01heXBvbGUvQ0xJLnBtLm9yaWcJTW9uIFNlcCAgNiAxMToxNzozMCAyMDA0Cisr KyAuL2xpYi9NYXlwb2xlL0NMSS5wbQlNb24gU2VwICA2IDExOjE5OjQ1IDIwMDQKQEAgLTI1LDYg KzI1LDExIEBACiAgICAgJHNlbGYtPntwYXRofSA9ICR1cmwtPnBhdGg7CiAgICAgJHNlbGYtPntw YXRofSA9fiBzL14kcm9vdC8vaSBpZiAkcm9vdDsKICAgICAkc2VsZi0+cGFyc2VfcGF0aDsKK30K Kworc3ViIHBhcnNlX2FyZ3MgeworICAgIG15ICRzZWxmID0gc2hpZnQ7CisgICAgJHNlbGYtPntw YXJhbXN9ID0gJHVybC0+cXVlcnlfZm9ybV9oYXNoOwogICAgICRzZWxmLT57cXVlcnl9ID0gJHVy bC0+cXVlcnlfZm9ybV9oYXNoOwogfQogCi0tLSAuL2xpYi9DR0kvTWF5cG9sZS5wbS5vcmlnCU1v biBTZXAgIDYgMTE6MTc6MjAgMjAwNAorKysgLi9saWIvQ0dJL01heXBvbGUucG0JTW9uIFNlcCAg NiAxMToxODo0OSAyMDA0CkBAIC0yMiwxMCArMjIsMTUgQEAKICAgICAgbm8gd2FybmluZ3MgJ3Vu aW5pdGlhbGl6ZWQnOwogICAgICAkc2VsZi0+e3BhdGh9ID1+IHMvXigkbG9jKT9cLy8vOwogICAg ICAkc2VsZi0+cGFyc2VfcGF0aDsKLSAgICAgJHNlbGYtPntwYXJhbXN9ID0geyAkc2VsZi0+e2Nn aX0tPlZhcnMgfTsKLSAgICAgJHNlbGYtPntxdWVyeX0gID0geyAkc2VsZi0+e2NnaX0tPlZhcnMg fTsKKyAgICAgJHNlbGYtPnBhcnNlX2FyZ3M7CiB9CiAKK3N1YiBwYXJzZV9hcmdzIHsKKyAgICBt eSAkc2VsZiA9IHNoaWZ0OworICAgICRzZWxmLT57cGFyYW1zfSA9IHsgJHNlbGYtPntjZ2l9LT5W YXJzIH07CisgICAgJHNlbGYtPntxdWVyeX0gID0geyAkc2VsZi0+e2NnaX0tPlZhcnMgfTsKK30K Kwogc3ViIHNlbmRfb3V0cHV0IHsKICAgICAgbXkgJHIgPSBzaGlmdDsJCiAJcHJpbnQgJHItPntj Z2l9LT5oZWFkZXIoLXR5cGUgPT4gJHItPntjb250ZW50X3R5cGV9LAotLS0gLi9saWIvQXBhY2hl L01WQy5wbS5vcmlnCU1vbiBTZXAgIDYgMTE6MTY6NTcgMjAwNAorKysgLi9saWIvQXBhY2hlL01W Qy5wbQlNb24gU2VwICA2IDExOjE4OjE3IDIwMDQKQEAgLTE3LDcgKzE3LDExIEBACiAgICAgbm8g d2FybmluZ3MgJ3VuaW5pdGlhbGl6ZWQnOwogICAgICRzZWxmLT57cGF0aH0gPX4gcy9eKCRsb2Mp P1wvLy87CiAgICAgJHNlbGYtPnBhcnNlX3BhdGg7CisgICAgJHNlbGYtPnBhcnNlX2FyZ3M7Cit9 CiAKK3N1YiBwYXJzZV9hcmdzIHsKKyAgICBteSAkc2VsZiA9IHNoaWZ0OwogICAgICRzZWxmLT57 cGFyYW1zfSA9IHsgJHNlbGYtPnthcn0tPmNvbnRlbnQgfTsKICAgICB3aGlsZSAobXkgKCRrZXks ICR2YWx1ZSkgPSBlYWNoICV7JHNlbGYtPntwYXJhbXN9fSkgewogICAgICAgJHNlbGYtPntwYXJh bXN9eyRrZXl9ID0gJycgdW5sZXNzIGRlZmluZWQgJHZhbHVlOwo= ------=OPENWEBMAIL_ATT_0.0749536862867934-- From simon@thegestalt.org Mon Sep 6 11:39:04 2004 From: simon@thegestalt.org (Simon Wistow) Date: Mon, 6 Sep 2004 11:39:04 +0100 Subject: [Maypole] Access to the Apache::Request object In-Reply-To: <413C3BE1.6060005@oook.de> References: <20040906101956.GC28947@thegestalt.org> <413C3BE1.6060005@oook.de> Message-ID: <20040906103904.GE28947@thegestalt.org> On Mon, Sep 06, 2004 at 12:28:49PM +0200, Sebastian Riedel said: > No, a simple header interface is on the todo list! :) Ah. Excellent. I thought I was going insane. From gabor@perl.org.il Mon Sep 6 11:46:56 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 13:46:56 +0300 (IDT) Subject: [Maypole] SQLite problem ? In-Reply-To: <20040906100140.GA18452@alibi.simon-cozens.org> References: <20040906100140.GA18452@alibi.simon-cozens.org> Message-ID: On Mon, 6 Sep 2004, Simon Cozens wrote: > Gabor Szabo: > > SQL ERROR: 'BIGINT' is not a recognized data type! > > Sounds like Class::DBI::Loader is unhappy with your schema. Do you have the > latest Class::DBI::SQLite? I am at 0.04 that seems to be the latest. here is a small example of dumped data that already generates one of the error messages: BEGIN TRANSACTION; create table authors ( cpanid varchar(10), name varchar(200), email varchar(250), average_kwalitee float default 0, distcount int unsigned default 0 ); INSERT INTO authors VALUES(NULL,NULL,NULL,0,0); INSERT INTO authors VALUES('VKON','Vadim','ru',7.66,3); COMMIT; Gabor From sf@flacks.net Mon Sep 6 11:55:37 2004 From: sf@flacks.net (Simon Flack) Date: Mon, 6 Sep 2004 11:55:37 +0100 Subject: [Maypole] SQLite problem ? In-Reply-To: References: <20040906100140.GA18452@alibi.simon-cozens.org> Message-ID: <20040906105149.M24566@flacks.net> On Mon, 6 Sep 2004 13:46:56 +0300 (IDT), Gabor Szabo wrote > On Mon, 6 Sep 2004, Simon Cozens wrote: > > > Gabor Szabo: > > > SQL ERROR: 'BIGINT' is not a recognized data type! > > > > Sounds like Class::DBI::Loader is unhappy with your schema. Do you have the > > latest Class::DBI::SQLite? > > I am at 0.04 that seems to be the latest. What version of SQLite are you using? ICBW but I suspect Class::DBI::SQLite doesn't work with the new sqlite3 database format. --simonflk From simon@simon-cozens.org Mon Sep 6 11:55:39 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 11:55:39 +0100 Subject: [Maypole] Access to the Apache::Request object In-Reply-To: <413C3BE1.6060005@oook.de> References: <20040906101956.GC28947@thegestalt.org> <413C3BE1.6060005@oook.de> Message-ID: <20040906105539.GB18452@alibi.simon-cozens.org> Sebastian Riedel: > >which seems, well, clunky. Am I missing something from the Maypole docs? > No, a simple header interface is on the todo list! :) Do you know, I thought "$r->ar" (as documented in Maypole::Workflow) was simple enough, but if you can come up with a simpler one, that would be great. -- Be not anxious about what you have, but about what you are. -- Pope St. Gregory I From sri@oook.de Mon Sep 6 11:58:18 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 12:58:18 +0200 Subject: [Maypole] [PATCH]: decouple param parsing from parse_location In-Reply-To: <20040906102115.M84890@flacks.net> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> <20040906102115.M84890@flacks.net> Message-ID: <413C42CA.4070902@oook.de> Simon Flack schrieb: >On Mon, 06 Sep 2004 12:08:58 +0200, Sebastian Riedel wrote > > >>Some additions based on feedback: >> >> >> >[snip] > > >>>* put POST and GET data in $r->{params} and deprecate $r->query >>> >>> >>This one is kind of funny, everybody wants it and everybody has a >>different solution for it. >>So this will have to wait until we find a good solution we all like. >> >> > >Ok, but in the meantime, can we make it easier to override for v1.8? I've >attached a patch to that effect. > > Yes we can, your patch has some small bugs but i will fix it... So...thanks, applied. :) >Another minor TODO would be to fix the indenting in CGI::Maypole. Everything >else looks ok (4 space indent). Yes, I'm slightly anal, but it's helpful to >keep the code clean and have some loose standards for people providing patches. > > I will run perltidy over everything for the 1.8 release. >It might be worth pinching the Slash style guide and modifying the bits you >don't like: > >http://www.slashcode.com/docs/slashstyle.html > >--simonflk > > > Cheers, Sebastian From sri@oook.de Mon Sep 6 12:06:34 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 13:06:34 +0200 Subject: [Maypole] Access to the Apache::Request object In-Reply-To: <20040906105539.GB18452@alibi.simon-cozens.org> References: <20040906101956.GC28947@thegestalt.org> <413C3BE1.6060005@oook.de> <20040906105539.GB18452@alibi.simon-cozens.org> Message-ID: <413C44BA.5040906@oook.de> Simon Cozens: >Sebastian Riedel: > > >>>which seems, well, clunky. Am I missing something from the Maypole docs? >>> >>> >>No, a simple header interface is on the todo list! :) >> >> > >Do you know, I thought "$r->ar" (as documented in Maypole::Workflow) was >simple enough, but if you can come up with a simpler one, that would be great. > > > I would like to have a $r->{header} slot containing a hash. So it would be as easy as $r->{header}{X-Bender} = 'kiss my shiny metal ass'; Cheers, Sebastian From gabor@perl.org.il Mon Sep 6 12:12:20 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 14:12:20 +0300 (IDT) Subject: [Maypole] SQLite problem ? In-Reply-To: <20040906105149.M24566@flacks.net> References: <20040906100140.GA18452@alibi.simon-cozens.org> <20040906105149.M24566@flacks.net> Message-ID: On Mon, 6 Sep 2004, Simon Flack wrote: > What version of SQLite are you using? ICBW but I suspect Class::DBI::SQLite > doesn't work with the new sqlite3 database format. > > --simonflk > Well, the same thing happens when I create the database myself with my tools so it does not seem to be SQLite version problem. (Actually since my first message, Thomas Klausner the creator of the database also answered and he also used the the DBD::SQLite when he created the database) Anyway here are some versions: Class::DBI::SQLite 0.04 sqlite-2.8.14.bin -version 2.8.14 I can read the database using this command line interface. #!/use/bin/perl use DBI; my $DBH=DBI->connect("dbi:SQLite:dbname=test.db"); print $DBH->{sqlite_version}; Gives back 2.8.12. I am using 0.31 of DBD::SQLite. Gabor From simon@thegestalt.org Mon Sep 6 12:26:42 2004 From: simon@thegestalt.org (Simon Wistow) Date: Mon, 6 Sep 2004 12:26:42 +0100 Subject: [Maypole] Todo In-Reply-To: <413A1958.3000009@oook.de> References: <413A1958.3000009@oook.de> Message-ID: <20040906112642.GF28947@thegestalt.org> On Sat, Sep 04, 2004 at 09:36:56PM +0200, Sebastian Riedel said: > These are some things I would like to see in the near future, post any > additions or complains right here. Since I'm in the posting mood ;) here's something I'd quite like (if it isn't in already which. given my earlier mistkae it probably is). It would be nice to be able to physically redirect rather than just perform a template switcheroo - I have a voting page which switches back to the view page which displays the current running totals but I'd rather actually redirect back so that people hitting 'refresh' to find the latest results aren't inadvertently voting again. This might be of use http://search.cpan.org/~ebruni/Apache-Request-Redirect/Redirect.pod Cheers, Simon From simon@simon-cozens.org Mon Sep 6 12:27:47 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 12:27:47 +0100 Subject: [Maypole] Todo In-Reply-To: <20040906112642.GF28947@thegestalt.org> References: <413A1958.3000009@oook.de> <20040906112642.GF28947@thegestalt.org> Message-ID: <20040906112747.GB24014@alibi.simon-cozens.org> Simon Wistow: > Since I'm in the posting mood ;) here's something I'd quite like (if it > isn't in already which. given my earlier mistkae it probably is). > > It would be nice to be able to physically redirect rather than just > perform a template switcheroo See Maypole::Redirect. -- BASH is great, it dumps core and has clear documentation. -Ari Suntioinen From simon@thegestalt.org Mon Sep 6 12:37:05 2004 From: simon@thegestalt.org (Simon Wistow) Date: Mon, 6 Sep 2004 12:37:05 +0100 Subject: [Maypole] Todo In-Reply-To: <20040906112747.GB24014@alibi.simon-cozens.org> References: <413A1958.3000009@oook.de> <20040906112642.GF28947@thegestalt.org> <20040906112747.GB24014@alibi.simon-cozens.org> Message-ID: <20040906113705.GG28947@thegestalt.org> On Mon, Sep 06, 2004 at 12:27:47PM +0100, Simon Cozens said: > See Maypole::Redirect. Ok, I'm going to shut up now until this infection of Stupid has cleared up. From gabor@perl.org.il Mon Sep 6 12:48:58 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 14:48:58 +0300 (IDT) Subject: [Maypole] SQLite problem ? In-Reply-To: References: <20040906100140.GA18452@alibi.simon-cozens.org> <20040906105149.M24566@flacks.net> Message-ID: Ok, so if nobody helps then... I looked where this error message comes from and it turns out it is from SQL::Parser v1.09 its documentation sais: * The following valid ANSI SQL92 options are not currently supported: table constraints, named constraints, check constriants, reference constraints, constraint attributes, collations, default clauses, domain names as data types so I think this is the source of the problem. Luckily I don't need these constraint in my read-only appliation so I'll look for a way to get rid of them. I'll come back to complain with other things later ;) Gabor From gabor@perl.org.il Mon Sep 6 13:51:21 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 15:51:21 +0300 (IDT) Subject: [Maypole] Primary key on multiple columns Message-ID: After replacing the unsupported fields with other fields most of things are already working in the CPANTS reader but there is one table for which the primary key should be two columns. I tried to do this in my Maypole code CPANTS::Maypole::Prereq->columns(Primary => qw/dist requires/); that generated the following: [Mon Sep 06 10:47:30 2004] [error] [client 127.0.0.1] CPANTS::Maypole::Prereq->retrieve() parameters don't include values for all primary key columns (dist requires) at /opt/perl584/lib/site_perl/5.8.4/Maypole/Model/Base.pm line 16, referer: http://cpants.local/size/list/ [Mon Sep 06 10:47:30 2004] [error] [client 127.0.0.1] Premature end of script headers: cpants.pl, referer: http://cpants.local/size/list/ what am I doing wrong and how can I tell maypole which are the primary keys ? regards Gabor From edward@debian.org Mon Sep 6 16:34:28 2004 From: edward@debian.org (Edward Betts) Date: Mon, 6 Sep 2004 16:34:28 +0100 Subject: [Maypole] Using Class::Date with Maypole Message-ID: <20040906153428.GA13698@4angle.com> Local formatted datetimes instead of ISO datetimes will scare users less, http://www.class-dbi.com/cgi-bin/wiki/index.cgi?ClassDate says it can be done using Class::Date, with something like: Film->has_a( created_date => 'Class::Date' ); When I try it with the Maypole and the default templates it gives me an error: undef error - Can't locate auto/Class/Date/table.al in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . /etc/apache-perl/ /etc/apache-perl/lib/perl) at (eval 69) line 44 The cause is in the macros template: MACRO maybe_link_view(object) BLOCK; IF object.table; # It's an object, i.e. a has-a link(object.table, "view", object.id, object); ELSE; object; END; END; How should I change the template to so that it doesn't try and load Class::Date::table? From simon@simon-cozens.org Mon Sep 6 16:51:56 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 16:51:56 +0100 Subject: [Maypole] Using Class::Date with Maypole In-Reply-To: <20040906153428.GA13698@4angle.com> References: <20040906153428.GA13698@4angle.com> Message-ID: <20040906155156.GA14339@alibi.simon-cozens.org> Edward Betts: > The cause is in the macros template: Well, don't use the default templates. I have written on this extensively before. :) > How should I change the template to so that it doesn't try and load > Class::Date::table? IF object.can("table"), I guess. I didn't realise TT had issues with Autoloader modules. -- No proper program contains an indication which as an operator-applied occurrence identifies an operator-defining occurrence which as an indication- applied occurrence identifies an indication-defining occurrence different from the one identified by the given indication as an indication-applied occurrence. - Algol 68 Report From marcus@thefeed.no Mon Sep 6 16:54:48 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Mon, 6 Sep 2004 17:54:48 +0200 Subject: [Maypole] Todo In-Reply-To: <413C373A.1080707@oook.de> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> Message-ID: <14DDD13C-001D-11D9-95BC-000A956D773E@thefeed.no> On 6. sep. 2004, at 12.08, Sebastian Riedel wrote: > Some additions based on feedback: > >> Todo: >> * fix all open bugs (pager and search results, pager and list >> order...more?) >> * call additional_data() and authenticate() for plain templates >> * make the templates valid XHTML >> * better documentation and more complex examples > > * mod_perl 2.0 compatibility See Apache2::MVC ? Marcus From sri@oook.de Mon Sep 6 17:51:04 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 18:51:04 +0200 Subject: [Maypole] Todo In-Reply-To: <14DDD13C-001D-11D9-95BC-000A956D773E@thefeed.no> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> <14DDD13C-001D-11D9-95BC-000A956D773E@thefeed.no> Message-ID: <413C9578.4030508@oook.de> Marcus Ramberg: > > On 6. sep. 2004, at 12.08, Sebastian Riedel wrote: > >> Some additions based on feedback: >> >>> Todo: >>> * fix all open bugs (pager and search results, pager and list >>> order...more?) >>> * call additional_data() and authenticate() for plain templates >>> * make the templates valid XHTML >>> * better documentation and more complex examples >> >> >> * mod_perl 2.0 compatibility > > See Apache2::MVC ? Looks good, just wondering how to integrate it into Apache::MVC, but that shouldn't be very hard... (using $mod_perl::VERSION) > > Marcus > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > Cheers, Sebastian From marcus@thefeed.no Mon Sep 6 17:59:00 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Mon, 6 Sep 2004 18:59:00 +0200 Subject: [Maypole] Todo In-Reply-To: <413C9578.4030508@oook.de> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> <14DDD13C-001D-11D9-95BC-000A956D773E@thefeed.no> <413C9578.4030508@oook.de> Message-ID: <0C73C714-0026-11D9-95BC-000A956D773E@thefeed.no> On 6. sep. 2004, at 18.51, Sebastian Riedel wrote: > Marcus Ramberg: > >> >> On 6. sep. 2004, at 12.08, Sebastian Riedel wrote: >> >> See Apache2::MVC ? > > Looks good, just wondering how to integrate it into Apache::MVC, but > that shouldn't be very hard... (using $mod_perl::VERSION) It should probably be used as a separate driver class, much like Maypole::CGI and the FastCGI driver floating out there somewhere? If base driver class should be set automagically it should probably include cgi as well? Maybe a separate module like Maypole::Autoloader or something to choose backend based on the environment? Would be a nice complement to a future Maypole::PAR module as well. Marcus From chromatic+maypole@wgz.org Mon Sep 6 18:11:19 2004 From: chromatic+maypole@wgz.org (chromatic) Date: Mon, 06 Sep 2004 10:11:19 -0700 Subject: [Maypole] Todo In-Reply-To: <413A1958.3000009@oook.de> References: <413A1958.3000009@oook.de> Message-ID: <1094490678.26179.1.camel@localhost> On Sat, 2004-09-04 at 12:36, Sebastian Riedel wrote: > * put POST and GET data in $r->{params} and deprecate $r->query Actually, the lack of encapsulation there drives me crazy. If it were up to me, I'd hide everything in $r behind nice method names instead of going the other way around. -- c From simon@simon-cozens.org Mon Sep 6 18:20:06 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 18:20:06 +0100 Subject: [Maypole] Todo In-Reply-To: <1094490678.26179.1.camel@localhost> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> Message-ID: <20040906172006.GA22781@alibi.simon-cozens.org> chromatic: > > * put POST and GET data in $r->{params} and deprecate $r->query > > Actually, the lack of encapsulation there drives me crazy. If it were > up to me, I'd hide everything in $r behind nice method names instead of > going the other way around. The fact that Maypole uses ->{x} sometimes rather than ->x is nothing to do with encapsulation, and everything to do with the facts that (a) I was micro-optimizing, and (b) I didn't really know what accessor methods I needed added for the $r slots and was just making stuff up as I went along, and hence was too lazy to add it back to ->mk_accessors. The universal fix is to change ->{foo} to ->foo and put "foo" in the mk_accessors list, for all values of foo. -- I inflict collateral damage; you have questionable foreign policy; they butcher innocent civilians. - Jon Chin From sri@oook.de Mon Sep 6 18:20:47 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 19:20:47 +0200 Subject: [Maypole] Todo In-Reply-To: <0C73C714-0026-11D9-95BC-000A956D773E@thefeed.no> References: <413A1958.3000009@oook.de> <413C373A.1080707@oook.de> <14DDD13C-001D-11D9-95BC-000A956D773E@thefeed.no> <413C9578.4030508@oook.de> <0C73C714-0026-11D9-95BC-000A956D773E@thefeed.no> Message-ID: <413C9C6F.9050406@oook.de> Marcus Ramberg schrieb: > On 6. sep. 2004, at 18.51, Sebastian Riedel wrote: > >> Marcus Ramberg: >> >>> >>> On 6. sep. 2004, at 12.08, Sebastian Riedel wrote: >>> >>> See Apache2::MVC ? >> >> >> Looks good, just wondering how to integrate it into Apache::MVC, but >> that shouldn't be very hard... (using $mod_perl::VERSION) > > > It should probably be used as a separate driver class, much like > Maypole::CGI and the FastCGI driver floating out there somewhere? If > base driver class should be set automagically it should probably > include cgi as well? Maybe a separate module like Maypole::Autoloader > or something to choose backend based on the environment? Would be a > nice complement to a future Maypole::PAR module as well. Very good idea! And quite simple to implement... > > Marcus > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > Cheers, Sebastian From sri@oook.de Mon Sep 6 18:38:34 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 19:38:34 +0200 Subject: [Maypole] Todo In-Reply-To: <20040906172006.GA22781@alibi.simon-cozens.org> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> <20040906172006.GA22781@alibi.simon-cozens.org> Message-ID: <413CA09A.9060601@oook.de> Simon Cozens: >The universal fix is to change ->{foo} to ->foo and put "foo" in the >mk_accessors list, for all values of foo. > > > Talked with Max "Corion" Maischein about it, maybe he wants to fix that, so it's another point on the todo list. :) Cheers, Sebastian From marcus@thefeed.no Mon Sep 6 18:41:16 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Mon, 6 Sep 2004 19:41:16 +0200 Subject: [Maypole] Todo In-Reply-To: <413CA09A.9060601@oook.de> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> <20040906172006.GA22781@alibi.simon-cozens.org> <413CA09A.9060601@oook.de> Message-ID: On 6. sep. 2004, at 19.38, Sebastian Riedel wrote: > Simon Cozens: > >> The universal fix is to change ->{foo} to ->foo and put "foo" in the >> mk_accessors list, for all values of foo. >> >> > Talked with Max "Corion" Maischein about it, maybe he wants to fix > that, so it's another point on the todo list. :) This would also make life easier for other views than TT, that don't treat ->{thing} and ->thing the same way. Marcus From sf@flacks.net Mon Sep 6 18:50:08 2004 From: sf@flacks.net (Simon Flack) Date: Mon, 6 Sep 2004 18:50:08 +0100 Subject: [Maypole] Todo In-Reply-To: <20040906172006.GA22781@alibi.simon-cozens.org> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> <20040906172006.GA22781@alibi.simon-cozens.org> Message-ID: <20040906174654.M70480@flacks.net> On Mon, 6 Sep 2004 18:20:06 +0100, Simon Cozens wrote > chromatic: > > > * put POST and GET data in $r->{params} and deprecate $r->query > > > > Actually, the lack of encapsulation there drives me crazy. If it were > > up to me, I'd hide everything in $r behind nice method names instead of > > going the other way around. > > The fact that Maypole uses ->{x} sometimes rather than ->x is > nothing to do with encapsulation, and everything to do with the > facts that (a) I was micro-optimizing, and (b) I didn't really know > what accessor methods I needed added for the $r slots and was just > making stuff up as I went along, and hence was too lazy to add it > back to ->mk_accessors. > > The universal fix is to change ->{foo} to ->foo and put "foo" in the > mk_accessors list, for all values of foo. But not for param(). param() IMO, should call $r->get_request->param(). That'd work at least for Apache::MVC and CGI::Maypole. You'd probably need something cleverer for Maypole::CLI. From simon@simon-cozens.org Mon Sep 6 18:59:18 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Mon, 6 Sep 2004 18:59:18 +0100 Subject: [Maypole] Todo In-Reply-To: <20040906174654.M70480@flacks.net> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> <20040906172006.GA22781@alibi.simon-cozens.org> <20040906174654.M70480@flacks.net> Message-ID: <20040906175918.GB22781@alibi.simon-cozens.org> Simon Flack: > But not for param(). param() IMO, should call $r->get_request->param(). That'd > work at least for Apache::MVC and CGI::Maypole. You'd probably need something > cleverer for Maypole::CLI. Huh? No, I think you misunderstand. The intention was that a Maypole request should be a superset of an Apache::Request or equivalent. It should encapsulate everything you need to know about the journey of a request from the browser to Maypole and out through the view class and the frontend. The parameters and arguments are no longer Apache or CGI parameters and arguments - they are Maypole parameters and arguments. You don't need to care where they come from. Imagine a pure-Maypole httpd (in a week, you won't have to *imagine* one, since I actually need one) - it won't get_request because the Maypole request will be all there is. get_request merely merges information from the environment into the Maypole request object. -- Imbalance of power corrupts and monopoly of power corrupts absolutely. -- Genji From sf@flacks.net Mon Sep 6 19:18:43 2004 From: sf@flacks.net (Simon Flack) Date: Mon, 6 Sep 2004 19:18:43 +0100 Subject: [Maypole] Todo In-Reply-To: <20040906175918.GB22781@alibi.simon-cozens.org> References: <413A1958.3000009@oook.de> <1094490678.26179.1.camel@localhost> <20040906172006.GA22781@alibi.simon-cozens.org> <20040906174654.M70480@flacks.net> <20040906175918.GB22781@alibi.simon-cozens.org> Message-ID: <20040906181555.M49084@flacks.net> On Mon, 6 Sep 2004 18:59:18 +0100, Simon Cozens wrote > Simon Flack: > > But not for param(). param() IMO, should call $r->get_request->param(). That'd > > work at least for Apache::MVC and CGI::Maypole. You'd probably need something > > cleverer for Maypole::CLI. > > Huh? No, I think you misunderstand. > > The intention was that a Maypole request should be a superset of an > Apache::Request or equivalent. It should encapsulate everything you > need to know about the journey of a request from the browser to > Maypole and out through the view class and the frontend. The > parameters and arguments are no longer Apache or CGI parameters and > arguments - they are Maypole parameters and arguments. You don't > need to care where they come from. > > Imagine a pure-Maypole httpd (in a week, you won't have to *imagine* > one, since I actually need one) - it won't get_request because the > Maypole request will be all there is. > > get_request merely merges information from the environment into the Maypole > request object. No. I understand all that. My point is that if $r->param('foo') or $r->param->{foo} simply returns the internal data structure, it means I have to write lots more supporting code: my $subscriber = $r->param()->{subscriber}; if (ref $subscriber eq 'ARRAY') { # I'm only after a single subscriber $subscriber = $subscriber->[0]; } or conversely, my $subscribers = $r->param()->{subscriber}; unless (ref $subscribers) { # Now I'm expecting a list $subscribers = [$subscribers]; } vs: my @subscribers = $r->param('subscriber'); my $subscriber = $r->param('subscriber'); I don't *actually* care whether param() delegates to get_request(), or whether it re-impliments the same functionality. But IMO, the param() method should behave like CGI's and A::R's because they DWIM. The good thing is that we don't have to agree. I can always impliment my own param() --simonflk From sri@oook.de Mon Sep 6 21:09:52 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 22:09:52 +0200 Subject: [Maypole] Todo In-Reply-To: <413A1958.3000009@oook.de> References: <413A1958.3000009@oook.de> Message-ID: <413CC410.8030406@oook.de> Status: * fix all open bugs (pager and search results, pager and list order...more?) - will do this later...(patches welcome) > * call additional_data() and authenticate() for plain templates - done > * make the templates valid XHTML - later...(someone willing to do it?) > * better documentation and more complex examples - this is going to be on the list forever ;) * mod_perl 2.0 compatibility - maybe done, added Apache2::MVC but have no idea if it works because my mod_perl2 is not yet compiled. :) * simple header interface $r->{header} (and maybe a send_header() method to overload?) - not sure about this, simon tries to convince me that we need HTTP::Response... > * put POST and GET data in $r->{params} and deprecate $r->query - added parse_args(), more later * Add new universal front-end that detects if it's a CGI, Apache or Apache2 - done! :) called it Maypole::Application for now * perltidy - later A first snapshot can be found at: http://files.oook.de/Maypole/Maypole-1.8.tar.gz Cheers, Sebastian _______________________________________________ maypole mailing list maypole@lists.netthink.co.uk http://lists.netthink.co.uk/listinfo/maypole From gabor@perl.org.il Mon Sep 6 21:18:46 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Mon, 6 Sep 2004 23:18:46 +0300 (IDT) Subject: [Maypole] CPANTS web front end Message-ID: After some struggle with the schema that was partially unsupported by SQL::Parser and lacked any primary keys finally I managed to put together the first version of the interface. http://cpants.szabgab.com/ thanks for Maypole Gabor From marcus@thefeed.no Mon Sep 6 21:32:38 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Mon, 6 Sep 2004 22:32:38 +0200 Subject: [Maypole] Todo In-Reply-To: <413CC410.8030406@oook.de> References: <413A1958.3000009@oook.de> <413CC410.8030406@oook.de> Message-ID: I just remembered one more suggestion for TODO: Write tests. Marcus On 6. sep. 2004, at 22.09, Sebastian Riedel wrote: > Status: > > * fix all open bugs (pager and search results, pager and list > order...more?) > - will do this later...(patches welcome) > >> * call additional_data() and authenticate() for plain templates > - done > >> * make the templates valid XHTML > - later...(someone willing to do it?) > >> * better documentation and more complex examples > - this is going to be on the list forever ;) > > * mod_perl 2.0 compatibility > - maybe done, added Apache2::MVC but have no idea if it works because > my mod_perl2 is not yet compiled. :) > > * simple header interface $r->{header} (and maybe a send_header() > method > to overload?) > - not sure about this, simon tries to convince me that we need > HTTP::Response... > >> * put POST and GET data in $r->{params} and deprecate $r->query > - added parse_args(), more later > > * Add new universal front-end that detects if it's a CGI, Apache or > Apache2 > - done! :) called it Maypole::Application for now > > * perltidy > - later > > A first snapshot can be found at: > http://files.oook.de/Maypole/Maypole-1.8.tar.gz > > Cheers, > Sebastian > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole From sri@oook.de Mon Sep 6 21:43:57 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 06 Sep 2004 22:43:57 +0200 Subject: [Maypole] Todo In-Reply-To: References: <413A1958.3000009@oook.de> <413CC410.8030406@oook.de> Message-ID: <413CCC0D.8090502@oook.de> Marcus Ramberg: > I just remembered one more suggestion for TODO: > Write tests. Definedly, someone willing to do it? (...please!) ;) > > Marcus > > On 6. sep. 2004, at 22.09, Sebastian Riedel wrote: > >> Status: >> >> * fix all open bugs (pager and search results, pager and list >> order...more?) >> - will do this later...(patches welcome) >> >>> * call additional_data() and authenticate() for plain templates >> >> - done >> >>> * make the templates valid XHTML >> >> - later...(someone willing to do it?) >> >>> * better documentation and more complex examples >> >> - this is going to be on the list forever ;) >> >> * mod_perl 2.0 compatibility >> - maybe done, added Apache2::MVC but have no idea if it works because >> my mod_perl2 is not yet compiled. :) >> >> * simple header interface $r->{header} (and maybe a send_header() method >> to overload?) >> - not sure about this, simon tries to convince me that we need >> HTTP::Response... >> >>> * put POST and GET data in $r->{params} and deprecate $r->query >> >> - added parse_args(), more later >> >> * Add new universal front-end that detects if it's a CGI, Apache or >> Apache2 >> - done! :) called it Maypole::Application for now >> >> * perltidy >> - later >> >> A first snapshot can be found at: >> http://files.oook.de/Maypole/Maypole-1.8.tar.gz >> >> Cheers, >> Sebastian >> >> _______________________________________________ >> maypole mailing list >> maypole@lists.netthink.co.uk >> http://lists.netthink.co.uk/listinfo/maypole >> >> >> _______________________________________________ >> maypole mailing list >> maypole@lists.netthink.co.uk >> http://lists.netthink.co.uk/listinfo/maypole > > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > From drew@tech.coop Tue Sep 7 05:33:03 2004 From: drew@tech.coop (Drew Crampsie - Software Developer) Date: Mon, 06 Sep 2004 21:33:03 -0700 Subject: [Maypole] feature idea: Automatic 'AddFrom' of has_many relationships. In-Reply-To: <413CCC0D.8090502@oook.de> References: <413A1958.3000009@oook.de> <413CC410.8030406@oook.de> <413CCC0D.8090502@oook.de> Message-ID: <413D39FF.6070500@tech.coop> Hello, I'd like to add a new feature to maypole, as it would simplify what i'm doing currently, and it seems like a good idea. For any table that has a 'has_many' relationship setup, the default view template lists all the rows in the foreign table that are related. I'd like to add a feature that takes it when step further and defines a function that will add a new row to the related table. Example: I have two tables, account and demograpic. when i do "account/view/x" i'd like a function on demographic linked from that page that does 'addnew' , but automatically populates the foreign key field 'account_id' with the account id of the currently viewed account. ie: "demographic/add_from_account/x". It seems to me that adding that functionality to Maypole::Model::CDBI would be the best bet. Then, in my current project, creating an 'add new customer' wizard would be a simple matter of creating new view templates, rather then a whole bunch of methods on the various tables involved in a new customer (which is somthing like account->demographic->delivery_account->delivery_route). Any suggestions of how to procceed to make it most useful to maypole users? Gotchas? It seems pretty simple in concept. Thanks! drewc From sri@oook.de Tue Sep 7 20:48:36 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 07 Sep 2004 21:48:36 +0200 Subject: [Maypole] Subversion Message-ID: <413E1094.4010708@oook.de> We now have a Subversion repository at http://dev.thefeed.no/repos/Apache-MVC. Thanks Marcus! Btw. I have released Maypole::Config::YAML to CPAN, i like it, maybe it's useful for someone else too... Sebastian From marcus@thefeed.no Tue Sep 7 22:02:23 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Tue, 7 Sep 2004 23:02:23 +0200 Subject: [Maypole] Subversion In-Reply-To: <413E1094.4010708@oook.de> References: <413E1094.4010708@oook.de> Message-ID: <36E2D408-0111-11D9-B3FB-000A956D773E@thefeed.no> Also, more useful for most people, a svnweb installation at http://dev.thefeed.no/svnweb/index.cgi/Apache-MVC/browse/trunk/ Marcus On 7. sep. 2004, at 21.48, Sebastian Riedel wrote: > We now have a Subversion repository at > http://dev.thefeed.no/repos/Apache-MVC. > Thanks Marcus! > > Btw. I have released Maypole::Config::YAML to CPAN, i like it, maybe > it's useful for someone else too... > > Sebastian > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole From bg271828@yahoo.com Wed Sep 8 04:14:00 2004 From: bg271828@yahoo.com (Your Name) Date: Tue, 7 Sep 2004 20:14:00 -0700 (PDT) Subject: [Maypole] Eliminating "table" from URL? Message-ID: <20040908031400.91348.qmail@web53401.mail.yahoo.com> i have an application where i dont want to have to include the table in the URL--i am using the 'main' table for everything, and anything fancy ill do in special Class::DBI code. So, id liketo have my Maypole URL's look like http://www.mysite.com/MyApp/list or http://www.mysite.com/MyApp/search?item=camera or http://www.mysite.com/MyApp/do_something_fancy instead of needing http://www.mysite.com/MyApp/catalog/list or whatever. Is there an easy way i can do this? Thanking you, Jen __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sri@oook.de Wed Sep 8 10:11:20 2004 From: sri@oook.de (Sebastian Riedel) Date: Wed, 08 Sep 2004 11:11:20 +0200 Subject: [Maypole] Eliminating "table" from URL? In-Reply-To: <20040908031400.91348.qmail@web53401.mail.yahoo.com> References: <20040908031400.91348.qmail@web53401.mail.yahoo.com> Message-ID: <413ECCB8.3060807@oook.de> Your Name: >i have an application where i dont want to have to >include the table in the URL--i am using the 'main' >table for everything, and anything fancy ill do in >special Class::DBI code. > >So, id liketo have my Maypole URL's look like > >http://www.mysite.com/MyApp/list or >http://www.mysite.com/MyApp/search?item=camera or >http://www.mysite.com/MyApp/do_something_fancy > >instead of needing > >http://www.mysite.com/MyApp/catalog/list >or whatever. > >Is there an easy way i can do this? > > Overload parse_location()... (or use mod_rewrite) >Thanking you, > >Jen > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > >_______________________________________________ >maypole mailing list >maypole@lists.netthink.co.uk >http://lists.netthink.co.uk/listinfo/maypole > > > Sebastian From teejay@droogs.org Fri Sep 10 10:47:00 2004 From: teejay@droogs.org (Aaron Trevena) Date: Fri, 10 Sep 2004 10:47:00 +0100 (BST) Subject: [Maypole] Problems with stringify and Class::DBI::FromCGI Message-ID: I have just spent a few hours tracking down an inexplicable silent death (the first I have had with CDBI or Maypole) in my Maypole application. It appears that when the validate method is called in Class::DBI::FromCGI, it is calling stringify() on the class it creates, this appeared to be happening when it tried to discover the type of the id field of my class, it would also appear that at this point warnings get swallowed. I hate this as much as I hate silent death bugs (when debugging I ensure that all the methods I suspect to be called do a warn '[package::name] method_name called..').Therefore it took a while to work out that it was my stringify method being called. So anyway, Class::DBI::FromCGI calls validate on itself, which then appears to call stringify - somebody please correct me if I am wrong, then if your stringify calls some methods on itself that fetch related objects, then you get a segfault, everytime you try and insert a new object of that class, with the code reaching the id field, attempting to call ' my $type = $them->untaint_type($field) or next; ' and dying silently, taking one of your apache processes down with it. There is a workaround for this.. I added a condition to my stringify method in the problem class before getting values from related objects, the new class is shown here : ########### package Pukka::Product; use base qw(Pukka::DBI); use Data::Dumper; __PACKAGE__->set_up_table( "product" ); __PACKAGE__->has_a( variety => 'Pukka::Variety'); __PACKAGE__->has_a( size => 'Pukka::Size'); sub stringify_self { warn "[Pukka::Product] stringify called"; my $self = shift; my $stringified = 1; if ($self->id) { my $variety = $self->variety; warn "[Pukka::Product] got variety\n"; my $size = $self->size; warn "[Pukka::Product] got size\n"; warn "[Pukka::Product] variety : $variety\n"; warn "[Pukka::Product] size : $size\n"; $stringified = join(' ',$self->{items},'x', $size->name, $variety->name); warn "[Pukka::Product] stringified : $stringified\n", } return $stringified; } 1; ########### As you can see its a fairly common construct in any catalogue type application, so this problem is likely to occur frequently where have this type of relationship between classes. Note that Pukka::Variety has_many Pukka::Product, this may contribute to the problem when validating. One final note : never ever print @_ or any variable that may refer to or possibly include $self or any code that may return $self from inside stringify - one apache mod_perl process grew to over 90 MB in a couple of seconds when I was debugging this problem and mistakenly copy & pasted a ' warn "func_name called by ", caller(), " with ", @_, "\n" ' into the stringify method. The perl compiler didn't catch the deep recursion and there were no warnings unless you checked top or noticed that your machine had slowed to a crawl. I believe there could be a fix for both of these The code that calls stringify_self could be wrapped to ensure that it doesn't call itself, warn about it and return -1 - this would be a tiny patch to CDBI and should have next to no impact on CDBI behaviour or performance. The code that gets types in CGI::Untaint (I think that could be where the problem is) needs to be more careful about stringifying objects before they are saved to the db and should stop swallowing warnings. I'm not sure entirely what is going on there and now I have a work-around I'm not inclined to spend any time in that code. Cheers, A. (learning in public so you don't have to) ps - happy to move this thread to the cdbi mailing list if people want, just thought that this problem is likely to have an impact on maypole developers which rely on Class::DBI::FromCGI heavily. -- Aaron J Trevena - Perl Hacker, Kung Fu Geek, Internet Consultant AutoDia --- Automatic UML and HTML Specifications from Perl, C++ and Any Datasource with a Handler. http://droogs.org/autodia From dhoworth@mrc-lmb.cam.ac.uk Fri Sep 10 16:27:01 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Fri, 10 Sep 2004 16:27:01 +0100 Subject: [Maypole] maypole without mod_perl? Message-ID: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> I've just discovered Maypole and want to try it. I saw from CPAN that there's a version CGI::Maypole that works without mod_perl (which I don't have) but when I try to install Maypole, the installation fails looking for mod_perl when building Apache::Request. Is it possible to install Maypole without mod_perl? Thanks and regards, Dave From dennis@sutch.com Fri Sep 10 16:33:39 2004 From: dennis@sutch.com (Dennis Sutch) Date: Fri, 10 Sep 2004 11:33:39 -0400 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> References: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> Message-ID: I haven't had much luck getting Maypole installed without mod_perl. Some time ago Simon removed the reqirement for Apache::Request so that Maypole could be installed without it. Apache::Request is only required for mod_perl, so there's no need to install it if you're using CGI::Maypole. - Dennis On Fri, 10 Sep 2004 16:27:01 +0100, Dave Howorth wrote: > I've just discovered Maypole and want to try it. I saw from CPAN that > there's a version CGI::Maypole that works without mod_perl (which I > don't have) but when I try to install Maypole, the installation fails > looking for mod_perl when building Apache::Request. > > Is it possible to install Maypole without mod_perl? > > Thanks and regards, > Dave > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > -- "Thanks to the crew of rocketscientists.ca for the gmail invitation!" http://www.rocketscientists.ca/ From dhoworth@mrc-lmb.cam.ac.uk Fri Sep 10 17:05:26 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Fri, 10 Sep 2004 17:05:26 +0100 Subject: [Maypole] maypole without mod_perl? In-Reply-To: References: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> Message-ID: <4141D0C6.6030207@mrc-lmb.cam.ac.uk> I wrote: >>Is it possible to install Maypole without mod_perl? Dennis Sutch wrote: > I haven't had much luck getting Maypole installed without mod_perl. I just found some more bad luck. Class::DBI::Plugin::Type has a broken install process (it needs DBD::SQLite). I've reported it as: Seems like Maypole is one of those packages with a huge dependency list and several of the packages have niggling problems that stop them installing. Just discovered another: DBD::SQLite won't install. A compiler error in tests again. They're stacking up :( Let's hope I can work through them and eventually get back to installing Maypole! It looks really good - I want it NOW :) Cheers, Dave From dave@riverside-cms.co.uk Fri Sep 10 17:08:09 2004 From: dave@riverside-cms.co.uk (David R. Baird) Date: Fri, 10 Sep 2004 17:08:09 +0100 Subject: [Maypole] maypole without mod_perl? In-Reply-To: References: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> Message-ID: <4141DF79.28911.B04EC4F@localhost> While we're on dependencies, Maypole also lists the Template Toolkit as a requirement. Not much fun downloading all that stuff if you want to use it with Mason, or whatever. Have you tried using 'force' to install Maypole? d. On 10 Sep 2004 at 11:33, Dennis Sutch wrote: > I haven't had much luck getting Maypole installed without mod_perl. > Some time ago Simon removed the reqirement for Apache::Request so that > Maypole could be installed without it. Apache::Request is only > required for mod_perl, so there's no need to install it if you're > using CGI::Maypole. > > - Dennis > > On Fri, 10 Sep 2004 16:27:01 +0100, Dave Howorth > wrote: > > I've just discovered Maypole and want to try it. I saw from CPAN that > > there's a version CGI::Maypole that works without mod_perl (which I > > don't have) but when I try to install Maypole, the installation fails > > looking for mod_perl when building Apache::Request. > > > > Is it possible to install Maypole without mod_perl? > > > > Thanks and regards, > > Dave > > > > _______________________________________________ > > maypole mailing list > > maypole@lists.netthink.co.uk > > http://lists.netthink.co.uk/listinfo/maypole > > > > > > -- > "Thanks to the crew of rocketscientists.ca for the gmail invitation!" > http://www.rocketscientists.ca/ > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk From brian@glassbrian.com Fri Sep 10 17:08:18 2004 From: brian@glassbrian.com (Brian Glass) Date: Fri, 10 Sep 2004 12:08:18 -0400 Subject: [Maypole] maypole without mod_perl? Message-ID: <4141D172.9030809@glassbrian.com> It works fine for me. I installed it using CGI::Maypole because I'm using Apache 2 and Maypole doesn't run on Apache 2 without some hacking. I'm also using HTML::Mason for the view class and it doesn't work under mod_perl2. I haven't had any problems with it so far and it was pretty easy to install other than there being a huge number of dependancies. From dhoworth@mrc-lmb.cam.ac.uk Fri Sep 10 17:23:47 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Fri, 10 Sep 2004 17:23:47 +0100 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141DF79.28911.B04EC4F@localhost> References: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> <4141DF79.28911.B04EC4F@localhost> Message-ID: <4141D513.3060107@mrc-lmb.cam.ac.uk> David R. Baird wrote: > While we're on dependencies, Maypole also lists the Template Toolkit > as a requirement. Not much fun downloading all that stuff if you want > to use it with Mason, or whatever. I sympathise, but not too much :) because TT2 is what I use and is one of the main reasons I want to try Maypole. > Have you tried using 'force' to install Maypole? No, I don't like to do that. The whole point of tests is to make sure something is working. If you force it, you have no idea what you've just installed and when it's going to break. I just find another package if I can't resolve failures. Cheers, Dave From dhoworth@mrc-lmb.cam.ac.uk Fri Sep 10 17:24:30 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Fri, 10 Sep 2004 17:24:30 +0100 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141D172.9030809@glassbrian.com> References: <4141D172.9030809@glassbrian.com> Message-ID: <4141D53E.5080408@mrc-lmb.cam.ac.uk> Brian Glass wrote: > It works fine for me. I installed it using CGI::Maypole because I'm > using Apache 2 and Maypole doesn't run on Apache 2 without some hacking. > I'm also using HTML::Mason for the view class and it doesn't work under > mod_perl2. > > I haven't had any problems with it so far and it was pretty easy to > install other than there being a huge number of dependancies. Did you not have broken dependencies? What's your OS/Perl config? Are you using CPAN or packages from some distro? Cheers, Dave From brian@glassbrian.com Fri Sep 10 17:50:28 2004 From: brian@glassbrian.com (Brian Glass) Date: Fri, 10 Sep 2004 12:50:28 -0400 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141D53E.5080408@mrc-lmb.cam.ac.uk> References: <4141D172.9030809@glassbrian.com> <4141D53E.5080408@mrc-lmb.cam.ac.uk> Message-ID: <4141DB54.2030106@glassbrian.com> Dave Howorth wrote: > Brian Glass wrote: > >> It works fine for me. I installed it using CGI::Maypole because I'm >> using Apache 2 and Maypole doesn't run on Apache 2 without some >> hacking. I'm also using HTML::Mason for the view class and it doesn't >> work under mod_perl2. >> >> I haven't had any problems with it so far and it was pretty easy to >> install other than there being a huge number of dependancies. > > > Did you not have broken dependencies? What's your OS/Perl config? Are > you using CPAN or packages from some distro? > > Cheers, Dave I did have a few broken dependencies. I installed from CPAN. I ended up forcing a few of them. I don't remember which they were. it probably took about 5 iterations of: perl -MCPAN -e 'install CGI::Maypole' interspersed with forced package installations. Doing it this way lets you know which packages didn't install right. After that it worked fine (aside from the fact that it took hours to figure out that I had to have a trailing backslash on my URLs). I've come to expect this sort of thing and am used to forcing things to install. I'm using Mandrake 10. From sri@oook.de Fri Sep 10 18:00:45 2004 From: sri@oook.de (Sebastian Riedel) Date: Fri, 10 Sep 2004 19:00:45 +0200 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141D172.9030809@glassbrian.com> References: <4141D172.9030809@glassbrian.com> Message-ID: <4141DDBD.1050904@oook.de> Brian Glass: > I installed it using CGI::Maypole because I'm using Apache 2 and > Maypole doesn't run on Apache 2 without some hacking. The current svn version should work fine with mod_perl2. I'll make a 1.8 release soon. (maybe with all those new features it should be called 2.0) > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > sebastian From gabor@perl.org.il Fri Sep 10 18:09:07 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Fri, 10 Sep 2004 20:09:07 +0300 (IDT) Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141D513.3060107@mrc-lmb.cam.ac.uk> References: <4141C7C5.4030106@mrc-lmb.cam.ac.uk> <4141DF79.28911.B04EC4F@localhost> <4141D513.3060107@mrc-lmb.cam.ac.uk> Message-ID: On Fri, 10 Sep 2004, Dave Howorth wrote: > > Have you tried using 'force' to install Maypole? > > No, I don't like to do that. The whole point of tests is to make sure > something is working. If you force it, you have no idea what you've just > installed and when it's going to break. consider using CPANPLUS and reporting the broken tests to the CPAN Testers and the force installing the module. This way the author will get an error message and hopefully will fix the issues soon. Then you can upgrde you package to one that installas without an error in the tests. BTW I managed to install it and I am using CGI::Maypole but I had to patch one of the files to fix the trailing slash issue. I could not find another solution. This module is actually using CGI::Maypole to display the CPANTS database: http://search.cpan.org/~szabgab/Module-CPANTS-Maypole-0.03/ patches and fixes are welcome to that module. Gabor From dave@riverside-cms.co.uk Fri Sep 10 20:21:52 2004 From: dave@riverside-cms.co.uk (David R. Baird) Date: Fri, 10 Sep 2004 20:21:52 +0100 Subject: [Maypole] maypole without mod_perl? In-Reply-To: <4141D513.3060107@mrc-lmb.cam.ac.uk> References: <4141DF79.28911.B04EC4F@localhost> Message-ID: <41420CE0.25296.BB6481E@localhost> On 10 Sep 2004 at 17:23, Dave Howorth wrote: > > Have you tried using 'force' to install Maypole? > > No, I don't like to do that. The whole point of tests is to make sure > something is working. If you force it, you have no idea what you've just > installed and when it's going to break. > > I just find another package if I can't resolve failures. I don't like to either, until I understand what the problem is. In this case, it's failing dependencies that probably shouldn't be listed as dependencies. Maypole.pm only runs 5 tests anyway. Sure, don't force blindly, but don't blindly enforce a force policy. But yes, it'd be better if the install went smoothly. d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk From sri@oook.de Fri Sep 10 21:14:05 2004 From: sri@oook.de (Sebastian Riedel) Date: Fri, 10 Sep 2004 22:14:05 +0200 Subject: [Maypole] Maypole::Utils for portability Message-ID: <41420B0D.1040402@oook.de> Just a little idea... Maybe we should provide a Maypole::Utils module full of portable helper functions that work with CGI, mod_perl1 and mod_perl2. use Maypole::Utils; $r->utils->remote_host; $r->utils->fetch_cookie(...lalala...); $r->utils->bake_cookie(...lalala...); $r->utils->add_header(...lalala...); $r->utils->header; $r->utils->param(...lalala...); This would fit very well in my concept to make everything clean and portable, which began with Maypole::Application.... sebastian From veljko.vidovic@canadair.ca Fri Sep 10 22:44:38 2004 From: veljko.vidovic@canadair.ca (Veljko Vidovic) Date: Fri, 10 Sep 2004 17:44:38 -0400 Subject: [Maypole] Re: maypole digest, Vol 1 #137 - 4 msgs References: <20040907053257.24107.68723.Mailman@alibi.simon-cozens.org> Message-ID: <000f01c4977f$5ef01690$1d1213ac@dyn.cit.canadair.ca> Hi, all I am getting this error when trying to update record: Can't update ...: Not an array reference (Date::Simple=SCALAR 0x8fcb8f0)) at /usr/local/lib/perl5/site_perl/5.6.1/DBIx/ContextualFetch.pm line 51, line 3.\n at /usr/local/lib/perl5/site_perl/5.6.1/Class/DBI/FromCGI.pm line 233\n I was looking at DBIx/ContextualFetch.pm and it seems to me there is some problem with untaint, but I can not figure out what. CGI::Untaint and CGI::Untaint::date are there, it is running on PostgreSQL and Apache 1.3 with mod_perl. Here is my table: CREATE TABLE public.supcode ( id serial NOT NULL, name char(50) NOT NULL, memo varchar(200), ddate date, CONSTRAINT supcode_pkey PRIMARY KEY (id) ) WITH OIDS; and package: package Vds::Supcode; use strict; Vds::Supcode->untaint_columns( printable => [qw/name memo/], date => [qw/ddate/] ); sub display_columns { qw(name memo ddate) } 1; Any help appreciated, Veljko From wijnand@nedbsd.nl Sat Sep 11 11:37:44 2004 From: wijnand@nedbsd.nl (Wijnand Wiersma) Date: Sat, 11 Sep 2004 12:37:44 +0200 Subject: [Maypole] still having missing slashes Message-ID: <4142D578.5090609@nedbsd.nl> This is a cryptographically signed message in MIME format. --------------ms010809090301030301050903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi List, I am finally trying maypole today and as everyone: I start with beerdb. It was pretty easy to setup but I am being trolled by an old bug: missing trailing slashes in links. I already found http://lists.netthink.co.uk/pipermail/maypole/2004-July/000489.html And the proposed patch already looks applied to me. [% MACRO link(table, command, additional, label) BLOCK; ''; label; ""; END; %] And yes, I have a trailing slash in my config: BeerDB->config->{uri_base} = "http://akroma.thuis.shady.nl/beerdb/"; Is there a new bug in town, or am I just too stupid for even maypole? Wijnand --------------ms010809090301030301050903 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCC As8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMTkwOTQ5WhcNMDUwNDEyMTkwOTQ5 WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkBFhF3 aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKTTnmG6 uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMixfyfvmZtmOIistwEMhhQb6VImcPm SRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+IdrzYHdEE+QaBGrD8ZWSEetR/uSSLOYM fm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD++rp+iRHmSBbF44Ms8A26jI5x4Nd QNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEkN9ylodODexQE3gl4U+AP7CL0GNuY FrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm1B0CAwEAAaMuMCwwHAYDVR0RBBUw E4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBB Tp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVmYoxy6d7Sq77K8VBsHiu0jDxILPEQ GzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+6hq+3kGb5Olyn+QtJkfcMvkQZF/i dvDEbZNk2b5jg5WzarIT3/JasjCCAs8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEy MTkwOTQ5WhcNMDUwNDEyMTkwOTQ5WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMSAwHgYJKoZIhvcNAQkBFhF3aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKTTnmG6uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMi xfyfvmZtmOIistwEMhhQb6VImcPmSRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+Idrz YHdEE+QaBGrD8ZWSEetR/uSSLOYMfm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD ++rp+iRHmSBbF44Ms8A26jI5x4NdQNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEk N9ylodODexQE3gl4U+AP7CL0GNuYFrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm 1B0CAwEAAaMuMCwwHAYDVR0RBBUwE4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQBBTp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVm Yoxy6d7Sq77K8VBsHiu0jDxILPEQGzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+ 6hq+3kGb5Olyn+QtJkfcMvkQZF/idvDEbZNk2b5jg5WzarIT3/JasjCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDB0OMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDkxMTEwMzc0NFowIwYJKoZIhvcNAQkEMRYE FJC2Zh6HxBViyrxV7H39L2EQyuh/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgG CSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMMHQ4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDB0OMA0GCSqGSIb3DQEBAQUABIIBACgBqi+UFHNG eeabjrcthiVT6RTb7gwfHNRrCbkJ26pO61m3jjE8JESwdz8h8SZfrNV80DfMSiToeZH3wLDh SKPmyqW3U/gqoO8Qu4rZu8mQ1K7bGnP4cgm3xYJLplt5AFmDqJOqIeTXuvtCJn/yVeRfzUXC ACZiosY2iNr+XKPuNZuURrIm/iZq6nXaTZpKlNe9ZguXJHn01AEcRuVeYQyNVJSSLnpM3axD mSgfuIgusbYrxs3Vv9BZ2qnKetr84HPAv1K9NqHpqH8l7MuCOL+keYagUAJfbi8gVCBGNAsY 1M+STKAlqxwlzclxqjA72OeKr66PXTf73oyZNrRwGOkAAAAAAAA= --------------ms010809090301030301050903-- From gabor@perl.org.il Sat Sep 11 13:47:01 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Sat, 11 Sep 2004 15:47:01 +0300 (IDT) Subject: [Maypole] CGI::Maypole trailing slashes issue Message-ID: When I was trying to setup CGI::Maypole I encountered a few issues, let me send them to the list so that either someone can explain me how to do it better or if this is the best solution then it might help oters to find the solution for their similar problemts. In my module I write: use base 'CGI::Maypole'; BEGIN { Module::CPANTS::Maypole->setup("dbi:SQLite:dbname=../../db/cpants.db"); } Module::CPANTS::Maypole->config->{uri_base} = "http://$ENV{HTTP_HOST}/"; [... rest skipped] This should be enough for the trailing slashes but then once I click on one of the table views all the new links were missing the slash between the hostname and the rest of the URL. I patched Maypole::View::Base and it works now. Here is the patch: --- /opt/perl584/lib/site_perl/5.8.4/Maypole/View/Base.pm Sat Jul 17 19:55:03 2004 +++ www/cgi/Maypole/View/Base.pm Mon Sep 6 09:39:54 2004 @@ -23,6 +23,7 @@ my $class = $r->model_class; my $base = $r->{config}->{uri_base}; $base =~ s/\/+$//; + $base .= "/"; my %args = ( request => $r, objects => $r->objects, Do I really need this patch or did I make a mistake somewhere else ? BTW if this is relevant, this is the Apache configuration I use: ServerName cpants.local DocumentRoot /web/cpants/www Alias /robots.txt /web/cpants/www/robots.txt Alias /cpants.css /web/cpants/www/cpants.css Alias /favicon.ico /web/cpants/www/favicon.ico ScriptAliasMatch ^/(.*)$ /web/cpants/www/cgi/cpants.pl/$1 Gabor From gabor@perl.org.il Sat Sep 11 14:00:04 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Sat, 11 Sep 2004 16:00:04 +0300 (IDT) Subject: [Maypole] CGI::Maypole issues (continued) Message-ID: Again, it might be only me but I needed the following things in order to make CGI::Maypole work and these were also the most difficult issues as it was hard *for me* to find documentation for these 1) put the setup in BEGIN block in order to be able to be able to use the :Exported attribute 2) override get_template_root 3) override send_output if you wan to set cookies or otherwis manipulate the header 4) The Maypole::View::Base patch I mentioned in the previous message. use base 'CGI::Maypole'; BEGIN { # must be in the BEGIN block to faciliate the attributes thing... MP->setup("dbi:SQLite:dbname=../../db/cpants.db"); } # this is not strictly CGI::Maypole issue but it can help if # the live server has differnt hostname than the development server # which is usually the case MP->config->{uri_base} = "http://$ENV{HTTP_HOST}/"; # you must provide this function in case of CGI::Maypole # and this was you don't have to worry at deployment time. sub get_template_root { if ($ENV{HTTP_HOST} eq "cpants.szabgab.com") { return "/web/cpants/www/templates"; } return "/home/gabor/cpants/www/templates"; } # override a function of CGI::Maypole in order to be able to set cookie sub send_output { my $r = shift; #warn "send_output\n"; print $r->{cgi}->header(-type => $r->{content_type}, -content_length => length $r->{output}, -cookie => $r->{cookie}, ); print $r->{output}; } All this using Maypole 1.7. Gabor From sf@flacks.net Sat Sep 11 15:16:21 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 15:16:21 +0100 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <41420B0D.1040402@oook.de> References: <41420B0D.1040402@oook.de> Message-ID: <20040911131113.M99456@flacks.net> On Fri, 10 Sep 2004 22:14:05 +0200, Sebastian Riedel wrote > Just a little idea... > > Maybe we should provide a Maypole::Utils module full of portable > helper functions that work with CGI, mod_perl1 and mod_perl2. > > use Maypole::Utils; > > $r->utils->remote_host; > $r->utils->fetch_cookie(...lalala...); > $r->utils->bake_cookie(...lalala...); > $r->utils->add_header(...lalala...); > $r->utils->header; > $r->utils->param(...lalala...); > > This would fit very well in my concept to make everything clean and > portable, which began with Maypole::Application.... I don't think it's a very portable design or will help people to write portable Maypole applications. I've already said this on the dev mailing list, but I think that param() should be a controller method, that behaves like CGI->param and Apache:: Request->param: http://shrunk.net/4c737123-lists.netthink.co.uk I don't think the proposed design is portable since it ignores the other Maypole providers: Maypole::CLI, MasonX::Maypole and Jellybean::Container:: Maypole. I think the best way you can achieve portability is for the controller to have a well-defined, but flexible API. I'm not sure what that is, but perhaps something like: $r->cookie(); $r->header(); $r->param(...); with cookie() and header() being Class::Data::Inheritable hashes of CGI:: Cookie objects and header strings. Just a thought. --simonflk From sf@flacks.net Sat Sep 11 15:31:25 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 15:31:25 +0100 Subject: [Maypole] CGI::Maypole issues (continued) In-Reply-To: References: Message-ID: <20040911142530.M33902@flacks.net> On Sat, 11 Sep 2004 16:00:04 +0300 (IDT), Gabor Szabo wrote > Again, it might be only me but I needed the following things in order > to make CGI::Maypole work and these were also the most difficult issues > as it was hard *for me* to find documentation for these > > 1) put the setup in BEGIN block in order to be able to be able > to use the :Exported attribute > 2) override get_template_root What did $r->get_template_root return? Did you try setting $r->config->{template_root} ? --simonflk From sf@flacks.net Sat Sep 11 15:41:39 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 15:41:39 +0100 Subject: [Maypole] CGI::Maypole trailing slashes issue In-Reply-To: References: Message-ID: <20040911143943.M4250@flacks.net> This patch adds a trailing slash where necessary, rather than adding it on after stripping it off. Index: trunk/lib/Maypole/View/Base.pm =================================================================== --- trunk/lib/Maypole/View/Base.pm (revision 172) +++ trunk/lib/Maypole/View/Base.pm (working copy) @@ -22,7 +22,7 @@ my ($self, $r) = @_; my $class = $r->model_class; my $base = $r->{config}->{uri_base}; - $base =~ s/\/+$//; + $base =~ s/([^\/])$/$1\//; my %args = ( request => $r, objects => $r->objects, On Sat, 11 Sep 2004 15:47:01 +0300 (IDT), Gabor Szabo wrote > When I was trying to setup CGI::Maypole I encountered a few issues, > let me send them to the list so that either someone can explain me > how to do it better or if this is the best solution then it might > help oters to find the solution for their similar problemts. > > In my module I write: > > use base 'CGI::Maypole'; > BEGIN { > Module::CPANTS::Maypole- > >setup("dbi:SQLite:dbname=../../db/cpants.db"); } > > Module::CPANTS::Maypole->config->{uri_base} = "http://$ENV{HTTP_HOST}/"; > > [... rest skipped] > This should be enough for the trailing slashes but then once I click > on one of the table views all the new links were missing the slash between > the hostname and the rest of the URL. > I patched Maypole::View::Base and it works now. > Here is the patch: > > --- /opt/perl584/lib/site_perl/5.8.4/Maypole/View/Base.pm Sat Jul 17 > 19:55:03 2004 > +++ www/cgi/Maypole/View/Base.pm Mon Sep 6 09:39:54 2004 > @@ -23,6 +23,7 @@ > my $class = $r->model_class; > my $base = $r->{config}->{uri_base}; > $base =~ s/\/+$//; > + $base .= "/"; > my %args = ( > request => $r, > objects => $r->objects, > > Do I really need this patch or did I make a mistake somewhere else ? > > BTW if this is relevant, this is the Apache configuration I use: > > > ServerName cpants.local > DocumentRoot /web/cpants/www > Alias /robots.txt /web/cpants/www/robots.txt > Alias /cpants.css /web/cpants/www/cpants.css > Alias /favicon.ico /web/cpants/www/favicon.ico > ScriptAliasMatch ^/(.*)$ /web/cpants/www/cgi/cpants.pl/$1 > > > Gabor > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole --simonflk From sri@oook.de Sat Sep 11 16:01:15 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 17:01:15 +0200 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <20040911131113.M99456@flacks.net> References: <41420B0D.1040402@oook.de> <20040911131113.M99456@flacks.net> Message-ID: <4143133B.2040908@oook.de> Simon Flack: > >I don't think it's a very portable design or will help people to write >portable Maypole applications. > >I don't think the proposed design is portable since it ignores the other >Maypole providers: Maypole::CLI, MasonX::Maypole and Jellybean::Container:: >Maypole. > Very good argument against it. >I think the best way you can achieve portability is for the >controller to have a well-defined, but flexible API. I'm not sure what that >is, but perhaps something like: > > $r->cookie(); > $r->header(); > $r->param(...); > >with cookie() and header() being Class::Data::Inheritable hashes of CGI:: >Cookie objects and header strings. > >Just a thought. > > Maybe it's best to make it separate CPAN modules, Maypole::Cookie, Maypole::Header... >--simonflk > >_______________________________________________ >maypole mailing list >maypole@lists.netthink.co.uk >http://lists.netthink.co.uk/listinfo/maypole > > > sebastian From sri@oook.de Sat Sep 11 16:08:19 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 17:08:19 +0200 Subject: [Maypole] still having missing slashes In-Reply-To: <4142D578.5090609@nedbsd.nl> References: <4142D578.5090609@nedbsd.nl> Message-ID: <414314E3.1090508@oook.de> Wijnand Wiersma: > Hi List, > > I am finally trying maypole today and as everyone: I start with beerdb. > It was pretty easy to setup but I am being trolled by an old bug: > missing trailing slashes in links. > > I already found > http://lists.netthink.co.uk/pipermail/maypole/2004-July/000489.html > > And the proposed patch already looks applied to me. > [% > MACRO link(table, command, additional, label) BLOCK; > ''; > label; > ""; > END; > %] That should look like this: '' The development version has this fixed... > > > And yes, I have a trailing slash in my config: > BeerDB->config->{uri_base} = "http://akroma.thuis.shady.nl/beerdb/"; > > Is there a new bug in town, or am I just too stupid for even maypole? > > Wijnand sebastian From sri@oook.de Sat Sep 11 16:19:28 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 17:19:28 +0200 Subject: [Maypole] CGI::Maypole trailing slashes issue In-Reply-To: <20040911143943.M4250@flacks.net> References: <20040911143943.M4250@flacks.net> Message-ID: <41431780.10809@oook.de> Simon Flack schrieb: >This patch adds a trailing slash where necessary, rather than adding it on >after stripping it off. > >Index: trunk/lib/Maypole/View/Base.pm >=================================================================== >--- trunk/lib/Maypole/View/Base.pm (revision 172) >+++ trunk/lib/Maypole/View/Base.pm (working copy) >@@ -22,7 +22,7 @@ > my ($self, $r) = @_; > my $class = $r->model_class; > my $base = $r->{config}->{uri_base}; >- $base =~ s/\/+$//; >+ $base =~ s/([^\/])$/$1\//; > my %args = ( > request => $r, > objects => $r->objects, > > >On Sat, 11 Sep 2004 15:47:01 +0300 (IDT), Gabor Szabo wrote > > >>When I was trying to setup CGI::Maypole I encountered a few issues, >>let me send them to the list so that either someone can explain me >>how to do it better or if this is the best solution then it might >>help oters to find the solution for their similar problemts. >> >>In my module I write: >> >>use base 'CGI::Maypole'; >>BEGIN { >> Module::CPANTS::Maypole- >> >> >>>setup("dbi:SQLite:dbname=../../db/cpants.db"); } >>> >>> >>Module::CPANTS::Maypole->config->{uri_base} = "http://$ENV{HTTP_HOST}/"; >> >>[... rest skipped] >>This should be enough for the trailing slashes but then once I click >>on one of the table views all the new links were missing the slash between >>the hostname and the rest of the URL. >>I patched Maypole::View::Base and it works now. >>Here is the patch: >> >>--- /opt/perl584/lib/site_perl/5.8.4/Maypole/View/Base.pm Sat Jul 17 >>19:55:03 2004 >>+++ www/cgi/Maypole/View/Base.pm Mon Sep 6 09:39:54 2004 >>@@ -23,6 +23,7 @@ >> my $class = $r->model_class; >> my $base = $r->{config}->{uri_base}; >> $base =~ s/\/+$//; >>+ $base .= "/"; >> my %args = ( >> request => $r, >> objects => $r->objects, >> >>Do I really need this patch or did I make a mistake somewhere else ? >> >>BTW if this is relevant, this is the Apache configuration I use: >> >> >> ServerName cpants.local >> DocumentRoot /web/cpants/www >> Alias /robots.txt /web/cpants/www/robots.txt >> Alias /cpants.css /web/cpants/www/cpants.css >> Alias /favicon.ico /web/cpants/www/favicon.ico >> ScriptAliasMatch ^/(.*)$ /web/cpants/www/cgi/cpants.pl/$1 >> >> >>Gabor >> >>_______________________________________________ >>maypole mailing list >>maypole@lists.netthink.co.uk >>http://lists.netthink.co.uk/listinfo/maypole >> >> > > > And again, this is already fixed in the svn version...but by modifying the template macro. >--simonflk > > >_______________________________________________ >maypole mailing list >maypole@lists.netthink.co.uk >http://lists.netthink.co.uk/listinfo/maypole > > > sebastian From wijnand@nedbsd.nl Sat Sep 11 16:30:05 2004 From: wijnand@nedbsd.nl (Wijnand Wiersma) Date: Sat, 11 Sep 2004 17:30:05 +0200 Subject: [Maypole] still having missing slashes In-Reply-To: <414314C6.9020704@oook.de> References: <4142D578.5090609@nedbsd.nl> <414314C6.9020704@oook.de> Message-ID: <414319FD.8030907@nedbsd.nl> This is a cryptographically signed message in MIME format. --------------ms020002040306030802090101 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sebastian Riedel wrote: > That should look like this: > ' '">' > > The development version has this fixed... That works, thanks. Wijnand --------------ms020002040306030802090101 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCC As8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMTkwOTQ5WhcNMDUwNDEyMTkwOTQ5 WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkBFhF3 aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKTTnmG6 uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMixfyfvmZtmOIistwEMhhQb6VImcPm SRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+IdrzYHdEE+QaBGrD8ZWSEetR/uSSLOYM fm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD++rp+iRHmSBbF44Ms8A26jI5x4Nd QNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEkN9ylodODexQE3gl4U+AP7CL0GNuY FrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm1B0CAwEAAaMuMCwwHAYDVR0RBBUw E4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBB Tp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVmYoxy6d7Sq77K8VBsHiu0jDxILPEQ GzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+6hq+3kGb5Olyn+QtJkfcMvkQZF/i dvDEbZNk2b5jg5WzarIT3/JasjCCAs8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEy MTkwOTQ5WhcNMDUwNDEyMTkwOTQ5WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMSAwHgYJKoZIhvcNAQkBFhF3aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKTTnmG6uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMi xfyfvmZtmOIistwEMhhQb6VImcPmSRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+Idrz YHdEE+QaBGrD8ZWSEetR/uSSLOYMfm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD ++rp+iRHmSBbF44Ms8A26jI5x4NdQNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEk N9ylodODexQE3gl4U+AP7CL0GNuYFrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm 1B0CAwEAAaMuMCwwHAYDVR0RBBUwE4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQBBTp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVm Yoxy6d7Sq77K8VBsHiu0jDxILPEQGzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+ 6hq+3kGb5Olyn+QtJkfcMvkQZF/idvDEbZNk2b5jg5WzarIT3/JasjCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDB0OMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDkxMTE1MzAwNVowIwYJKoZIhvcNAQkEMRYE FBXyVpOk6IRKeXjY1Oy7l2cER7mIMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgG CSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMMHQ4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDB0OMA0GCSqGSIb3DQEBAQUABIIBACKjThcvXVqx 0NvJE99eV0QJ6GpZUkctbS8hMYGz+KF9bdAMxm3hzxn7uFfLAkV+lS6AUS6kzhCItbc4DtVg 5guIyHB1P9NseI1Pam11+4NkU3RZiE0sZ0SuzMHTXKz/KCFqtVvlaPEuU7breizN2Y85t+Lo 3TtOb8LXWu3XdQbN+kPW4ew1b48LhT5NK6VibqxK6MGvAXJucjgJ8PhlO2dlN52EEDvLyf7K ub/zhCp/y0CFUoi31eMxx6UYW+HaQFWN/vJN8X+xlL2sRfFnD93ZEF8dYsud6JI5bHSpsDNI lclTLMgDgVPJiHTYdRK5nKH8e7Np+Kzo0+m0d9bpfrkAAAAAAAA= --------------ms020002040306030802090101-- From gabor@perl.org.il Sat Sep 11 17:49:54 2004 From: gabor@perl.org.il (Gabor Szabo) Date: Sat, 11 Sep 2004 19:49:54 +0300 (IDT) Subject: [Maypole] CGI::Maypole trailing slashes issue In-Reply-To: <41431780.10809@oook.de> References: <20040911143943.M4250@flacks.net> <41431780.10809@oook.de> Message-ID: thanks for both of you On Sat, 11 Sep 2004, Sebastian Riedel wrote: > And again, this is already fixed in the svn version...but by modifying > the template macro. in that case sorry for making unnecessary noise with this. I wish there was a newer version on CPAN already even in the form of a evelopment release with _01 version numbering. Gabor From sri@oook.de Sat Sep 11 18:02:50 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 19:02:50 +0200 Subject: [Maypole] CGI::Maypole trailing slashes issue In-Reply-To: References: <20040911143943.M4250@flacks.net> <41431780.10809@oook.de> Message-ID: <41432FBA.50506@oook.de> Gabor Szabo: >I wish there was a newer version on CPAN already even in the form of a >evelopment release with _01 version numbering. > > I will release a 2.0_01 when the templates are fixed and valid XHTML, so it's not far away... sebastian From sf@flacks.net Sat Sep 11 18:03:04 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 18:03:04 +0100 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <4143133B.2040908@oook.de> References: <41420B0D.1040402@oook.de> <20040911131113.M99456@flacks.net> <4143133B.2040908@oook.de> Message-ID: <20040911160202.M36769@flacks.net> This is a multi-part message in MIME format. ------=OPENWEBMAIL_ATT_0.870957576976256 Content-Type: text/plain; charset=iso-8859-1 On Sat, 11 Sep 2004 17:01:15 +0200, Sebastian Riedel wrote > Simon Flack: [snip] > > $r->cookie(); > > $r->header(); > > $r->param(...); > > > >with cookie() and header() being Class::Data::Inheritable hashes of CGI:: > >Cookie objects and header strings. > > > >Just a thought. > > > > > Maybe it's best to make it separate CPAN modules, Maypole::Cookie, > Maypole::Header... We could do, but I don't think we need to reinvent tested modules that are already on CPAN. Despite being in the CGI:: namespace, CGI::Cookie isn't dependent on CGI or mod_perl or any other environment. A new maypole provider just needs to create CGI::Cookie objects or do nothing if cookies aren't available. We could also use HTTP::Headers to represent the output headers. I've attached a patch to demonstrate. It's untested, but should work like this: $r->headers->content_type('text/plain'); $r->headers->expires(...); $r->headers->header('X-Bender', 'kiss my shiny metal ass'); $r->cookie()->{foo} = CGI::Cookie->new(-name => 'foo' -value => 'bar'); my $user_prefs = $r->cookie()->{user_prefs}; print $user_prefs->value; The headers() object and cookie() hash is initialised by Maypole.pm in handler(). So maypole providers just need to populate cookies() if applicable, and handle the headers and cookies in send_output(). --simonflk ------=OPENWEBMAIL_ATT_0.870957576976256 Content-Type: application/octet-stream; name="maypole_with_cookies_and_headers.diff" Content-Disposition: attachment; filename="maypole_with_cookies_and_headers.diff" Content-Transfer-Encoding: base64 SW5kZXg6IHRydW5rL2xpYi9BcGFjaGUvTVZDLnBtCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHRydW5rL2xpYi9B cGFjaGUvTVZDLnBtCShyZXZpc2lvbiAxNzIpCisrKyB0cnVuay9saWIvQXBhY2hlL01WQy5wbQko d29ya2luZyBjb3B5KQpAQCAtMTQsNiArMTQsNyBAQAogfQogZWxzZSB7IHJlcXVpcmUgQXBhY2hl IH0KIHJlcXVpcmUgQXBhY2hlOjpSZXF1ZXN0OwordXNlIENHSTo6Q29va2llOwogCiBvdXIgJFZF UlNJT04gPSAiMC40IjsKIApAQCAtMzAsNiArMzEsNyBAQAogICAgICRzZWxmLT57cGF0aH0gPX4g cy9eKCRsb2MpP1wvLy87CiAgICAgJHNlbGYtPnBhcnNlX3BhdGg7CiAgICAgJHNlbGYtPnBhcnNl X2FyZ3M7CisgICAgJHNlbGYtPmNvb2tpZSh7IGZldGNoIENHSTo6Q29va2llIH0pOwogfQogCiBz dWIgcGFyc2VfYXJncyB7CkBAIC00MCw4ICs0MiwyMSBAQAogCiBzdWIgc2VuZF9vdXRwdXQgewog ICAgIG15ICRyID0gc2hpZnQ7Ci0gICAgJHItPnthcn0tPmNvbnRlbnRfdHlwZSggJHItPntjb250 ZW50X3R5cGV9ICk7CisKKyAgICAjIFNldCBIVFRQIGhlYWRlcnMKKyAgICAkci0+e2FyfS0+Y29u dGVudF90eXBlKCAkci0+aGVhZGVycy0+Y29udGVudF90eXBlICk7CiAgICAgJHItPnthcn0tPmhl YWRlcnNfb3V0LT5zZXQoICJDb250ZW50LUxlbmd0aCIgPT4gbGVuZ3RoICRyLT57b3V0cHV0fSAp OworICAgIGZvcmVhY2ggKCRyLT5oZWFkZXJzLT5oZWFkZXJfZmllbGRfbmFtZXMpIHsKKyAgICAg ICAgbmV4dCBpZiAvXkNvbnRlbnQtLzsKKyAgICAgICAgJHItPnthcn0tPmhlYWRlcnNfb3V0LT5z ZXQoJF8gPT4gJHItPmhlYWRlcnMtPmhlYWRlcigkXykpOworICAgIH0KKworICAgICMgQWRkIGNv b2tpZXMKKyAgICBmb3JlYWNoIChrZXlzICV7JHItPmNvb2tpZSgpfSkgeworICAgICAgICBteSAk Y29va2llID0gJHItPmNvb2tpZS0+eyRffTsKKyAgICAgICAgJHItPnthcn0tPmhlYWRlcnNfb3V0 LT5hZGQoJ1NldC1Db29raWUnID0+ICRjb29raWUpOworICAgIH0KKwogICAgICRyLT57YXJ9LT5z ZW5kX2h0dHBfaGVhZGVyOwogICAgICRyLT57YXJ9LT5wcmludCggJHItPntvdXRwdXR9ICk7CiB9 CkluZGV4OiB0cnVuay9saWIvTWF5cG9sZS5wbQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0cnVuay9saWIvTWF5 cG9sZS5wbQkocmV2aXNpb24gMTcyKQorKysgdHJ1bmsvbGliL01heXBvbGUucG0JKHdvcmtpbmcg Y29weSkKQEAgLTUsMTIgKzUsMTMgQEAKIHVzZSBzdHJpY3Q7CiB1c2Ugd2FybmluZ3M7CiBvdXIg JFZFUlNJT04gPSAiMS44IjsKLV9fUEFDS0FHRV9fLT5ta19jbGFzc2RhdGEoJF8pIGZvciBxdygg Y29uZmlnIGluaXRfZG9uZSB2aWV3X29iamVjdCApOworX19QQUNLQUdFX18tPm1rX2NsYXNzZGF0 YSgkXykgZm9yIHF3KCBjb25maWcgaW5pdF9kb25lIHZpZXdfb2JqZWN0IGhlYWRlcnMgY29va2ll KTsKIF9fUEFDS0FHRV9fLT5ta19hY2Nlc3NvcnMgKCBxdyggYXIgcGFyYW1zIHF1ZXJ5IG9iamVj dHMgbW9kZWxfY2xhc3MKIGFyZ3MgYWN0aW9uIHRlbXBsYXRlICkpOwogX19QQUNLQUdFX18tPmNv bmZpZyh7fSk7CiBfX1BBQ0tBR0VfXy0+aW5pdF9kb25lKDApOwogdXNlIE1heXBvbGU6OkNvbnN0 YW50czsKK3VzZSBIVFRQOjpIZWFkZXJzOwogCiBzdWIgZGVidWcgeyAwIH0KIApAQCAtNTAsNiAr NTEsOCBAQAogc3ViIGhhbmRsZXIgewogICAgICMgU2VlIE1heXBvbGU6OldvcmtmbG93IGJlZm9y ZSB0cnlpbmcgdG8gdW5kZXJzdGFuZCB0aGlzLgogICAgIG15ICggJGNsYXNzLCAkcmVxICkgPSBA XzsKKyAgICAkY2xhc3MtPmhlYWRlcnMoSFRUUDo6SGVhZGVycy0+bmV3KENvbnRlbnRfVHlwZSA9 PiAndGV4dC9odG1sJykpOworICAgICRjbGFzcy0+Y29va2llKHt9KTsKICAgICAkY2xhc3MtPmlu aXQgdW5sZXNzICRjbGFzcy0+aW5pdF9kb25lOwogICAgIG15ICRyID0gYmxlc3MgeyBjb25maWcg PT4gJGNsYXNzLT5jb25maWcgfSwgJGNsYXNzOwogICAgICRyLT5nZXRfcmVxdWVzdCgkcmVxKTsK SW5kZXg6IHRydW5rL2xpYi9DR0kvTWF5cG9sZS5wbQo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSB0cnVuay9saWIv Q0dJL01heXBvbGUucG0JKHJldmlzaW9uIDE3MikKKysrIHRydW5rL2xpYi9DR0kvTWF5cG9sZS5w bQkod29ya2luZyBjb3B5KQpAQCAtMyw2ICszLDcgQEAKIAogdXNlIHN0cmljdDsKIHVzZSB3YXJu aW5nczsKK3VzZSBDR0k6OkNvb2tpZTsKIG91ciAkVkVSU0lPTiA9ICIwLjMiOwogCiBzdWIgcnVu IHsKQEAgLTIzLDYgKzI0LDcgQEAKICAgICAkc2VsZi0+e3BhdGh9ID1+IHMvXigkbG9jKT9cLy8v OwogICAgICRzZWxmLT5wYXJzZV9wYXRoOwogICAgICRzZWxmLT5wYXJzZV9hcmdzOworICAgICRz ZWxmLT5jb29raWUoeyBmZXRjaCBDR0k6OkNvb2tpZSB9KTsKIH0KIAogc3ViIHBhcnNlX2FyZ3Mg ewpAQCAtMzgsMTAgKzQwLDIxIEBACiAKIHN1YiBzZW5kX291dHB1dCB7CiAgICAgbXkgJHIgPSBz aGlmdDsKLSAgICBwcmludCAkci0+e2NnaX0tPmhlYWRlcigKLSAgICAgICAgLXR5cGUgICAgICAg ICAgID0+ICRyLT57Y29udGVudF90eXBlfSwKLSAgICAgICAgLWNvbnRlbnRfbGVuZ3RoID0+IGxl bmd0aCAkci0+e291dHB1dH0sCi0gICAgKTsKKworICAgICMgUHJpbnQgSFRUUCBoZWFkZXJzCisg ICAgJHItPmhlYWRlcnMtPmNvbnRlbnRfbGVuZ3RoKGxlbmd0aCAkci0+e291dHB1dH0pOworICAg IG15IEBoZWFkZXJfbGlzdDsKKyAgICBmb3JlYWNoICgkci0+aGVhZGVycy0+aGVhZGVyX2ZpZWxk X25hbWVzKSB7CisgICAgICAgIHB1c2ggQGhlYWRlcl9saXN0LCAiLSRfIiwgJHItPmhlYWRlcnMt PmhlYWRlcigkXyk7CisgICAgfQorCisgICAgIyBBZGQgY29va2llczsKKyAgICBteSBAY29va2ll cyA9IHZhbHVlcyAleyRyLT5jb29raWUoKX07CisgICAgaWYgKEBjb29raWVzKSB7CisgICAgICAg IHB1c2ggQGhlYWRlcl9saXN0LCAnLWNvb2tpZScsIFxAY29va2llcworICAgIH0KKworICAgIHBy aW50ICRyLT57Y2dpfS0+aGVhZGVyKEBoZWFkZXJfbGlzdCk7CiAgICAgcHJpbnQgJHItPntvdXRw dXR9OwogfQogCg== ------=OPENWEBMAIL_ATT_0.870957576976256-- From sf@flacks.net Sat Sep 11 18:19:19 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 18:19:19 +0100 Subject: [Maypole] CGI::Maypole trailing slashes issue In-Reply-To: <41431780.10809@oook.de> References: <20040911143943.M4250@flacks.net> <41431780.10809@oook.de> Message-ID: <20040911170929.M18138@flacks.net> On Sat, 11 Sep 2004 17:19:28 +0200, Sebastian Riedel wrote > Simon Flack schrieb: > > >This patch adds a trailing slash where necessary, rather than adding it on > >after stripping it off. > > > >Index: trunk/lib/Maypole/View/Base.pm > >=================================================================== > >--- trunk/lib/Maypole/View/Base.pm (revision 172) > >+++ trunk/lib/Maypole/View/Base.pm (working copy) > >@@ -22,7 +22,7 @@ > > my ($self, $r) = @_; > > my $class = $r->model_class; > > my $base = $r->{config}->{uri_base}; > >- $base =~ s/\/+$//; > >+ $base =~ s/([^\/])$/$1\//; > > my %args = ( > > request => $r, > > objects => $r->objects, > > > > [snip] > And again, this is already fixed in the svn version...but by > modifying the template macro. That's fine. I just thought it would be a good idea to keep the trailing slash on the base, because of the way that URI.pm works: This oneliner: perl -MURI -le 'print URI->new_abs("table/list", "http://127.1/maypole")' returns different things depending on the presence of a trailing slash: I thought that might be important for things like Template::Plugin::URI, but it doesn't exist. I suppose it's not a good idea to unconditionally add a trailing slash because it might not make sense for some providers. But I'm not sure it's a good thing to unconditionally remove the trailing slash either :) --simonflk From sri@oook.de Sat Sep 11 18:36:14 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 19:36:14 +0200 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <20040911160202.M36769@flacks.net> References: <41420B0D.1040402@oook.de> <20040911131113.M99456@flacks.net> <4143133B.2040908@oook.de> <20040911160202.M36769@flacks.net> Message-ID: <4143378E.4050305@oook.de> Simon Flack: > >We could do, but I don't think we need to reinvent tested modules that are >already on CPAN. Despite being in the CGI:: namespace, CGI::Cookie isn't >dependent on CGI or mod_perl or any other environment. A new maypole provider >just needs to create CGI::Cookie objects or do nothing if cookies aren't >available. We could also use HTTP::Headers to represent the output headers. > >I've attached a patch to demonstrate. It's untested, but should work like >this: > > $r->headers->content_type('text/plain'); > $r->headers->expires(...); > $r->headers->header('X-Bender', 'kiss my shiny metal ass'); > I like it, but how would you handle input headers? > $r->cookie()->{foo} = CGI::Cookie->new(-name => 'foo' -value => 'bar'); > my $user_prefs = $r->cookie()->{user_prefs}; > print $user_prefs->value; > > Having to type foo twice is a liddle bit annoying and incoming cookies will also be send out. >The headers() object and cookie() hash is initialised by Maypole.pm in >handler(). So maypole providers just need to populate cookies() if applicable, >and handle the headers and cookies in send_output(). > > but looks like a good start... sebastian From sf@flacks.net Sat Sep 11 18:48:29 2004 From: sf@flacks.net (Simon Flack) Date: Sat, 11 Sep 2004 18:48:29 +0100 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <4143378E.4050305@oook.de> References: <41420B0D.1040402@oook.de> <20040911131113.M99456@flacks.net> <4143133B.2040908@oook.de> <20040911160202.M36769@flacks.net> <4143378E.4050305@oook.de> Message-ID: <20040911174214.M27362@flacks.net> On Sat, 11 Sep 2004 19:36:14 +0200, Sebastian Riedel wrote > Simon Flack: > > > > >We could do, but I don't think we need to reinvent tested modules that are > >already on CPAN. Despite being in the CGI:: namespace, CGI::Cookie isn't > >dependent on CGI or mod_perl or any other environment. A new maypole provider > >just needs to create CGI::Cookie objects or do nothing if cookies aren't > >available. We could also use HTTP::Headers to represent the output headers. > > > >I've attached a patch to demonstrate. It's untested, but should work like > >this: > > > > $r->headers->content_type('text/plain'); > > $r->headers->expires(...); > > $r->headers->header('X-Bender', 'kiss my shiny metal ass'); > > > I like it, but how would you handle input headers? I'm not sure. Perhaps there should be a headers_in() and headers_out(). I don't really like $r->headers->header() either. I suppose you could do $r->headers->push_header() or init_header(). It would be better if it were $r->headers->set or $r->headers->add. Maybe there is a case for a Maypole:: Headers wrapper around HTTP::Headers. > > $r->cookie()->{foo} = CGI::Cookie->new(-name => 'foo' -value => 'bar'); > > my $user_prefs = $r->cookie()->{user_prefs}; > > print $user_prefs->value; > > > > > Having to type foo twice is a liddle bit annoying and incoming > cookies will also be send out. Agreed. $r->cookie()->add() / set() / get() might be nicer. Perhaps there's a case for a Maypole::Cookie wrapper too. Is it bad if incoming cookies are also sent out? I imagine that's what you'd want most of the time. > >The headers() object and cookie() hash is initialised by Maypole.pm in > >handler(). So maypole providers just need to populate cookies() if applicable, > >and handle the headers and cookies in send_output(). > > > > > but looks like a good start... > > sebastian > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole --simonflk From sri@oook.de Sat Sep 11 20:12:48 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 11 Sep 2004 21:12:48 +0200 Subject: [Maypole] Maypole::Utils for portability In-Reply-To: <20040911174214.M27362@flacks.net> References: <41420B0D.1040402@oook.de> <20040911131113.M99456@flacks.net> <4143133B.2040908@oook.de> <20040911160202.M36769@flacks.net> <4143378E.4050305@oook.de> <20040911174214.M27362@flacks.net> Message-ID: <41434E30.1060803@oook.de> Simon Flack: >Is it bad if incoming cookies are also sent out? I imagine that's what you'd want most of the time. > > It's just unnecessary... sebastian From wijnand@nedbsd.nl Sun Sep 12 00:24:58 2004 From: wijnand@nedbsd.nl (Wijnand Wiersma) Date: Sun, 12 Sep 2004 01:24:58 +0200 Subject: [Maypole] Real life examples Message-ID: <4143894A.4020600@nedbsd.nl> This is a cryptographically signed message in MIME format. --------------ms090609010905090803000602 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I asked this before, but never got a answer: Are there any live websites built in Maypole? And if so, where can I see one? Maybe it would be interesting to mention some real life examples on the maypole website or in the wiki. Is there anyone who already implemented a complete portal ala *nuke or something like that in Maypole? I like to know if it can be done in Maypole since I am already pretty far with my portal wich integrates wiki, newsgroups and maillinglists. Right now it is just plain perl code and I was hoping I could start all over again using Maypole. I also hope there will be more documentation since the current documentation doesn't look very complete. Can you guys give me some pointers to the answers to this questions? Wijnand --------------ms090609010905090803000602 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII6TCC As8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UE ChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEyMTkwOTQ5WhcNMDUwNDEyMTkwOTQ5 WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMSAwHgYJKoZIhvcNAQkBFhF3 aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKTTnmG6 uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMixfyfvmZtmOIistwEMhhQb6VImcPm SRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+IdrzYHdEE+QaBGrD8ZWSEetR/uSSLOYM fm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD++rp+iRHmSBbF44Ms8A26jI5x4Nd QNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEkN9ylodODexQE3gl4U+AP7CL0GNuY FrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm1B0CAwEAAaMuMCwwHAYDVR0RBBUw E4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQBB Tp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVmYoxy6d7Sq77K8VBsHiu0jDxILPEQ GzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+6hq+3kGb5Olyn+QtJkfcMvkQZF/i dvDEbZNk2b5jg5WzarIT3/JasjCCAs8wggI4oAMCAQICAwwdDjANBgkqhkiG9w0BAQQFADBi MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEs MCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EwHhcNMDQwNDEy MTkwOTQ5WhcNMDUwNDEyMTkwOTQ5WjBDMR8wHQYDVQQDExZUaGF3dGUgRnJlZW1haWwgTWVt YmVyMSAwHgYJKoZIhvcNAQkBFhF3aWpuYW5kQG5lZGJzZC5ubDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKTTnmG6uIUZTfboqsR6cWDqUsA4vuQUbyHiC8x94Lpnu+n/QgMi xfyfvmZtmOIistwEMhhQb6VImcPmSRBx1xB+tG02O4h3Ga0JwonO8TIVNF1I22itnrt+Idrz YHdEE+QaBGrD8ZWSEetR/uSSLOYMfm1ctE0FZqzxvxRopSiaCIqc0nplRdagOTKviNC3SUKD ++rp+iRHmSBbF44Ms8A26jI5x4NdQNVA21ZGZ3Sc9S3ffkwHbtDkOdkpF/YxdaGj6Xfw5VEk N9ylodODexQE3gl4U+AP7CL0GNuYFrK9VmdfSlZ82Swnf7gPdBoIBqFdLQcZ1FjI+JnaRgzm 1B0CAwEAAaMuMCwwHAYDVR0RBBUwE4ERd2lqbmFuZEBuZWRic2QubmwwDAYDVR0TAQH/BAIw ADANBgkqhkiG9w0BAQQFAAOBgQBBTp7NP3ygds3WRlbyDkt6vqAGusTs79cIKSoBGOZVqwVm Yoxy6d7Sq77K8VBsHiu0jDxILPEQGzKcd30qM0RkrvfkmbArV+mUNEgTdYOxx5rHEQDf/Ww+ 6hq+3kGb5Olyn+QtJkfcMvkQZF/idvDEbZNk2b5jg5WzarIT3/JasjCCAz8wggKooAMCAQIC AQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAm BgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQD EyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEF AAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B 1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79A gAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8E CDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3 dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEa MBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7M DaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUa C4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341YheILcIRk1 3iSx0x1G/11fZU8xggM7MIIDNwIBATBpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIDDB0OMAkGBSsOAwIaBQCgggGnMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA0MDkxMTIzMjQ1OFowIwYJKoZIhvcNAQkEMRYE FJSOINXNCano0Gwyufl70Qy+qMj3MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI KoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMHgG CSsGAQQBgjcQBDFrMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1 aW5nIENBAgMMHQ4wegYLKoZIhvcNAQkQAgsxa6BpMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQK ExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29u YWwgRnJlZW1haWwgSXNzdWluZyBDQQIDDB0OMA0GCSqGSIb3DQEBAQUABIIBADlwvDwZ+oIg Fqjktnq3knQ3ZrKfPEtwptw94ELlmi3vqeZR8CznVUEPzgTI/wJLIy0VbAzWhPePuO1CwXr7 YsB7qCV5AL2KH/wH9er60QI8XWknCA9afRaB6BjzlZ0m/KlteWPOPmezIzqS6u2V3hYZp2A+ nEdZKqo7y3jcaL+r5oWHXWoqJlnDBK2ZgoYCPqPPpJKX3vceOOSzvs/vWmqmBuDtiqlVRzcY FzdrBGvzXkUUdl9aOU/ZXMp2Sjn8L0S2+O0ndULuTS4AA9BBkLT4py4FKYgZvDzbAbbxR/e2 kSo9FC6lKzZVjPVzaKQd54jHp8oxzgTGRZhIxDVi4AYAAAAAAAA= --------------ms090609010905090803000602-- From sri@oook.de Sun Sep 12 02:04:22 2004 From: sri@oook.de (Sebastian Riedel) Date: Sun, 12 Sep 2004 03:04:22 +0200 Subject: [Maypole] Real life examples In-Reply-To: <4143894A.4020600@nedbsd.nl> References: <4143894A.4020600@nedbsd.nl> Message-ID: <4143A096.5000306@oook.de> Wijnand Wiersma: > I asked this before, but never got a answer: > Are there any live websites built in Maypole? And if so, where can I > see one? > Maybe it would be interesting to mention some real life examples on > the maypole website or in the wiki. Very good question! I am currently building a very big e-commerce platform for T-Systems International with Maypole, unfortunately it's an internal system, so no url. > > Is there anyone who already implemented a complete portal ala *nuke or > something like that in Maypole? > > I like to know if it can be done in Maypole since I am already pretty > far with my portal wich integrates wiki, newsgroups and maillinglists. > Right now it is just plain perl code and I was hoping I could start > all over again using Maypole. It can definately be done, and if you get used to Maypole it should be quite easy to do it. ;) > > I also hope there will be more documentation since the current > documentation doesn't look very complete. I hope that too, the current documentation constists mostly of articles and tutorials, would be great if someone writes references... I really would like to do it, but i have not that much time at the moment and am non native english speaker...bad combination... > > > Can you guys give me some pointers to the answers to this questions? > > Wijnand sebastian From simon@simon-cozens.org Sun Sep 12 10:56:39 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Sun, 12 Sep 2004 10:56:39 +0100 Subject: [Maypole] Real life examples In-Reply-To: <4143894A.4020600@nedbsd.nl> References: <4143894A.4020600@nedbsd.nl> Message-ID: <20040912095639.GA7991@alibi.simon-cozens.org> Wijnand Wiersma: > Is there anyone who already implemented a complete portal ala *nuke or > something like that in Maypole? http://maypole.simon-cozens.org/ibsportal/ See, of course, the documentation for how it was done. > I also hope there will be more documentation since the current > documentation doesn't look very complete. The current documentation stretches to about 25,000 words, or four chapters of a book. Patches are welcome. -- yes >/dev/kmem # Shutdown is broken. This'll have to do - plan9 has a bad day From wijnand@nedbsd.nl Sun Sep 12 16:49:25 2004 From: wijnand@nedbsd.nl (Wijnand Wiersma) Date: Sun, 12 Sep 2004 17:49:25 +0200 Subject: [Maypole] Real life examples In-Reply-To: <20040912095639.GA7991@alibi.simon-cozens.org> References: <4143894A.4020600@nedbsd.nl> <20040912095639.GA7991@alibi.simon-cozens.org> Message-ID: <41447005.8060605@nedbsd.nl> This is a cryptographically signed message in MIME format. --------------ms000201060509010500020603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Simon Cozens wrote: >Wijnand Wiersma: > > >>Is there anyone who already implemented a complete portal ala *nuke or >>something like that in Maypole? >> >> > >http://maypole.simon-cozens.org/ibsportal/ > >See, of course, the documentation for how it was done. > > > It's a nice start, thanks. >The current documentation stretches to about 25,000 words, or four chapters >of a book. Patches are welcome. > > Yes, but before I can submit any I have to learn how to create nice things with maypole :-) Some pages are already good, like the model classes page. But some pages still need some updates, and it looks to me they are in this same state for a long time. I also like to see some good documentation about all the possibilities of untaint_columns, and some good information about setting up relationships for tables. Wijnand --------------ms000201060509010500020603 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sm