From sri@oook.de Mon Nov 1 00:32:27 2004 From: sri@oook.de (Sebastian Riedel) Date: Mon, 01 Nov 2004 01:32:27 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099248129.2664.64.camel@localhost> References: <1099248129.2664.64.camel@localhost> Message-ID: <1099269147.5010.6.camel@localhost> Ok, another update. :) Now i've implemented pre and post actions so you can chain small code snippets from multiple classes to a pipeline. Communicating throug $r->objects() and $r->trunk() works quite well. Yes, all this goes far beyond Struts. =) Example: --- #YAML:1.0 name: Maypole PetStore root: '/home/sri/PetStore/templates' base: http://localhost/petstore models: - name: Cart - name: CDBI base: CDBI dsn: dbi:Pg:dbname=petstore user: postgres pass: 0 opts: AutoCommit: 1 views: - name: TT base: TT controllers: - name: Categories - name: Cart - name: Items - name: Products logic: - controller: cart action: view pre: - model: cart action: content post: - model: cdbi_item action: resolve_cart - controller: categories action: list pre: - model: cdbi_category - controller: items action: list pre: - model: cdbi_item - controller: products action: list pre: - model: cdbi_product auth: user_class: MyApp::Customer user_field: email session_class: Apache::Session::Postgres session_args: DataSource: dbi:Pg:dbname=petstore TableName: session UserName: postgres Password: 0 Commit: 1 sebastian From peterspeltz@yahoo.com Mon Nov 1 06:13:42 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Sun, 31 Oct 2004 22:13:42 -0800 (PST) Subject: [Maypole] Maypole::Config documentation In-Reply-To: <20041030091927.GA12514@soto.kasei.com> Message-ID: <20041101061342.29270.qmail@web52108.mail.yahoo.com> --- Tony Bowden wrote: > On Sat, Oct 30, 2004 at 02:00:07AM -0700, Peter Speltz wrote: > > ok_tables is different from display tables in that it doesn't put a tab in > the > > navbar for the table. Its very useful for private tables you want access > to, > > for example administration tables or tables you don't want a tab for and > would > > rather make a link for somewhere on certain pages. > > > > If you set it you have to add your display tables to it as well because the > > code doesn't add display tables to it if it exists. I could be wrong as it > > should add display tables to it if it exists. Anyway i use it like this: > > Actually maybe it shouldn't add display tables to ok_tables. I don't know. > > sub display tables { qw/service/ }; > > sub ok_tables { qw/service price service_pkg/ }; > > > Wouldn't it be better to have a private_tables() instead? > > sub display tables { qw/service/ }; > sub private_tables { qw/price service_pkg/ }; > > Tony > Well, private to who? Privacy is a matter of access/authorization/authentication. You need a user and maypole doesn't provide that. access_tables or accessible_tables would be better. ok_tables is easier to type and is pretty descriptive but it really means these tables are ok to acess. Since maypole revolves around providing access to tables , that may be redundant. My vote -- accessible_tables . > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > ===== pjs __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail From josenyimi@yahoo.fr Mon Nov 1 13:36:45 2004 From: josenyimi@yahoo.fr (=?iso-8859-1?q?Jos=FFffffe9=20Nyimi?=) Date: Mon, 1 Nov 2004 14:36:45 +0100 (CET) Subject: [Maypole] The Future of Maypole In-Reply-To: <1099269147.5010.6.camel@localhost> Message-ID: <20041101133645.4264.qmail@web86906.mail.ukl.yahoo.com> Considere getting some design ideas from SpringMVC and AuroraMVC. These are great frameworks applying clean MVC. Struts is a flawed framework. [References] http://www.auroramvc.org http://www.springframework.org Regards, José. --- Sebastian Riedel a écrit : > Ok, another update. :) > > Now i've implemented pre and post actions so you can > chain small code > snippets from multiple classes to a pipeline. > > Communicating throug $r->objects() and $r->trunk() > works quite well. > > Yes, all this goes far beyond Struts. =) > > Example: > > --- #YAML:1.0 > name: Maypole PetStore > root: '/home/sri/PetStore/templates' > base: http://localhost/petstore > models: > - name: Cart > - name: CDBI > base: CDBI > dsn: dbi:Pg:dbname=petstore > user: postgres > pass: 0 > opts: > AutoCommit: 1 > views: > - name: TT > base: TT > controllers: > - name: Categories > - name: Cart > - name: Items > - name: Products > logic: > - controller: cart > action: view > pre: > - model: cart > action: content > post: > - model: cdbi_item > action: resolve_cart > - controller: categories > action: list > pre: > - model: cdbi_category > - controller: items > action: list > pre: > - model: cdbi_item > - controller: products > action: list > pre: > - model: cdbi_product > auth: > user_class: MyApp::Customer > user_field: email > session_class: Apache::Session::Postgres > session_args: > DataSource: dbi:Pg:dbname=petstore > TableName: session > UserName: postgres > Password: 0 > Commit: 1 > > sebastian > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > Vous manquez d’espace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com From sri@oook.de Tue Nov 2 00:00:24 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 01:00:24 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041101133645.4264.qmail@web86906.mail.ukl.yahoo.com> References: <20041101133645.4264.qmail@web86906.mail.ukl.yahoo.com> Message-ID: <1099353624.8149.3.camel@localhost> Umm...pointless bashing at other frameworks is dumb, why is Struts flawed? What features do you like in SpringMVC/AuroraMVC and how should they be implemented? sebastian Jos=FFffffe9 Nyimi: > Considere getting some design ideas from SpringMVC and > AuroraMVC. > These are great frameworks applying clean MVC. > Struts is a flawed framework. >=20 > [References] > http://www.auroramvc.org > http://www.springframework.org >=20 > Regards, >=20 > Jos=E9. From sri@oook.de Tue Nov 2 00:10:03 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 01:10:03 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099248129.2664.64.camel@localhost> References: <1099248129.2664.64.camel@localhost> Message-ID: <1099354203.8149.12.camel@localhost> Yet another update. This time the logic stuff mutated into a plain old dispatch table. actions: cart: add: - cart: add - cart: content - cdbi_item: resolve - cdbi_product: resolve update: - cart: update - cart: content - cdbi_item: resolve - cdbi_product: resolve view: - cart: content - cdbi_item: resolve - cdbi_product: resolve Yes, it's a bit verbose, but very very simple to understand and modify. cart: add: - cart: add - cart: content - cdbi_item: resolve - cdbi_product: resolve This would be translated to something like: PetStore::Controller::Cart::add() PetStore::Model::Cart::add() PetStore::Model::Cart::content() PetStore::Model::CDBI::Item::resolve() PetStore::Model::CDBI::Product::resolve() Such a dispatch table exists for the requests lifetime and is modifyable via $r->table. And again, don't take this too serious, i'm just loud thinking... ;) sebastian From dhoworth@mrc-lmb.cam.ac.uk Tue Nov 2 09:43:27 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Tue, 02 Nov 2004 09:43:27 +0000 Subject: [Maypole] Maypole::Config documentation In-Reply-To: <20041101061342.29270.qmail@web52108.mail.yahoo.com> References: <20041101061342.29270.qmail@web52108.mail.yahoo.com> Message-ID: <418756BF.5090505@mrc-lmb.cam.ac.uk> I have two personalities here :) The first personality just wrote a proposed documentation change to reflect what I understood Sebastian said about the purpose of ok_tables. I don't care what we decide it means, as long as we're clear! And indeed, prompting this discussion is already a healthy and useful result. The second personality does software design :) It seems to me that what Peter is trying to do revolves entirely around access control. Whether a user should be able to see a price or change a price or even be aware that something has a price is something that should be handled by an authorization component. Once it's decided what a user is entitled to, display_tables can be populated accordingly (and ok_tables can be derived automatically as a cache), edit buttons can be provided or not as appropriate etc. I haven't looked at authorization in Maypole at all, so I have no idea how much or little of this is provided. Granted the templates would need an upgrade. So my long term perspective would be that Peter's requirements would be better met another way than using ok_tables. But in the short term, Peter has code that depends on users being allowed to manipulate ok_tables, and I have no idea whether there's a better way he could use right now? Switching back to my first persona ... On the basis of the information I have right now, I'd suggest saying: This is a hash of the public tables that is available to templates. Normally, it is populated automatically by Maypole from the list in display_tables. Presently, users can instead load a list of tables into this attribute, which must include at least all those tables in the display_tables list. This facility is liable to be replaced in some future release by an authorization-based mechanism. Cheers, Dave From dhoworth@mrc-lmb.cam.ac.uk Tue Nov 2 09:53:54 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Tue, 02 Nov 2004 09:53:54 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099248129.2664.64.camel@localhost> References: <1099248129.2664.64.camel@localhost> Message-ID: <41875932.2030607@mrc-lmb.cam.ac.uk> Sebastian Riedel wrote: > So i began to reimplement Maypole from scratch. (really) WOW! > --- #YAML:1.0 > name: Maypole PetStore > root: '/home/sri/PetStore/templates' > base: http://localhost/petstore > models: > - name: CDBI > base: CDBI > dsn: dbi:Pg:dbname=petstore > user: postgres > pass: 0 > opts: > AutoCommit: 1 > views: > - name: TT > base: TT > controllers: > - name: Categories > - name: Cart > - name: Items > - name: Products > logic: > - controller: categories > action: list > rules: > - model: cdbi_category > auth: > user_class: MyApp::Customer > user_field: email > session_class: Apache::Session::Postgres > session_args: > DataSource: dbi:Pg:dbname=petstore > TableName: session > UserName: postgres > Password: 0 > Commit: 1 This looks great; very exciting. > Well, name, root, base and auth are self explaining. I think template_root is self explanatory, but not root. (a fortiori, is 'extension' self explanatory?). Come to that, uri_base and application_name tell me more about what they mean as well. > The models, views and controllers sections are there to define the > class layout of our application. > > models: > - name: CDBI > base: CDBI > dsn: dbi:Pg:dbname=petstore > user: postgres > pass: 0 > opts: > AutoCommit: 1 > > Yes, it's an array, and so as much models as you want are supported. ;) Excellent. > The name will be internally translated to the class "MyApp::Model::CDBI" > and will get "Maypole::Model::CDBI" as it's base class. Where does "MyApp" come from? > The other options will be passed to the setup() method of > "MyApp::Model::CDBI". > > Internally we never use class names (we are lazy), so we have aliases. > "CDBI" becomes "cdbi", "MyApp::Model::CDBI::Stuff" becomes "cdbi_stuff". I don't like this, even though it may mean less typing. It means that everybody has to keep the extra transformation in mind in their head. It's sowing confusion and doubt - what does SuperModel become? Anglic peoples aren't so used to concatenating words and extracting the meaning intuitively. I'd prefer to have just one name for something and use it everywhere, so I can see at first glance what it means. I guess a compromise might be to declare the aliases explicitly in the config file? > Maypole::Model::CDBI's setup() automatically creates and loads > subclasses for your tables and registers them with aliases. What happened to my choice of loader? I need this back please. > Exactly the same thing happens for views and controllers. (Yes, even > setup() gets called for them) Great. > === Logic === > > The core of all this is logic, it's an intelligent and dynamic internal > mapping between controllers and models. Now this I really like. > logic: > - controller: categories > action: list > rules: > - model: cdbi_category > > This small example means that when someone requests > http://localhost/categories/list not only > MyApp::Controller::Categories::list() will be called but also > MyApp::Model::CDBI::Category::list() (and possibly more models and > actions if you define them). > > In fact MyApp::Controller::Categories::list() doesn't even have to exist > as method, as soon as its defined in logic it's automatically exported. > > The current set of available logic options is not yet finished...so > there is much room for cool features. > > logic: > - controller: categories > action: list > rules: > - model: cdbi_category > pre: > - first_post > post: > - i_am_late > - i_am_the_last > > Right now i'm thinking about pre and post actions, so the model actions > could be called before and after the controller ones. > > Controllers, Models and Views don't communicate directly, they use > $r->objects and $r->trunk to exchange informations. What's $r->trunk? What can a model see? What must it see? > Views can be dynamically switched by setting > $r->view('some_view_alias'). Excellent. > So it's very very simple to switch between TT2, Mason or a YAML > Serializer. ;) > > === END === > > Now the best thing, this is not pseudo code, i already implemented all > this! > You can grab a (not yet very clean) snapshot at > http://files.oook.de/PetStore.tar.gz > > That should be enough to make your heads explode, but there are many > more changes to be exposed! =) > > Feedback is very welcome, even when it's "WOW!" or "You Moron!". WOW! > sebastian Dave From dhoworth@mrc-lmb.cam.ac.uk Tue Nov 2 10:02:19 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Tue, 02 Nov 2004 10:02:19 +0000 Subject: [Maypole] text formatting In-Reply-To: <20041029153354.GA19788@alibi.simon-cozens.org> References: <41825E01.3080704@mrc-lmb.cam.ac.uk> <20041029153354.GA19788@alibi.simon-cozens.org> Message-ID: <41875B2B.2090606@mrc-lmb.cam.ac.uk> I wrote: > I have a question about text formatting in Maypole. If the value of a > field in the database is text in which the spaces and especially line > breaks are significant, how is it handled by Maypole? Simon Cozens replied: > It isn't handled. That's a templating issue. Maypole doesn't really > care what you display, whether it's HTML, plain text, or whatever. > That's not part of its remit. > No, you just need to change your templates from, say, > [% beer.description %] > to > [% beer.description | html_line_break %] > > You are using your own custom templates, aren't you? Well, no, I'm not yet. The issue that occurs to me with regard to your suggestion is m*n complexity versus m+n. That is, I think there's a layer of abstraction missing; namely data types. Database types are clearly much too coarse-grained for purposes other than storage (other purposes like input, manipulation and display, for example). Yet I may have more than one column in a database with the same object type (or I may reuse somebody else's object type). The proper place for display formatting of a type is certainly within the type's view logic, but I'd argue that it is better placed in a Perl module than in macros or whatever in a template. Indeed, CDBI already has inflation logic if only I can get it to play nicely with Maypole and TT. How do you write a single template function that can display any type of object correctly? Or are you suggesting that there should be different templates for every combination of field types? That sounds like a maintenance nightmare. I can certainly see an argument that the html_line_break filter should be applied to *all* TEXT fields! I can't see why anybody would insert a newline into a database value if they didn't want it to be preserved and displayed. I'll try that as a solution to this specific problem. Thanks, Dave From simon@simon-cozens.org Tue Nov 2 10:34:12 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 10:34:12 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099354203.8149.12.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> Message-ID: <20041102103412.GA21814@alibi.simon-cozens.org> Sebastian Riedel: > actions: > cart: > add: > - cart: add Cool, you seem to have turned Maypole into exactly the kind of thing I wanted to avoid. Any chance of coming up with a new name for this project? -- Just imagine we are meeting the aliens for the first time. Most people would just shoot them to see how many points they are worth. From simon@simon-cozens.org Tue Nov 2 10:36:08 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 10:36:08 +0000 Subject: [Maypole] text formatting In-Reply-To: <41875B2B.2090606@mrc-lmb.cam.ac.uk> References: <41825E01.3080704@mrc-lmb.cam.ac.uk> <20041029153354.GA19788@alibi.simon-cozens.org> <41875B2B.2090606@mrc-lmb.cam.ac.uk> Message-ID: <20041102103608.GB21814@alibi.simon-cozens.org> Dave Howorth: > > You are using your own custom templates, aren't you? > > Well, no, I'm not yet. That's essentially the problem right there. > Or are you suggesting that there should be different > templates for every combination of field types? That sounds like a > maintenance nightmare. I'm assuming that when you write an application, you know what types of data your objects have, and hence you can write your templates accordingly. Apologies if that's a broken assumption and your application is full of data that you have no idea about. -- int three = 128+64, two = 128, one=64; - plan9 has a bad day From sri@oook.de Tue Nov 2 12:45:56 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 13:45:56 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102103412.GA21814@alibi.simon-cozens.org> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> Message-ID: <1099399556.9177.8.camel@localhost> Simon Cozens: > Sebastian Riedel: > > actions: > > cart: > > add: > > - cart: add > > Cool, you seem to have turned Maypole into exactly the kind of thing I wanted > to avoid. > > Any chance of coming up with a new name for this project? > I expected this answear. =) What are the reasons you wanted to avoid this? And yes, there is a very good chance it gets it's own name, since i don't make big changes to Maypole unless the majority want's them... sebastian From simon@simon-cozens.org Tue Nov 2 13:33:17 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 13:33:17 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099399556.9177.8.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> Message-ID: <20041102133317.GC21814@alibi.simon-cozens.org> Sebastian Riedel: > What are the reasons you wanted to avoid this? If you have both configuration (of actions) and code for actions, you're duplicating information. Not duplicating information is the first rule of good programming. I would like Maypole to continue being good programming. :) -- "Even if you're on the right track, you'll get run over if you just sit there." -- Will Rogers From sri@oook.de Tue Nov 2 15:21:19 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 16:21:19 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102133317.GC21814@alibi.simon-cozens.org> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> Message-ID: <1099408879.9732.64.camel@localhost> Simon Cozens: > Sebastian Riedel: > > What are the reasons you wanted to avoid this? > > If you have both configuration (of actions) and code for actions, you're > duplicating information. Not duplicating information is the first rule of good > programming. I would like Maypole to continue being good programming. :) > Right, i absolutely hate duplication too! Let me convince you that this is good programming. When we say... actions: cart: add: - cart: add - cart: content - cdbi_item: resolve - cdbi_product: resolve ...it means that our engine "tries" to run... PetStore::Controller::Cart::add() PetStore::Model::Cart::add() PetStore::Model::Cart::content() PetStore::Model::CDBI::Item::resolve() PetStore::Model::CDBI::Product::resolve() ...but it doesn't matter if PetStore::Controller::Cart::add() exists, it can be completely virtual. (controller actions are automatically exported when they appear in config) In fact, this approach is much more about code reuse, since you group code snippets from different models to actions. actions: cart: add: - cart: add - cart: content - cdbi_item: resolve - cdbi_product: resolve update: - cart: update - cart: content - cdbi_item: resolve - cdbi_product: resolve view: - cart: content - cdbi_item: resolve - cdbi_product: resolve This is just an example but you see... PetStore::Model::Cart::content() PetStore::Model::CDBI::Item::resolve() PetStore::Model::CDBI::Product::resolve() ...are reused. Some would say this is a bit AOP like. ;) I would really like to push blueprint driven development and design patterns. For example we could make the CRUD stuff a blueprint with a set of baseclasses, people could begin to design their applications around. name: My Maypole CRUD root: '/home/sri/CRUD/templates' base: http://localhost/crud models: - name: Stuff base: CRUD dsn: dbi:Pg:dbname=petstore user: postgres pass: 0 opts: AutoCommit: 1 views: - name: MyTT base: TT controllers: - name: MyFoo base: CRUD This class definition would generate something like this. (pseudocode to visualize) We assume the CRUD model to default to a CDBI loader, loading the two tables foo and bar. # Controller package MyApp::Controller::MyFoo; use base 'Maypole::Controller::CRUD'; # Model package MyApp::Model::Stuff; use base 'Maypole::Model::CRUD'; package MyApp::Model::Stuff::Foo; use base 'Maypole::Model::Stuff'; package MyApp::Model::Stuff::Bar; use base 'Maypole::Model::Stuff'; # View package MyApp::View::MyTT; use base 'Maypole::View::TT'; Maypole::Controller::CRUD would define the basic action sets while Maypole::Model::CRUD provides the snippets to modify the data. Extending this blueprint would be as easy as, "create this file",... package MyApp::Model::Stuff::Foo; sub my_list { my ($self, $r) = @_; $r->objects([__PACKAGE__->retrieve_all]); } ...(it will be automatically required), "then a new virtual action"... actions: crud: my_list: - stuff_foo: do_some_built_in_things - stuff_foo: my_list ..."and finally a my_list template for the tt view"... [% FOR thing = objects %] Thing: [% thing %] [% END %] The biggest problem is that you have to rethink, you no more do stuff on tables, you do it on controllers. So http://localhost/crud/table/list would become http://localhost/crud/list/table Dynamic dispatching based on arguments like the table name would happen in "real actions" in the controller. sebastian From simon@simon-cozens.org Tue Nov 2 15:27:24 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 15:27:24 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099408879.9732.64.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> Message-ID: <20041102152724.GA11648@alibi.simon-cozens.org> > Some would say this is a bit AOP like. ;) > I would really like to push blueprint driven development and design > patterns. I'm sure you know what you're doing. -- "The elder gods went to Suggoth and all I got was this lousy T-shirt." From peterspeltz@yahoo.com Tue Nov 2 17:23:57 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Tue, 2 Nov 2004 09:23:57 -0800 (PST) Subject: [Maypole] Weird listing if stringify_self specified. Message-ID: <20041102172357.36152.qmail@web52103.mail.yahoo.com> I have a person class and on the list it puts the value returned for stringify self for the mid_name column or first_name column depending on whether i use the Person::stingify_self method or Person->columns( Stringify=> ..). When i take them I get the correct values in the listing. Here's what it looks like with Stingify set. Person ID First Name Mid Name Last Name -------------------------------------------------- 4 Peter Peter Joe Speltz Speltz Here is my person class: package My::Person; use Class::Date (); use strict; use warnings; __PACKAGE__->columns('Primary' => 'prsn_id' ); __PACKAGE__->untaint_columns( printable => [ qw/first_name mid_name last_name/ ], date => [ "dob" ] ); sub stringify_self { # with this, i get listing above my $self = shift; join (" " , ($self->first_name, $self->mid_name, $self->last_name) ); } # With this, mid name is correct in listing above but first name is # Peter/Joe/Speltz #__PACKAGE__->columns('Stringify' => qw/first_name mid_name last_name/ ); # returns true if prsn is senior citizen sub is_senior_cit { my $self = shift; return 1 if ($self->dob <= ( Class::Date::now - '65Y' ) ); return 0; } 1; thanks ===== pjs __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From sri@oook.de Tue Nov 2 18:46:04 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 19:46:04 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102152724.GA11648@alibi.simon-cozens.org> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> <20041102152724.GA11648@alibi.simon-cozens.org> Message-ID: <1099421164.10078.14.camel@localhost> Simon Cozens: > > Some would say this is a bit AOP like. ;) > > I would really like to push blueprint driven development and design > > patterns. > > I'm sure you know what you're doing. > Some more productive critics would be nice... I for one think the AOP pattern fits, since we have the ability to extend our actions with new functionality by just adding a model dependency, even at runtime. And how i imagine blueprints sould be clear too... Currently you start all your Maypole applications with the CRUD example, it is hardwired into the model. Wouldn't it be nicer to start with something that's more like the endresult? For example when you want to develop a shopping cart, why start with CRUD? Why not using the PetStore? sebastian From simon@simon-cozens.org Tue Nov 2 18:56:50 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 18:56:50 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099421164.10078.14.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> <20041102152724.GA11648@alibi.simon-cozens.org> <1099421164.10078.14.camel@localhost> Message-ID: <20041102185650.GA27271@alibi.simon-cozens.org> Sebastian Riedel: > Currently you start all your Maypole applications with the CRUD example, > it is hardwired into the model. This is utterly, utterly untrue. The CRUD model is there to help you, to inherit from, to use if you want. I hardly ever use the methods it provides. In the last Maypole application I wrote, I think I only used one of its methods (view) and only for one of the classes. I've said it before, and I'll say it again, but shipping default templates which do the right thing was probably the biggest mistake I made with Maypole, because them people expect the default templates to do the right thing for *every* application, and so they start by using the default templates and attempting to mould their application around them. Don't do this. I've lost count of the number of times I've told people not to do this, but they still do it. And now even you, the maintainer of the code, seems to think that this is the way people should be writing Maypole applications currently. It's not true. Try writing a bunch more Maypole applications first, and you might discover it too. Throw away the default templates, for heaven's sake. They only seem to cause confusion. Try writing an application without them. You'll get it done much quicker and easier. Please, please, call your new project something other than Maypole; you've already adequately demonstrated that you don't understand how Maypole works, so I don't really want my legacy to be redesigned according to your fallacy. -- 3rd Law of Computing: Anything that can go wr fortune: Segmentation violation -- Core dumped From sri@oook.de Tue Nov 2 19:35:01 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 20:35:01 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102185650.GA27271@alibi.simon-cozens.org> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> <20041102152724.GA11648@alibi.simon-cozens.org> <1099421164.10078.14.camel@localhost> <20041102185650.GA27271@alibi.simon-cozens.org> Message-ID: <1099424101.10078.52.camel@localhost> Simon Cozens: > Sebastian Riedel: > > Currently you start all your Maypole applications with the CRUD example, > > it is hardwired into the model. > > This is utterly, utterly untrue. The CRUD model is there to help you, to > inherit from, to use if you want. I hardly ever use the methods it provides. > In the last Maypole application I wrote, I think I only used one of its > methods (view) and only for one of the classes. > > I've said it before, and I'll say it again, but shipping default templates > which do the right thing was probably the biggest mistake I made with Maypole, > because them people expect the default templates to do the right thing for > *every* application, and so they start by using the default templates and > attempting to mould their application around them. > > Don't do this. I've lost count of the number of times I've told people not to > do this, but they still do it. > > And now even you, the maintainer of the code, seems to think that this is the > way people should be writing Maypole applications currently. It's not true. > Try writing a bunch more Maypole applications first, and you might discover it > too. > > Throw away the default templates, for heaven's sake. They only seem to cause > confusion. Try writing an application without them. You'll get it done much > quicker and easier. > > Please, please, call your new project something other than Maypole; you've > already adequately demonstrated that you don't understand how Maypole works, > so I don't really want my legacy to be redesigned according to your fallacy. > Oh thats sooo wrong... I absolutely agree about the factory templates and CRUD methods, it totally sucks to build applications around them. BUT! Reusing sane working code is a very nice thing. And so i designed the new framework for exactly that purpose, you can specifically pick the snippets you want and group them to actions. See my notes about clean separation of model-acions. You don't have to use blueprints, they are just additional base classes, it is absolutely painless not to use them. ;) Oh, and here is a nice name suggestion i got from Mark Thomas: > How about Windmill? It's a bit like a maypole, only a lot bigger, more > powerful and spins in a different direction :) sebastian From simon@simon-cozens.org Tue Nov 2 19:41:33 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 2 Nov 2004 19:41:33 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099424101.10078.52.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> <20041102152724.GA11648@alibi.simon-cozens.org> <1099421164.10078.14.camel@localhost> <20041102185650.GA27271@alibi.simon-cozens.org> <1099424101.10078.52.camel@localhost> Message-ID: <20041102194133.GA31854@alibi.simon-cozens.org> Sebastian Riedel: > I absolutely agree about the factory templates and CRUD methods, it > totally sucks to build applications around them. Yes, Maypole is much nicer if you don't do that. It even does what you think you want. :) -- "If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234 From sri@oook.de Tue Nov 2 20:04:39 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 21:04:39 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <41875932.2030607@mrc-lmb.cam.ac.uk> References: <1099248129.2664.64.camel@localhost> <41875932.2030607@mrc-lmb.cam.ac.uk> Message-ID: <1099425879.10078.57.camel@localhost> Dave Howorth: > Sebastian Riedel wrote: > > So i began to reimplement Maypole from scratch. (really) > > WOW! > > > --- #YAML:1.0 > > name: Maypole PetStore > > root: '/home/sri/PetStore/templates' > > base: http://localhost/petstore > > models: > > - name: CDBI > > base: CDBI > > dsn: dbi:Pg:dbname=petstore > > user: postgres > > pass: 0 > > opts: > > AutoCommit: 1 > > views: > > - name: TT > > base: TT > > controllers: > > - name: Categories > > - name: Cart > > - name: Items > > - name: Products > > logic: > > - controller: categories > > action: list > > rules: > > - model: cdbi_category > > auth: > > user_class: MyApp::Customer > > user_field: email > > session_class: Apache::Session::Postgres > > session_args: > > DataSource: dbi:Pg:dbname=petstore > > TableName: session > > UserName: postgres > > Password: 0 > > Commit: 1 > > This looks great; very exciting. > > > Well, name, root, base and auth are self explaining. > > I think template_root is self explanatory, but not root. > (a fortiori, is 'extension' self explanatory?). Come to that, uri_base > and application_name tell me more about what they mean as well. Well, template_root doesn't sound right anymore, since we removed all TT2 slang. Could be called additional_files_root or something like that. :) We'll decide later... > > > The name will be internally translated to the class "MyApp::Model::CDBI" > > and will get "Maypole::Model::CDBI" as it's base class. > > Where does "MyApp" come from? You still need a MyApp.pm package PetStore; use strict; use Maypole::Application qw(-Debug Config::YAML Authentication::Abstract Component -Setup); use Maypole::Constants; sub authenticate { my $r = shift; return OK if $r->parent; $r->public; return OK; } 1; > > > The other options will be passed to the setup() method of > > "MyApp::Model::CDBI". > > > > Internally we never use class names (we are lazy), so we have aliases. > > "CDBI" becomes "cdbi", "MyApp::Model::CDBI::Stuff" becomes "cdbi_stuff". > > I don't like this, even though it may mean less typing. It means that > everybody has to keep the extra transformation in mind in their head. > It's sowing confusion and doubt - what does SuperModel become? Anglic > peoples aren't so used to concatenating words and extracting the meaning > intuitively. I'd prefer to have just one name for something and use > it everywhere, so I can see at first glance what it means. > > I guess a compromise might be to declare the aliases explicitly in the > config file? > Shouldn't be a big problem since you normally don't access other namespaces directly. You just pass around your data in $r->objects and $r->trunk from model-action to model-action and modify it. > > Maypole::Model::CDBI's setup() automatically creates and loads > > subclasses for your tables and registers them with aliases. > > What happened to my choice of loader? I need this back please. Should be easy to port other loaders... > > > Exactly the same thing happens for views and controllers. (Yes, even > > setup() gets called for them) > > Great. > > > === Logic === > > > > The core of all this is logic, it's an intelligent and dynamic internal > > mapping between controllers and models. > > Now this I really like. Replaced by actions, see my other posts. =) > > > logic: > > - controller: categories > > action: list > > rules: > > - model: cdbi_category > > > > This small example means that when someone requests > > http://localhost/categories/list not only > > MyApp::Controller::Categories::list() will be called but also > > MyApp::Model::CDBI::Category::list() (and possibly more models and > > actions if you define them). > > > > In fact MyApp::Controller::Categories::list() doesn't even have to exist > > as method, as soon as its defined in logic it's automatically exported. > > > > The current set of available logic options is not yet finished...so > > there is much room for cool features. > > > > logic: > > - controller: categories > > action: list > > rules: > > - model: cdbi_category > > pre: > > - first_post > > post: > > - i_am_late > > - i_am_the_last > > > > Right now i'm thinking about pre and post actions, so the model actions > > could be called before and after the controller ones. > > > > Controllers, Models and Views don't communicate directly, they use > > $r->objects and $r->trunk to exchange informations. > > What's $r->trunk? $r->trunk eq $r->template_args Getting rid of TT2 slang...but it's also used to pass data from model action to model action, everything that doesn't fit in objects should go to the trunk. > > What can a model see? What must it see? > It should only see: $r->objects $r->trunk $r->params $r->args But it can see and interact with everything. > > Views can be dynamically switched by setting > > $r->view('some_view_alias'). > > Excellent. > > > So it's very very simple to switch between TT2, Mason or a YAML > > Serializer. ;) > > > > === END === > > > > Now the best thing, this is not pseudo code, i already implemented all > > this! > > You can grab a (not yet very clean) snapshot at > > http://files.oook.de/PetStore.tar.gz > > > > That should be enough to make your heads explode, but there are many > > more changes to be exposed! =) > > > > Feedback is very welcome, even when it's "WOW!" or "You Moron!". > > WOW! > > > sebastian > > Dave > > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole sebastian From publiustemp-maypole2@yahoo.com Tue Nov 2 20:06:04 2004 From: publiustemp-maypole2@yahoo.com (Ovid) Date: Tue, 2 Nov 2004 12:06:04 -0800 (PST) Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102185650.GA27271@alibi.simon-cozens.org> Message-ID: <20041102200604.70675.qmail@web60804.mail.yahoo.com> --- Simon Cozens wrote: > Throw away the default templates, for heaven's sake. They only seem > to cause confusion. What about splitting the difference and offering them as a separate package/download/whatever? That way, they're still available for those who want them, but it can be made more clear that they are not actually Maypole. Cheers, Ovid ===== Silence is Evil http://users.easystreet.com/ovid/philosophy/decency.html Ovid http://www.perlmonks.org/index.pl?node_id=17000 Web Programming with Perl http://users.easystreet.com/ovid/cgi_course/ From tony@kasei.com Tue Nov 2 20:27:59 2004 From: tony@kasei.com (Tony Bowden) Date: Tue, 2 Nov 2004 20:27:59 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099424101.10078.52.camel@localhost> References: <1099248129.2664.64.camel@localhost> <1099354203.8149.12.camel@localhost> <20041102103412.GA21814@alibi.simon-cozens.org> <1099399556.9177.8.camel@localhost> <20041102133317.GC21814@alibi.simon-cozens.org> <1099408879.9732.64.camel@localhost> <20041102152724.GA11648@alibi.simon-cozens.org> <1099421164.10078.14.camel@localhost> <20041102185650.GA27271@alibi.simon-cozens.org> <1099424101.10078.52.camel@localhost> Message-ID: <20041102202758.GA2073@soto.kasei.com> On Tue, Nov 02, 2004 at 08:35:01PM +0100, Sebastian Riedel wrote: > > How about Windmill? It's a bit like a maypole, only a lot bigger, more > > powerful and spins in a different direction :) I'm sure there's some parallel to be drawn here with Cervantes needing to kill off Quixote to stop the imposters destroying the legacy... But instead I'll just boggle at the concept of a windmill, tilted at or otherwise, being anything like a maypole. Hmmm. Yesterday was Beltane in the southern hemisphere ... do they use maypoles there? And if they do, do they have to call them novemberpoles? Tony From sri@oook.de Tue Nov 2 20:28:28 2004 From: sri@oook.de (Sebastian Riedel) Date: Tue, 02 Nov 2004 21:28:28 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041102200604.70675.qmail@web60804.mail.yahoo.com> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> Message-ID: <1099427308.10078.64.camel@localhost> Ovid: > --- Simon Cozens wrote: > > Throw away the default templates, for heaven's sake. They only seem > > to cause confusion. > > What about splitting the difference and offering them as a separate > package/download/whatever? That way, they're still available for those > who want them, but it can be made more clear that they are not actually > Maypole. That's the blueprint idea. ;) sebastian From kconnor@proofpoint.com Tue Nov 2 21:27:59 2004 From: kconnor@proofpoint.com (Kevin Connor) Date: Tue, 02 Nov 2004 13:27:59 -0800 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099427308.10078.64.camel@localhost> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> Message-ID: <4187FBDF.10805@proofpoint.com> $.02 or so. I checked out Maypole exactly because it used TT and CDBI. I don't want to move away from those technologies or even abstract away from them. Frameworks are often unnecessarily abstract such that it's hard to figure out where the rubber hits the road. It's difficult enough to figure out how a column gets rendered as html or which columns get displayed or why no data is retrieved in a query. As far as the default templates go, I found them immensely useful as a reference implementation. I don't think I would've gotten anywhere without them. Shipping without them would have been a bad idea IMHO. They're great for testing, demos, and learning. I'm not sold on the YAML configuration idea. I'd rather work with perl modules and templates. -Kevin From matt.adams@morcor.com Tue Nov 2 21:37:37 2004 From: matt.adams@morcor.com (Matt Adams) Date: Tue, 02 Nov 2004 16:37:37 -0500 Subject: [Maypole] Problems using Maypole::Plugin::Component Message-ID: <4187FE21.7040300@morcor.com> Hello: I've set up Maypole::Plugin::Component like this: use Maypole::Application qw(-Debug Config::YAML Authentication::Abstract Component -Setup); And am trying to use it within a template: [% request.component("/ntable/list/?arg=12345"); %] but instead of the expected output I end up getting the following error: caught view error: Can't call method "document_root" on an undefined value at /www/trunk/lib/Apache/MVC.pm line 57, line 14. Can't call method "document_root" on an undefined value at /www/trunk/lib/Apache/MVC.pm line 57, line 14. ...caught at /www/trunk/lib/Maypole/View/Base.pm line 74, line 14. Any thoughts or suggestions as to how I might fix this would be greatly appreciated. I've overloaded &MyApp::parse_path if it helps at all. ntable gets mapped to an actual table name and $self->{table} set appropriately. Thank you in advance, Matt -- Matt Adams Development Specialist Morcor Solutions Inc. (613) 354-2912 x228 GnuPG public key at Key fingerprint: BED5 B4F7 CCF5 D7B5 7C56 0505 9A0A A0FB C937 5975 From sri@oook.de Tue Nov 2 23:35:38 2004 From: sri@oook.de (Sebastian Riedel) Date: Wed, 03 Nov 2004 00:35:38 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <4187FBDF.10805@proofpoint.com> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> Message-ID: <1099438538.11234.19.camel@localhost> Kevin Connor: > $.02 or so. > > I checked out Maypole exactly because it used TT and CDBI. I don't want > to move away from those technologies or even abstract away from them. > Frameworks are often unnecessarily abstract such that it's hard to > figure out where the rubber hits the road. It's difficult enough to > figure out how a column gets rendered as html or which columns get > displayed or why no data is retrieved in a query. TT2 and CDBI are still the default. But now it's simple to use alternatives. For example imagine you want a REST interface. Just add this to your maypole.yaml views: - name: REST base: REST::YAML and this to your controller or additional_data $r->view('rest') if $r->params->{rest}; And you have a working REST service using a YAML serializer. (Maypole::View::REST::YAML does not yet exist, but would just serialize $r->objects and/or $r->trunk to $r->output) > > As far as the default templates go, I found them immensely useful as a > reference implementation. I don't think I would've gotten anywhere > without them. Shipping without them would have been a bad idea IMHO. > They're great for testing, demos, and learning. > Wouldn't it be great to have multiple of those demos, and be able to remove those demos once you're used to Maypole? > I'm not sold on the YAML configuration idea. I'd rather work with perl > modules and templates. > Thats the best thing, if you don't like it you don't have to use it. The YAML configuration is just a Plugin. $r->config->views([{ name => 'REST', base => 'REST::YAML' }]); sebastian From peterspeltz@yahoo.com Tue Nov 2 23:55:45 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Tue, 2 Nov 2004 15:55:45 -0800 (PST) Subject: [Maypole] Maypole::Config documentation In-Reply-To: <418756BF.5090505@mrc-lmb.cam.ac.uk> Message-ID: <20041102235545.87889.qmail@web52108.mail.yahoo.com> --- Dave Howorth wrote: > > I have two personalities here :) > > The first personality just wrote a proposed documentation change to > reflect what I understood Sebastian said about the purpose of ok_tables. > I don't care what we decide it means, as long as we're clear! And > indeed, prompting this discussion is already a healthy and useful result. > > The second personality does software design :) It seems to me that what > Peter is trying to do revolves entirely around access control. Yes. Access control. > user should be able to see a price or change a price or even be aware > that something has a price is something that should be handled by an > authorization component. No. Not an authorization component. Access control. Access is just worried about access. Not who is accessing it. I'm not sure how to say it but What maypole does with ok_tables is perfect except maybe it should have been called accessible_tables. Dave, Maypole::Manual::Request has a great example of authorization/authentication in Maypole. Its a good system. Basically you make override "sub authenticate{ }" in your Controller. Thats the front door -- check cookie, redirect to login page, and return OK to let them in. Then each table (model class) can have a sub_authenticate to specify further authorization. Its cool and easy. >Once it's decided what a user is entitled to, > display_tables can be populated accordingly (and ok_tables can be > derived automatically as a cache), edit buttons can be provided or not > as appropriate etc. I haven't looked at authorization in Maypole at all, > so I have no idea how much or little of this is provided. Granted the > templates would need an upgrade. > > So my long term perspective would be that Peter's requirements would be > better met another way than using ok_tables. But in the short term, > Peter has code that depends on users being allowed to manipulate > ok_tables, and I have no idea whether there's a better way he could use > right now? > I believe i confused everyone as i was confused til now. My requirements really are to have a 1. To be able to say what tables i want access to. (ok_tables) 2. To specify which business objects I want on the navigation system. (display_tables) Maypole kindly does that perfectly. I keep finding its nicer and nicer all the time. Now i haven't browsed the code for calls to display tables but i've only seen it in 2 places: if ok_tables isn't set, it gets called and it gets called to set config->{display_tables}. AS far as i can tell, its sole purpose for existing is to provide a configuration for the navigation system. In conclusion, ok_tables, display_tables are perfect how they are. these nicities make putting a simple database web app together more fun and faster. Check out this site i built in a day. I didn't want anything fancy just a simple tool for my club. www.mtsubiodiesel.org. Well, thats Probably too much analysis for anyone's good and i'm sorry for that. > Switching back to my first persona ... > > On the basis of the information I have right now, I'd suggest saying: > > This is a hash of the public tables that is available to templates. > Normally, it is populated automatically by Maypole from the list in > display_tables. Presently, users can instead load a list of tables into > this attribute, which must include at least all those tables in the > display_tables list. This facility is liable to be replaced in some > future release by an authorization-based mechanism. > > Cheers, Dave > I would say this: display_tables -- list of tables you may want to put links to in your navigation system. Usually these are the primary business objects. These are passed to the templates in the config->{display_tables} elements. An example of its use is in the factory templates navbar. These tables become the navigation tabs in that template. This is primarily a nicity to aid in constructing your navigation system. ok_tables -- list of accessible tables on our website. If a table is not in ok_tables and you go to "host/table/whatever" , you will get a not found error. If this is not specified in your Controller class, then display_tables is used as a fall back. If you specify this, you must add the tables in display tables to the list as well. > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > ===== pjs __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From tony@kasei.com Wed Nov 3 23:00:42 2004 From: tony@kasei.com (Tony Bowden) Date: Wed, 3 Nov 2004 23:00:42 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <4187FBDF.10805@proofpoint.com> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> Message-ID: <20041103230042.GA1006@soto.kasei.com> On Tue, Nov 02, 2004 at 01:27:59PM -0800, Kevin Connor wrote: > I checked out Maypole exactly because it used TT and CDBI. I don't want > to move away from those technologies or even abstract away from them. I agree. I'd much rather see Maypole get even more entwined with them. When you head in the opposite direction you can no longer play to the things that make the various components different - you have to reduce everything to lowest common denominator. I see a lot of scope for Maypole to exploit lots more features of TT, for example. Rather than having all the default templates that we currently have, we could push more and more of this stuff further into VIEWs, MACROs and Plugins, so that the default templates become lighter and lighter, such that there's a much smoother learning curve for moving from them to building your own. But if we need to work with lots of other templating systems as well, this becomes harder and harder to do, and the framework becomes blander and blander. Maypole should really just be the framework that says: "If you want to build a website with Class::DBI and Template::Toolkit, then here's a framework that'll get rid of all the boring repetitive bits for you, and free you up to concentrate on the stuff that makes your site unique" If Maypole decides to become something other than this, then someone else still really needs to make what I've just described. Tony From perrin@elem.com Thu Nov 4 00:06:11 2004 From: perrin@elem.com (Perrin Harkins) Date: Wed, 03 Nov 2004 19:06:11 -0500 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041103230042.GA1006@soto.kasei.com> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> Message-ID: <1099526770.3418.128.camel@localhost.localdomain> On Wed, 2004-11-03 at 18:00, Tony Bowden wrote: > On Tue, Nov 02, 2004 at 01:27:59PM -0800, Kevin Connor wrote: > > I checked out Maypole exactly because it used TT and CDBI. I don't want > > to move away from those technologies or even abstract away from them. > > I agree. I'd much rather see Maypole get even more entwined with them. > When you head in the opposite direction you can no longer play to the > things that make the various components different - you have to reduce > everything to lowest common denominator. I tend to agree that the more your framework does everything, the more it does nothing. In other words, the advantage that is gained from using a framework is diminished by making it so general that the path to setting up a basic app with all the defaults becomes long and the documentation becomes stretched too thin. You can try to mitigate this problem by defining careful interfaces for ambitious people who want to use them to plug in something else, but only providing examples and code for a specific set of choices. This seems to be the approach with Maypole so far. Incidentally, as the youngest kid on the block, it might be a good idea for Maypole to check out what some of the more mature MVC frameworks for Perl have done about things like abstraction and declarative programming. Both OpenInteract (http://http://openinteract.org/) and Apache::PageKit (http://pagekit.org/) have been around for a while and significant applications have been built with them. They have both chosen the tightly coupled route for the most part. Integration with SPOPS allows OI to do some interesting security things, but is also a liability for people who are used to Class::DBI. OI 2.0 is experimenting with the declarative approach. (It uses the ini files style, which I find much clearer and more trustworthy than YAML, but that's ultimately beside the point.) - Perrin From peterspeltz@yahoo.com Thu Nov 4 00:12:58 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Wed, 3 Nov 2004 16:12:58 -0800 (PST) Subject: [Maypole] column_names override not being called sometimes Message-ID: <20041104001258.48160.qmail@web52101.mail.yahoo.com> I use Model/CDBI base class. sometimes seemingly sporadically, its column_names sub is called instead of my sub class's column_names sub. I've pinpointed one thing that triggers this in one class. If a stingify_self sub or columns('Stringify' => qw/...) is set in the class. Has anyone else encountered this? ===== pjs __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From sri@oook.de Thu Nov 4 01:03:39 2004 From: sri@oook.de (Sebastian Riedel) Date: Thu, 04 Nov 2004 02:03:39 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099526770.3418.128.camel@localhost.localdomain> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> Message-ID: <1099530219.16984.33.camel@localhost> Perrin Harkins: > On Wed, 2004-11-03 at 18:00, Tony Bowden wrote: > > On Tue, Nov 02, 2004 at 01:27:59PM -0800, Kevin Connor wrote: > > > I checked out Maypole exactly because it used TT and CDBI. I don't want > > > to move away from those technologies or even abstract away from them. > > > > I agree. I'd much rather see Maypole get even more entwined with them. > > When you head in the opposite direction you can no longer play to the > > things that make the various components different - you have to reduce > > everything to lowest common denominator. I still believe in both, flexible abstraction and tight integration. Don't know if you looked at my other notes about Maypole3 plans but the api is flexible enough to use most advanced features of CDBI/TT and also abstract enough to support all kinds of exotic components (YAML REST, SAP, LDAP, SPOPS, toasters, coffee machines...whatever...) > > I tend to agree that the more your framework does everything, the more > it does nothing. In other words, the advantage that is gained from > using a framework is diminished by making it so general that the path to > setting up a basic app with all the defaults becomes long and the > documentation becomes stretched too thin. > > You can try to mitigate this problem by defining careful interfaces for > ambitious people who want to use them to plug in something else, but > only providing examples and code for a specific set of choices. This > seems to be the approach with Maypole so far. Right, i'm trying to address that problem with blueprints, simple but well thought out exchangeable demo applications that are just a set of base classes (and maybe templates...). > > Incidentally, as the youngest kid on the block, it might be a good idea > for Maypole to check out what some of the more mature MVC frameworks for > Perl have done about things like abstraction and declarative > programming. Both OpenInteract (http://http://openinteract.org/) and > Apache::PageKit (http://pagekit.org/) have been around for a while and > significant applications have been built with them. They have both > chosen the tightly coupled route for the most part. Integration with > SPOPS allows OI to do some interesting security things, but is also a > liability for people who are used to Class::DBI. OI 2.0 is > experimenting with the declarative approach. I know both in depth and still think we can do it better... Not only them...i also studied the other kids (Struts, Ruby-on-Rails, Spring Framework...)...and stole a lot of ideas from them... ;) But i'm not just trying to bring Struts (or "insert favorite framework here") to Perl, with the next incarnation of Maypole (currently called "Catalyst") i will add some really new featuress. (like mixing MVC with Aspect Oriented Programming) > (It uses the ini files > style, which I find much clearer and more trustworthy than YAML, but > that's ultimately beside the point.) Our YAML loader is just aplugin...you can replace it with whatever you want... > > - Perrin > > sebastian From peterspeltz@yahoo.com Thu Nov 4 01:39:30 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Wed, 3 Nov 2004 17:39:30 -0800 (PST) Subject: [Maypole] Re: create_from_cgi question In-Reply-To: <20041104010319.GA3490@soto.kasei.com> Message-ID: <20041104013930.41353.qmail@web52106.mail.yahoo.com> --- Tony Bowden wrote: > On Wed, Nov 03, 2004 at 02:34:10PM -0800, Peter Speltz wrote: > > For an example: I have one big employee form with person, usr, and employee > > fields. employee has a prsn and usr. So i want to say something like > > There's been talk a few times of having Class::DBI's normal create() be > able to take arguments for related classes as well, and do the right > thing. Nothing's really ever come of it, but if it did, then this may > help with your problem (rather than trying to handle it in > create_from_cgi itself). Don't you think that would be useful in create_from_cgi? Here's a typical example of how it would be useful. I'll take a crack at coding it RIGHT AWAY if you think it would have a chance of making it in the distro as i need this functionality all the time. A user of the system is adding a new customer. the customer has a user_id field to tell who entered that customer. (Say the mean boss wants to put a stop to people entering data in the wrong format so he's tracking who enters what.) The user_id is known in the session and not a field in the form. We could add hidden usr_id field to the form but that doesn't work in cases like my first example where the foreign object must be created first and that's stupid anyway. So, the ideal solution would be to add an additional field to the create_from_cgi which would allow you to use it like this: my $customer = Customer->create_from_cgi( $h => { additional => {user_id => $session->usr_id} } ); Then you get the power of FromCGI with the freedom of CDBI::create. The docs would change like so: $film->update_from_cgi($h => { all => \@all_columns, # auto-filled if left blank ignore => \@cols_to_ignore, required => \@cols_needed, additional => \%cols_and_values_not_in_form }); ===== pjs __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From simon@simon-cozens.org Thu Nov 4 07:34:25 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Thu, 4 Nov 2004 07:34:25 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099526770.3418.128.camel@localhost.localdomain> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> Message-ID: <20041104073425.GA5697@alibi.simon-cozens.org> Perrin Harkins: > Incidentally, as the youngest kid on the block, it might be a good idea > for Maypole to check out what some of the more mature MVC frameworks for > Perl have done about things like abstraction and declarative > programming. I don't mean to sound head-in-the-sand, but this is a mistake; if you do this, then you become very tempted to go mad and redesign your framework to steal what you think are the cool features of everyone else's frameworks. Not necessarily for any technical merit, either, just to keep up with the neighbours. I'm bitterly disappointed about the way Maypole is going, but that's life - it isn't mine any more. -- I've looked at the listing, and it's right! -- Joel Halpern From peterspeltz@yahoo.com Thu Nov 4 07:43:55 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Wed, 3 Nov 2004 23:43:55 -0800 (PST) Subject: [Maypole] template_root should support an array ref Message-ID: <20041104074355.1404.qmail@web52102.mail.yahoo.com> Just curious why config->template_root doesn't take an array ref as TT does when specifying "INCLUDE_PATH". ===== pjs __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com From sri@oook.de Thu Nov 4 09:20:19 2004 From: sri@oook.de (Sebastian Riedel) Date: Thu, 04 Nov 2004 10:20:19 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041104073425.GA5697@alibi.simon-cozens.org> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> Message-ID: <1099560019.17313.10.camel@localhost> Simon Cozens: > Perrin Harkins: > > Incidentally, as the youngest kid on the block, it might be a good idea > > for Maypole to check out what some of the more mature MVC frameworks for > > Perl have done about things like abstraction and declarative > > programming. > > I don't mean to sound head-in-the-sand, but this is a mistake; if you do this, > then you become very tempted to go mad and redesign your framework to steal > what you think are the cool features of everyone else's frameworks. Not > necessarily for any technical merit, either, just to keep up with the > neighbours. > > I'm bitterly disappointed about the way Maypole is going, but that's life - it > isn't mine any more. > Hey, i'm not developing Maypole any further, the rewrite is now a subproject named "Catalyst"...Maypole will stay like it is...(you decide if thats good or bad...) We will see who makes the race... sebastian From sf@flacks.net Thu Nov 4 12:09:04 2004 From: sf@flacks.net (Simon Flack) Date: Thu, 4 Nov 2004 12:09:04 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099560019.17313.10.camel@localhost> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> Message-ID: <20041104114602.M68965@flacks.net> On Thu, 04 Nov 2004 10:20:19 +0100, Sebastian Riedel wrote > Simon Cozens: > > Perrin Harkins: > > > Incidentally, as the youngest kid on the block, it might be a good idea > > > for Maypole to check out what some of the more mature MVC frameworks for > > > Perl have done about things like abstraction and declarative > > > programming. > > > > I don't mean to sound head-in-the-sand, but this is a mistake; if you do this, > > then you become very tempted to go mad and redesign your framework to steal > > what you think are the cool features of everyone else's frameworks. Not > > necessarily for any technical merit, either, just to keep up with the > > neighbours. > > > > I'm bitterly disappointed about the way Maypole is going, but that's life - it > > isn't mine any more. > > > > Hey, i'm not developing Maypole any further, the rewrite is now a > subproject named "Catalyst"...Maypole will stay like it is...(you decide > if thats good or bad...) I think this is a shame. It seems to me that there have been a lot of developments and backwardly incompatible changes in the last month or so. And so soon after the 2.0 release there's already talk of more widespread changes to the framework. How is anyone to take Maypole seriously and invest in time learning and developing with it when it's in such flux? I'd love to see Maypole settle down. Maypole needs to be more defined. What are its goals and aims? What is outside the scope of Maypole? I'd like to see better documentation and unit tests. I'd like to see growing user confidence in Maypole. IMO, it's time to think about whether we need a Maypole 3 and what should be in it *only* after all these things are resolved. Is anyone willing to take over maintainership if Maypole is abandoned? FWIW, I'll throw my hat into the ring. --simonflk From tony@kasei.com Thu Nov 4 12:18:45 2004 From: tony@kasei.com (Tony Bowden) Date: Thu, 4 Nov 2004 12:18:45 +0000 Subject: [Maypole] Re: create_from_cgi question In-Reply-To: <20041104013930.41353.qmail@web52106.mail.yahoo.com> References: <20041104010319.GA3490@soto.kasei.com> <20041104013930.41353.qmail@web52106.mail.yahoo.com> Message-ID: <20041104121845.GA13471@soto.kasei.com> On Wed, Nov 03, 2004 at 05:39:30PM -0800, Peter Speltz wrote: > So, the ideal solution would be to add an additional field to the > create_from_cgi which would allow you to use it like this: > my $customer = Customer->create_from_cgi( $h => { additional => {user_id => $session->usr_id} } ); > Then you get the power of FromCGI with the freedom of CDBI::create. The docs > would change like so: > $film->update_from_cgi($h => { > all => \@all_columns, # auto-filled if left blank > ignore => \@cols_to_ignore, > required => \@cols_needed, > additional => \%cols_and_values_not_in_form > }); I tend to do that by adding those values into what will become $h in your example, before ever calling update_from_cgi with it... Tony From dhoworth@mrc-lmb.cam.ac.uk Thu Nov 4 15:50:52 2004 From: dhoworth@mrc-lmb.cam.ac.uk (Dave Howorth) Date: Thu, 04 Nov 2004 15:50:52 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041104114602.M68965@flacks.net> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> <20041104114602.M68965@flacks.net> Message-ID: <418A4FDC.6050403@mrc-lmb.cam.ac.uk> Sebastian Riedel: >>Hey, i'm not developing Maypole any further, the rewrite is now a >>subproject named "Catalyst"...Maypole will stay like it is...(you decide >>if thats good or bad...) Simon Flack: > I think this is a shame. It seems to me that there have been a lot of > developments and backwardly incompatible changes in the last month or so. And > so soon after the 2.0 release there's already talk of more widespread changes > to the framework. How is anyone to take Maypole seriously and invest in time > learning and developing with it when it's in such flux? > > I'd love to see Maypole settle down. Maypole needs to be more defined. What > are its goals and aims? What is outside the scope of Maypole? I'd like to see > better documentation and unit tests. I'd like to see growing user confidence > in Maypole. IMO, it's time to think about whether we need a Maypole 3 and what > should be in it *only* after all these things are resolved. > > Is anyone willing to take over maintainership if Maypole is abandoned? FWIW, > I'll throw my hat into the ring. Here's my 2p as a new would-be user of Maypole, FWIW. I came to Maypole with some experience of TT and CGI, a little of DBI, absolutely zero of CDBI or mod_perl. I don't have any problem with the idea of building my own templates, which Tony suggested might be a difficulty; the current ones seem pretty simple (I just happen to disagree with Simon C that it's the right answer to the specific problem I was and am trying to solve). The learning curves I did have difficulty with were CDBI, including all the additional packages in its namespace, and the organization of Maypole's model, request and initialisation. I'm starting to get a handle on the CDBI family and appreciate it. It's a large group of packages that has to be learnt, but it's mature, there's reasonable documentation and a good mailing list. I was attracted to Maypole by the apparent fit to one part of my design space (front-ending a database), by the simplicity of the Beer example and by the supporting docs. But I'm finding I still have trouble understanding how the central structures fit together - there are significant holes in the deeper documentation and the mailing list is patchy. Offsetting this, it's a much newer product and I accept there will be difficulties because of that, but I still worry about its readiness for real-life use. I said in response to Sebastian's first call for future priorities that I believe documenting and stabilising what's already there has to be top priority. So I wholeheartedly agree with what Simon F wrote as to the current state and the future direction. My reaction to the current state of flux has been to download OpenInteract and see what it can do for me :) If Sebastian wants to concentrate on developing a new version and was truly serious that he does not intend developing/maintaining the current iteration, then I think that responsibility would be better transferred to Simon F. Cheers, Dave From simon@simon-cozens.org Thu Nov 4 16:01:18 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Thu, 4 Nov 2004 16:01:18 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <418A4FDC.6050403@mrc-lmb.cam.ac.uk> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> <20041104114602.M68965@flacks.net> <418A4FDC.6050403@mrc-lmb.cam.ac.uk> Message-ID: <20041104160118.GC10988@alibi.simon-cozens.org> Dave Howorth: > Here's my 2p as a new would-be user of Maypole, FWIW. > ... > If Sebastian wants to concentrate on developing a new version and was > truly serious that he does not intend developing/maintaining the current > iteration, then I think that responsibility would be better transferred > to Simon F. That would be my 2p as the original author too. :) -- Thermodynamics in a nutshell: 1st Law: You can't win. (Energy is conserved) 2nd Law: You can't break even. (Entropy) 0th Law: You can't even quit the game. (Closed systems) -- Taki Kogoma From sri@oook.de Thu Nov 4 16:50:58 2004 From: sri@oook.de (Sebastian Riedel) Date: Thu, 04 Nov 2004 17:50:58 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041104160118.GC10988@alibi.simon-cozens.org> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> <20041104114602.M68965@flacks.net> <418A4FDC.6050403@mrc-lmb.cam.ac.uk> <20041104160118.GC10988@alibi.simon-cozens.org> Message-ID: <1099587058.17817.17.camel@localhost> Simon Cozens: > Dave Howorth: > > Here's my 2p as a new would-be user of Maypole, FWIW. > > ... > > If Sebastian wants to concentrate on developing a new version and was > > truly serious that he does not intend developing/maintaining the current > > iteration, then I think that responsibility would be better transferred > > to Simon F. > > That would be my 2p as the original author too. :) > Mutiny on the Bounty... =) I just said i won't "develop" it any further, nothing about giving up maintenance, but now that i think about it, seems like a good idea. Maybe you want to restart with 1.7 on CPAN? ;) So i pass the hat to whoever wants to take it and concentrate on the development of Catalyst. Maybe someone wants to adopt my Plugins too? Since they'll be ported to Catalyst and only maintained in that branch... sebastian From perrin@elem.com Thu Nov 4 16:56:46 2004 From: perrin@elem.com (Perrin Harkins) Date: Thu, 04 Nov 2004 11:56:46 -0500 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041104073425.GA5697@alibi.simon-cozens.org> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> Message-ID: <1099587406.3418.156.camel@localhost.localdomain> On Thu, 2004-11-04 at 02:34, Simon Cozens wrote: > I don't mean to sound head-in-the-sand, but this is a mistake I can't imagine what could sound more head-in-the-sand than an unwillingness to look at how other people have solved common problems. - Perrin From chromatic+maypole@wgz.org Thu Nov 4 18:37:35 2004 From: chromatic+maypole@wgz.org (chromatic) Date: Thu, 04 Nov 2004 10:37:35 -0800 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099587406.3418.156.camel@localhost.localdomain> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> Message-ID: <1099593455.2297.4.camel@localhost> On Thu, 2004-11-04 at 08:56, Perrin Harkins wrote: > I can't imagine what could sound more head-in-the-sand than an > unwillingness to look at how other people have solved common problems. I took it more as a warning that adding features that other frameworks have because they look cool and not because they solve any real problems that you have tends to lead to over-abstracted code. -- c From sri@oook.de Thu Nov 4 18:57:04 2004 From: sri@oook.de (Sebastian Riedel) Date: Thu, 04 Nov 2004 19:57:04 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099593455.2297.4.camel@localhost> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> <1099593455.2297.4.camel@localhost> Message-ID: <1099594624.19041.9.camel@localhost> chromatic: > On Thu, 2004-11-04 at 08:56, Perrin Harkins wrote: > > > I can't imagine what could sound more head-in-the-sand than an > > unwillingness to look at how other people have solved common problems. > > I took it more as a warning that adding features that other frameworks > have because they look cool and not because they solve any real problems > that you have tends to lead to over-abstracted code. Doesn't solving a real problem make features look cool in the first place? And is there something like over-abstraction? I see bad code allday, but it's always about not enough abstraction and spaghetti code, do you really know of an actual example for over-abstraction? sebastian From perrin@elem.com Thu Nov 4 19:09:24 2004 From: perrin@elem.com (Perrin Harkins) Date: Thu, 04 Nov 2004 14:09:24 -0500 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099593455.2297.4.camel@localhost> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> <1099593455.2297.4.camel@localhost> Message-ID: <1099595363.3418.188.camel@localhost.localdomain> On Thu, 2004-11-04 at 13:37, chromatic wrote: > I took it more as a warning that adding features that other frameworks > have because they look cool and not because they solve any real problems > that you have tends to lead to over-abstracted code. And yet it was a response to my post about the advantages of tight-coupling and keeping things simple. I'm well aware of how feature creep and too much abstraction can make a project hard to use, but I don't think that pretending Maypole is the first or only Perl MVC framework really benefits anyone. - Perrin From tony@kasei.com Thu Nov 4 19:45:53 2004 From: tony@kasei.com (Tony Bowden) Date: Thu, 4 Nov 2004 19:45:53 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099595363.3418.188.camel@localhost.localdomain> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> <1099593455.2297.4.camel@localhost> <1099595363.3418.188.camel@localhost.localdomain> Message-ID: <20041104194553.GA21277@soto.kasei.com> On Thu, Nov 04, 2004 at 02:09:24PM -0500, Perrin Harkins wrote: > I don't think that pretending Maypole is the first or only Perl MVC > framework really benefits anyone. This is another of the reasons why I prefer frameworks that say "If you want to do X and Y, using A, B, and C, then use me" over frameworks that say "No matter what you want to do, or what you want to use underneath, use me". Nothing can be everything to everyone. Yet too many frameworks try, and end up being used by almost no-one other than the person who wrote it. Frameworks are *hard*. They're much more about philosophy than technology. Early design mistakes get magnified dramatically, in direct proportion to the level of abstraction you're aiming at. A framework should never abstract away anything you haven't done the long way at least 3 times, or preferably more. I consulted for a company once who had what we came to call "three legged cow syndrome". They had developed a basic content management system that, like many of these things, had morphed into a product that could, of course, do anything any client (and particularly any potential client) wanted. And every time a client came with a request for something the system didn't already do, they tweaked the system so that it could do that in future. After all, that's just good practice. Of course, each time they did this, they implemented a hybrid of generic and specific requirements because they couldn't know the difference. Because the first client who ever wanted a certain feature had certain business rules associated with how that feature would work, the code assumed that everyone client who wanted that feature must work the same way. But of course, every client's process was different. And, almost invariably, insane. It's the nature of business systems. They evolve over time to account for all manner of foibles. As technologists we want to simplify these things, and refactor them all away. But almost every real-world business has bizarrely crippled logic to their business rules. They're all three legged cows. And every client who did things differently to the first client was then treated as if they were insane. Because everyone knows you don't do that like /that/ - you do it like /this/. The only known way around this syndrome is to implement the first client's additions as a standalone plugin. Then the second time someone comes in with something similar do the same, based on what you've learned the first time. The third time you can begin to factor out the commonality. Cautiously. Tony From simon@simon-cozens.org Fri Nov 5 01:17:04 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Fri, 5 Nov 2004 01:17:04 +0000 Subject: [Maypole] The Future of Maypole In-Reply-To: <1099587406.3418.156.camel@localhost.localdomain> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> Message-ID: <20041105011704.GD10988@alibi.simon-cozens.org> Perrin Harkins: > On Thu, 2004-11-04 at 02:34, Simon Cozens wrote: > > I don't mean to sound head-in-the-sand, but this is a mistake > > I can't imagine what could sound more head-in-the-sand than an > unwillingness to look at how other people have solved common problems. I didn't say anything about not *looking* at it. Sheesh. -- You can't have everything... where would you put it? -- Steven Wright From teejay@droogs.org Fri Nov 5 09:47:07 2004 From: teejay@droogs.org (Aaron Trevena) Date: Fri, 5 Nov 2004 09:47:07 +0000 (GMT) Subject: [Maypole] The Future of Maypole In-Reply-To: <1099594624.19041.9.camel@localhost> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099587406.3418.156.camel@localhost.localdomain> <1099593455.2297.4.camel@localhost> <1099594624.19041.9.camel@localhost> Message-ID: On Thu, 4 Nov 2004, Sebastian Riedel wrote: > Doesn't solving a real problem make features look cool in the first > place? And is there something like over-abstraction? In answer to the first - depends on the person and their background. In answer to the second - yes, look at many Java or .Net applications and you will see a great deal of it. I have recently worked on a monster project in Perl that was over abstracted and over-engineered. > I see bad code allday, but it's always about not enough abstraction and > spaghetti code, do you really know of an actual example for > over-abstraction? You can always abstract and refactor bad code, it can be harder to simplify over-engineered code, especially once its in production. I would always lean towards simplicity over abstraction, using the latter only when needed rather than as a rule. A. -- 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 marcus@thefeed.no Fri Nov 12 22:23:28 2004 From: marcus@thefeed.no (Marcus Ramberg) Date: Fri, 12 Nov 2004 23:23:28 +0100 Subject: [Maypole] (no subject) Message-ID: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> So, it seems to me like we need a maintainer, since people were not happy with SRI working with Catalyst and maintaining Maypole at the same time. Simon Flack has been set up as a suggestion, but I haven't been able to contact him while the list were down. Are there other candidates? Seems to me we need someone who's able to upload to CPAN and make decisions about incoming patches in a timely manner. Having some ideas about the future direction of Maypole probably wouldn't hurt either. Simon seems to be a good candidate for this. The general feeling seems to be that after 2.0 the maypole API needs time to stabilize, so backwards compability is a priority, but there are still plenty of improvements to be made, specially on the documentation and sane error reporting (internally to Maypole). So, who's up for the challenge? Whoever it is, I'm willing to keep maintaining the subversion tree and the website, and I still wish to continue development of Maypole, so whoever you are, you would not be alone. Marcus From sri@oook.de Fri Nov 12 22:42:28 2004 From: sri@oook.de (Sebastian Riedel) Date: Fri, 12 Nov 2004 23:42:28 +0100 Subject: [Maypole] (no subject) In-Reply-To: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> Message-ID: <1100299348.24695.4.camel@localhost> Marcus Ramberg: > Whoever it is, I'm willing to keep > maintaining the subversion tree and the website, and I still wish to > continue development of Maypole, so whoever you are, you would not be > alone. Well, even when i'm no more maintaining Maypole, i'm still around... And i'm sure the other two committers too, so "you" definately won't be alone. ;) It would also help if "you" could regularly visit #maypole, since all the interesting discussions happen there these days. sebastian From dave@riverside-cms.co.uk Fri Nov 12 23:52:17 2004 From: dave@riverside-cms.co.uk (David R. Baird) Date: Fri, 12 Nov 2004 23:52:17 -0000 Subject: [Maypole] MasonX::Maypole for Maypole 2 Message-ID: <41954CB1.6431.3B831F0A@localhost> Great to see the list back up, I was getting worried. I've just uploaded a new version of MasonX::Maypole that works with Maypole 2. It also now follows the same template search paths and uses the same path parsing scheme as Maypole, and has a MasonX::Maypole::View subclass. Includes Masonized versions of the factory templates from Maypole 2. This is a development version for the moment, and probably won't work with Maypole 1. If you're using a previous version of MasonX::Maypole, this release will break your app in a big way. >From CPAN soon, or here now: http://www.riverside-cms.co.uk/perl/ Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk From tony@kasei.com Sat Nov 13 09:34:17 2004 From: tony@kasei.com (Tony Bowden) Date: Sat, 13 Nov 2004 09:34:17 +0000 Subject: [Maypole] (no subject) In-Reply-To: <1100299348.24695.4.camel@localhost> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <1100299348.24695.4.camel@localhost> Message-ID: <20041113093417.GA20514@soto.kasei.com> On Fri, Nov 12, 2004 at 11:42:28PM +0100, Sebastian Riedel wrote: > It would also help if "you" could regularly visit #maypole, since all > the interesting discussions happen there these days. I don't think this should be a pre-req. There are lots of people, with lots to contribute, who don't do IRC. Even if the discussion does happen there, I'd suggest it be summarised to the list so the non-IRC people can comment on it too. Tony From jmorano@moretrix.com Sat Nov 13 13:15:59 2004 From: jmorano@moretrix.com (Johnny Morano) Date: Sat, 13 Nov 2004 14:15:59 +0100 Subject: [Maypole] (no subject) In-Reply-To: <20041113093417.GA20514@soto.kasei.com> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <1100299348.24695.4.camel@localhost> <20041113093417.GA20514@soto.kasei.com> Message-ID: <1100351759.7293.1.camel@r0nin> On Sat, 2004-11-13 at 09:34 +0000, Tony Bowden wrote: > I don't think this should be a pre-req. There are lots of people, with > lots to contribute, who don't do IRC. > > Even if the discussion does happen there, I'd suggest it be summarised > to the list so the non-IRC people can comment on it too. I second that motion! > Tony Johnny From corion@corion.net Thu Nov 4 21:25:41 2004 From: corion@corion.net (Max Maischein) Date: Thu, 04 Nov 2004 22:25:41 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <20041104114602.M68965@flacks.net> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> <20041104114602.M68965@flacks.net> Message-ID: <418A9E55.3070508@corion.net> >>>>Incidentally, as the youngest kid on the block, it might be a good idea >>>>for Maypole to check out what some of the more mature MVC frameworks for >>>>Perl have done about things like abstraction and declarative >>>>programming. >>> >>>[...] if you do this, >>>then you become very tempted to go mad and redesign your framework to steal >>>what you think are the cool features of everyone else's frameworks. Not >>>necessarily for any technical merit, either, just to keep up with the >>>neighbours. >>> Personally, I've looked at Maypole with much interest since its earliest beginnings, and while I haven't been overwhelmed with quality in certain locations, the overall quality of Maypole was really good, at least for the use I see in Maypole - a quickly prototypeable frontend for a database. The documentation quality has increased and with 2.0 it is good, at least good enough for me. What worries me is the Big Data Driven Approach currently taken, as the configuration "language" (for example YAML) is now a fourth language involved - there is only so much abstraction a toolkit can take, and I don't need much abstraction in Maypole once I sold my soul to TT (reluctant) and CDBI (willing). > I'd love to see Maypole settle down. Maypole needs to be more defined. Yes. I'd like to see the current (Maypole 1.7 / 2.0) Maypole to be accepted in more places as a potent seed for web applications. But for that to evolve, Maypole itself must mature, and it can't mature if the whole infrastructure changes every 5 months - if I wanted that, I'd program Java... Maypole has many ugly warts that need some Best Practices to evolve, like the best way of more flexible path management without involving mod_rewrite and CGI parameters, and it needs to expand horizontally, for example with a good, maintainable and low-overhead permission system, or handling of images and basic user/login features. But all of this needs a code base that does not change its outside interface. My 2 cents, -max From lists@riverside-cms.co.uk Fri Nov 12 23:09:07 2004 From: lists@riverside-cms.co.uk (David R. Baird) Date: Fri, 12 Nov 2004 23:09:07 -0000 Subject: [Maypole] MasonX::Maypole for Maypole 2 Message-ID: <41954293.6524.3B5B9640@localhost> Great to see the list back up, I was getting worried. I've just uploaded a new version of MasonX::Maypole that works with Maypole 2. It also now follows the same template search paths and uses the same path parsing scheme as Maypole, and has a MasonX::Maypole::View subclass. Includes Masonized versions of the factory templates from Maypole 2. This is a development version for the moment, and probably won't work with Maypole 1. If you're using a previous version of MasonX::Maypole, this release will break your app in a big way. >From CPAN soon, or here now: http://www.riverside-cms.co.uk/perl/ Cheers, d. -- Dr. David R. Baird Riverside Content Management Systems http://www.riverside-cms.co.uk From Dave.Howorth@acm.org Sat Nov 13 16:34:05 2004 From: Dave.Howorth@acm.org (Dave Howorth) Date: Sat, 13 Nov 2004 16:34:05 +0000 Subject: [Maypole] (no subject) In-Reply-To: <20041113093417.GA20514@soto.kasei.com> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <1100299348.24695.4.camel@localhost> <20041113093417.GA20514@soto.kasei.com> Message-ID: <4196377D.6030709@acm.org> Sebastian: >>It would also help if "you" could regularly visit #maypole, since all >>the interesting discussions happen there these days. Tony: > I don't think this should be a pre-req. There are lots of people, with > lots to contribute, who don't do IRC. I agree with Tony. I see several problems with IRC: - no archive, so whatever wisdom is expressed is immediately lost again. - in some jobs and/or situations it simply isn't practical to continually monitor groups in real-time - Maypole presently is a small group with a strong European focus but as it grows so will the community and Asians and Americans need to be able to learn and contribute. It isn't sensible to try to hold a global community to a single time pattern. - Maypole presently has two mailing lists, a wiki, a documentation set (is it down to one of those now? there used to be two), and IRC. These are too many methods of publishing information and are very confusing for newcomers in particular. > Even if the discussion does happen there, I'd suggest it be summarised > to the list so the non-IRC people can comment on it too. I think that *should* be a pre-requisite :) There should certainly be a single set of documentation and a single mailing list. Any more than that needs careful thought, and IMHO divides and weakens the community. Cheers, Dave From sri@oook.de Sat Nov 13 17:18:44 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 13 Nov 2004 18:18:44 +0100 Subject: [Maypole] The Future of Maypole In-Reply-To: <418A9E55.3070508@corion.net> References: <20041102200604.70675.qmail@web60804.mail.yahoo.com> <1099427308.10078.64.camel@localhost> <4187FBDF.10805@proofpoint.com> <20041103230042.GA1006@soto.kasei.com> <1099526770.3418.128.camel@localhost.localdomain> <20041104073425.GA5697@alibi.simon-cozens.org> <1099560019.17313.10.camel@localhost> <20041104114602.M68965@flacks.net> <418A9E55.3070508@corion.net> Message-ID: <1100366324.29026.22.camel@localhost> Max Maischein: > >>>>Incidentally, as the youngest kid on the block, it might be a good idea > >>>>for Maypole to check out what some of the more mature MVC frameworks for > >>>>Perl have done about things like abstraction and declarative > >>>>programming. > >>> > >>>[...] if you do this, > >>>then you become very tempted to go mad and redesign your framework to steal > >>>what you think are the cool features of everyone else's frameworks. Not > >>>necessarily for any technical merit, either, just to keep up with the > >>>neighbours. > >>> > Personally, I've looked at Maypole with much interest since its earliest > beginnings, and while I haven't been overwhelmed with quality in certain > locations, the overall quality of Maypole was really good, at least for > the use I see in Maypole - a quickly prototypeable frontend for a > database. The documentation quality has increased and with 2.0 it is > good, at least good enough for me. > > What worries me is the Big Data Driven Approach currently taken, as the > configuration "language" (for example YAML) is now a fourth language > involved - there is only so much abstraction a toolkit can take, and I > don't need much abstraction in Maypole once I sold my soul to TT > (reluctant) and CDBI (willing). > > > I'd love to see Maypole settle down. Maypole needs to be more defined. > Yes. I'd like to see the current (Maypole 1.7 / 2.0) Maypole to be > accepted in more places as a potent seed for web applications. But for > that to evolve, Maypole itself must mature, and it can't mature if the > whole infrastructure changes every 5 months - if I wanted that, I'd > program Java... Absolutely right, thats why i took my Maypole3 ideas and moved them into a subproject (Catalyst). Catalyst now completely aims at enterprise applications, it covers most features of a typical servlet container (api, sessions, contexts), struts-chain (the next-generation struts using the chain of responsibility pattern), ruby-on-rail (multiple controller support) and adds some weird stuff like AOP features (thats a new idea). It also completely separates the flow from the code (applications designed to be modified/refactored), cool stuff, you'll see... =) I'm very sure there are many features that'll get backported, like the extensive debugging/profiling features, header/cookie handling, redirect and http status support... So you see, it doesn't directly compete to Maypole, it's just a Maypole-like alternative, when Maypole's not enough for you... ;) Btw. YAML is not the configuration language, it's just a plugin to simplify configuration. The configuration is still just a Maypole::Config/Catalyst::Config object containing perl structures. So you can just use raw Perl or write your own plugin to configure your application, even xml. ;) > > Maypole has many ugly warts that need some Best Practices to evolve, > like the best way of more flexible path management without involving > mod_rewrite and CGI parameters, and it needs to expand horizontally, for > example with a good, maintainable and low-overhead permission system, or > handling of images and basic user/login features. But all of this needs > a code base that does not change its outside interface. IMHO there are also some design issues that need to be addressed, like debugging/profiling and multiple view/model support... sebastian From sri@oook.de Sat Nov 13 17:27:43 2004 From: sri@oook.de (Sebastian Riedel) Date: Sat, 13 Nov 2004 18:27:43 +0100 Subject: [Maypole] (no subject) In-Reply-To: <20041113093417.GA20514@soto.kasei.com> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <1100299348.24695.4.camel@localhost> <20041113093417.GA20514@soto.kasei.com> Message-ID: <1100366863.29026.27.camel@localhost> Tony Bowden: > On Fri, Nov 12, 2004 at 11:42:28PM +0100, Sebastian Riedel wrote: > > It would also help if "you" could regularly visit #maypole, since all > > the interesting discussions happen there these days. > > I don't think this should be a pre-req. There are lots of people, with > lots to contribute, who don't do IRC. Just sait "it would help". Since the most active contributors are also active on IRC. > Even if the discussion does happen there, I'd suggest it be summarised > to the list so the non-IRC people can comment on it too. Ack. sebastian From sf@flacks.net Sun Nov 14 17:47:01 2004 From: sf@flacks.net (Simon Flack) Date: Sun, 14 Nov 2004 17:47:01 +0000 Subject: [Maypole] (no subject) In-Reply-To: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> Message-ID: <20041114164158.M43016@flacks.net> On Fri, 12 Nov 2004 23:23:28 +0100, Marcus Ramberg wrote > So, it seems to me like we need a maintainer, since people were not > happy with SRI working with Catalyst and maintaining Maypole at the > same time. Simon Flack has been set up as a suggestion, but I > haven't been able to contact him while the list were down. Are there > other candidates? Seems to me we need someone who's able to upload > to CPAN and make decisions about incoming patches in a timely > manner. Having some ideas about the future direction of Maypole > probably wouldn't hurt either. Simon seems to be a good candidate > for this. > > The general feeling seems to be that after 2.0 the maypole API needs > time to stabilize, so backwards compability is a priority, but there > are still plenty of improvements to be made, specially on the > documentation and sane error reporting (internally to Maypole). So, > who's up for the challenge? Whoever it is, I'm willing to keep > maintaining the subversion tree and the website, and I still wish to > continue development of Maypole, so whoever you are, you would not > be alone. Over the next week I'll take a more in-depth look at the codebase and the mailing list archives and draw up a todo which I'll then post to the list. We can distill it down to several small milestones on the website. I'm keen for Maypole to be a community-driven project, but I think we need to keep the development focused. If everyone's happy with that, I'll take over the role of Maypole maintainer. I think Sebastian will need to pass maintainership or make me a co-maintainer via PAUSE. I want to make clear that I really appreciate the work that Sebastian and others have done on Maypole and I'll be watching Catalyst's progress with interest. --simonflk From sri@oook.de Sun Nov 14 18:18:28 2004 From: sri@oook.de (Sebastian Riedel) Date: Sun, 14 Nov 2004 19:18:28 +0100 Subject: [Maypole] (no subject) In-Reply-To: <20041114164158.M43016@flacks.net> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <20041114164158.M43016@flacks.net> Message-ID: <1100456308.2446.2.camel@localhost> Simon Flack: > If everyone's happy with that, I'll take over the role of Maypole maintainer. > I think Sebastian will need to pass maintainership or make me a co-maintainer > via PAUSE. Maybe we should try co-maint this time. ;) sebastian From brian@glassbrian.com Tue Nov 16 17:45:50 2004 From: brian@glassbrian.com (Brian Glass) Date: Tue, 16 Nov 2004 12:45:50 -0500 Subject: [Maypole] Apache2 Message-ID: <419A3CCE.6050006@glassbrian.com> I'm going crazy here trying to get Maypole 2 (from CPAN) to work in Apache2 with mod_perl2. I installed libapreq2-2.02_02-dev.tar.gz (I'm trying to use XAMPP and previously Mandrake 10.0 Apache) and I just can't get it to work. The error I'm getting right now is: Can't locate auto/Apache/Request/print.al in @INC Any ideas? From peterspeltz@yahoo.com Tue Nov 16 19:26:15 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Tue, 16 Nov 2004 11:26:15 -0800 (PST) Subject: [Maypole] Apache2 In-Reply-To: <419A3CCE.6050006@glassbrian.com> Message-ID: <20041116192615.54247.qmail@web52106.mail.yahoo.com> --- Brian Glass wrote: > I'm going crazy here trying to get Maypole 2 (from CPAN) to work in > Apache2 with mod_perl2. I installed libapreq2-2.02_02-dev.tar.gz (I'm > trying to use XAMPP and previously Mandrake 10.0 Apache) and I just > can't get it to work. > > The error I'm getting right now is: > > Can't locate auto/Apache/Request/print.al in @INC > > Any ideas? Man, i had this error a month ago but can't recall what i did. There is light at the end of the tunnel. Maybe i hadn't installed libapreq 2 or had some lines of code in wrong order. Does libapreq2 work outside maypole? I had to upgrade ExtUtils::XSBuilder before install libapreq2. Send your Modperl/Apache configuration directives and your source and maybe i can see what's causing the problem. > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > ===== pjs __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com From peterspeltz@yahoo.com Tue Nov 16 20:15:38 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Tue, 16 Nov 2004 12:15:38 -0800 (PST) Subject: [Maypole] -e argument OK isn't numeric in eq (==) Message-ID: <20041116201538.82603.qmail@web52108.mail.yahoo.com> I'm getting this in my error log all the time and am wondering if it's causing weird results. -e: Argument "OK" isn't numeric in numeric eq (==) at /usr/lib/perl5/site_perl/5.8.3/Maypole.pm line 98, line 3. ===== pjs __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From Dave.Howorth@acm.org Tue Nov 16 20:48:49 2004 From: Dave.Howorth@acm.org (Dave Howorth) Date: Tue, 16 Nov 2004 20:48:49 +0000 Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <20041116201538.82603.qmail@web52108.mail.yahoo.com> References: <20041116201538.82603.qmail@web52108.mail.yahoo.com> Message-ID: <419A67B1.2060406@acm.org> > I'm getting this in my error log all the time and am wondering if > it's causing weird results. > > -e: Argument "OK" isn't numeric in numeric eq (==) at > /usr/lib/perl5/site_perl/5.8.3/Maypole.pm line 98, line 3. Maypole::Constants exports OK as 0. If it's become non-numeric, I'd guess that you, or one of the other modules you're using, have somehow set it to some other value, probably a string. If it were me, I'd try single stepping the request using Maypole::CLI and the debugger to see what value it has acquired and where it occurred. Or go real low-tech and put a bunch of print statements in! Cheers, Dave From simon@simon-cozens.org Tue Nov 16 20:52:29 2004 From: simon@simon-cozens.org (Simon Cozens) Date: Tue, 16 Nov 2004 20:52:29 +0000 Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <419A67B1.2060406@acm.org> References: <20041116201538.82603.qmail@web52108.mail.yahoo.com> <419A67B1.2060406@acm.org> Message-ID: <20041116205229.GB26578@alibi.simon-cozens.org> Dave Howorth: > >-e: Argument "OK" isn't numeric in numeric eq (==) at > >/usr/lib/perl5/site_perl/5.8.3/Maypole.pm line 98, line 3. > > Maypole::Constants exports OK as 0. And if it's still being seen by the parser as "OK", not as the constant, then it suggests Maypole::Constants isn't being imported properly. -- 0x5: Thou shalt not decrease entropy 0x6: Thou shalt not connect PWR to GND 0x7: Thou shalt not sex toads 0x8: Thou shalt not exceed the speed of light - 0x10 Commandments, Our Lady Of The All-Night Tool From raanders@tsmg.us Tue Nov 16 21:38:43 2004 From: raanders@tsmg.us (Roderick A. Anderson) Date: Tue, 16 Nov 2004 13:38:43 -0800 Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <20041116201538.82603.qmail@web52108.mail.yahoo.com> References: <20041116201538.82603.qmail@web52108.mail.yahoo.com> Message-ID: <419A7363.5060103@tsmg.us> Peter Speltz wrote: > I'm getting this in my error log all the time and am wondering if it's causing > weird results. > > -e: Argument "OK" isn't numeric in numeric eq (==) at > /usr/lib/perl5/site_perl/5.8.3/Maypole.pm line 98, line 3. Based on my limited perl capabilities. The line is return $status unless $status == OK; I'd would have thought there would be a warning about a bare word before this. I haven't succeeded in getting Maypole installed (too many dependencies to sort out right now) but my attempts left many of the files in the .cpan directory. Therefore I can't debug it any further. But looking at the code it looks like call_authenticate or call_exception should be returning a numeric code but OK isn't. If you're brave you could edit Maypole.pm and change the == to eq and single quote the OK ('OK') and see if it runs. But you're probably better off waiting for one of the Maypole developers to say what the _real_ fix is. Cheers, Rod -- Roderick A. Anderson Technology Services Management Group Spokane WA, 99202 --- [This E-mail scanned for viruses by Declude Virus] From josenyimi@yahoo.fr Tue Nov 16 22:08:11 2004 From: josenyimi@yahoo.fr (=?iso-8859-1?q?Jos=FFffffe9=20Nyimi?=) Date: Tue, 16 Nov 2004 23:08:11 +0100 (CET) Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <419A7363.5060103@tsmg.us> Message-ID: <20041116220811.79105.qmail@web86910.mail.ukl.yahoo.com> --- "Roderick A. Anderson" a écrit : > Peter Speltz wrote: > > > I'm getting this in my error log all the time and > am wondering if it's causing > > weird results. > > > > -e: Argument "OK" isn't numeric in numeric eq (==) > at > > /usr/lib/perl5/site_perl/5.8.3/Maypole.pm line 98, > line 3. > > Based on my limited perl capabilities. The line is > > return $status unless $status == OK; perldoc constant and you would understant why OK is OK :-) José. Vous manquez d’espace pour stocker vos mails ? Yahoo! Mail vous offre GRATUITEMENT 100 Mo ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com From michael@diaspora.gen.nz Wed Nov 17 00:20:16 2004 From: michael@diaspora.gen.nz (michael@diaspora.gen.nz) Date: Wed, 17 Nov 2004 13:20:16 +1300 Subject: [Maypole] Apache2 In-Reply-To: Your message of "Tue, 16 Nov 2004 12:45:50 CDT." <419A3CCE.6050006@glassbrian.com> Message-ID: Brian Glass writes: >I'm going crazy here trying to get Maypole 2 (from CPAN) to work in >Apache2 with mod_perl2. I installed libapreq2-2.02_02-dev.tar.gz (I'm >trying to use XAMPP and previously Mandrake 10.0 Apache) and I just >can't get it to work. > >The error I'm getting right now is: > > Can't locate auto/Apache/Request/print.al in @INC Try this patch (had the same problem on Debian using -unstable packages for apache2 and mod_perl2): pivot$ svn diff Index: lib/Apache/MVC.pm =================================================================== --- lib/Apache/MVC.pm (revision 280) +++ lib/Apache/MVC.pm (working copy) @@ -12,6 +12,7 @@ if (APACHE2) { require Apache2; + require Apache::RequestIO; require Apache::RequestRec; require Apache::RequestUtil; require APR::URI; From Dave.Howorth@acm.org Wed Nov 17 00:21:56 2004 From: Dave.Howorth@acm.org (Dave Howorth) Date: Wed, 17 Nov 2004 00:21:56 +0000 Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <20041116205229.GB26578@alibi.simon-cozens.org> References: <20041116201538.82603.qmail@web52108.mail.yahoo.com> <419A67B1.2060406@acm.org> <20041116205229.GB26578@alibi.simon-cozens.org> Message-ID: <419A99A4.7070706@acm.org> > it suggests Maypole::Constants isn't being imported properly. I think it was imported OK :) because Peter didn't say there was a warning when it was used earlier on line 76. There don't seem to be too many places between there and line 98 where things could go awry unless there's been some adventurous overloading. My money would have to be on something in custom authentication code. Put us out of our misery, Peter! Where was the problem? Cheers, Dave From brian@glassbrian.com Wed Nov 17 03:01:19 2004 From: brian@glassbrian.com (Brian Glass) Date: Tue, 16 Nov 2004 22:01:19 -0500 Subject: [Maypole] Apache2 In-Reply-To: References: Message-ID: <419ABEFF.6060802@glassbrian.com> You're my hero! Thanks immensly. michael@diaspora.gen.nz wrote: >Brian Glass writes: > > >>I'm going crazy here trying to get Maypole 2 (from CPAN) to work in >>Apache2 with mod_perl2. I installed libapreq2-2.02_02-dev.tar.gz (I'm >>trying to use XAMPP and previously Mandrake 10.0 Apache) and I just >>can't get it to work. >> >>The error I'm getting right now is: >> >> Can't locate auto/Apache/Request/print.al in @INC >> >> > >Try this patch (had the same problem on Debian using -unstable packages >for apache2 and mod_perl2): > >pivot$ svn diff >Index: lib/Apache/MVC.pm >=================================================================== >--- lib/Apache/MVC.pm (revision 280) >+++ lib/Apache/MVC.pm (working copy) >@@ -12,6 +12,7 @@ > > if (APACHE2) { > require Apache2; >+ require Apache::RequestIO; > require Apache::RequestRec; > require Apache::RequestUtil; > require APR::URI; > > > > From peterspeltz@yahoo.com Wed Nov 17 05:02:58 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Tue, 16 Nov 2004 21:02:58 -0800 (PST) Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <419A99A4.7070706@acm.org> Message-ID: <20041117050258.63945.qmail@web52108.mail.yahoo.com> --- Dave Howorth wrote: > > it suggests Maypole::Constants isn't being imported properly. > > I think it was imported OK :) because Peter didn't say there was a > warning when it was used earlier on line 76. > Exactly. > There don't seem to be too many places between there and line 98 where > things could go awry unless there's been some adventurous overloading. > My money would have to be on something in custom authentication code. > You're in the money. > Put us out of our misery, Peter! Where was the problem? > > Cheers, Dave > I took a break to fiddle with car. Thanks for the great ideas, all. I nailed it down in minutes after reading your emails. Too bad cause i was really looking forward to using Maypole::CLI, too. guess i'll try that later. To end the suspense -- Problem was maypole constants weren't imported into my driver class. In my authenticate sub i was returning OK. i forgot use strict;, use warnings; in my driver class. DOOHH! (it's in all my other classes i swear.) So this went by as a bareword. So many of you were right on. I'm using 2.4. Now my question is, why doesn't my driver have maypole::constants when i say use base qw/Maypole::Application Maypole::Authentication::UserSessionCookie/; I checked the code and Apache::MVC uses maypole as a base so it should have them. and Maypole::App gets A::MVC pushed on it's @ISA (in my case) so maybe the problem is what? The more i do this stuff the more i realize i have no idea what's going on. ===== pjs __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sri@oook.de Wed Nov 17 08:45:11 2004 From: sri@oook.de (Sebastian Riedel) Date: Wed, 17 Nov 2004 09:45:11 +0100 Subject: [Maypole] Apache2 In-Reply-To: References: Message-ID: <1100681111.13905.1.camel@localhost> michael@diaspora.gen.nz: > pivot$ svn diff > Index: lib/Apache/MVC.pm > =================================================================== > --- lib/Apache/MVC.pm (revision 280) > +++ lib/Apache/MVC.pm (working copy) > @@ -12,6 +12,7 @@ > > if (APACHE2) { > require Apache2; > + require Apache::RequestIO; > require Apache::RequestRec; > require Apache::RequestUtil; > require APR::URI; Thanks, applied to Maypole and Catalyst. sebastian From tony@kasei.com Wed Nov 17 09:46:42 2004 From: tony@kasei.com (Tony Bowden) Date: Wed, 17 Nov 2004 09:46:42 +0000 Subject: [Maypole] -e argument OK isn't numeric in eq (==) In-Reply-To: <20041117050258.63945.qmail@web52108.mail.yahoo.com> References: <419A99A4.7070706@acm.org> <20041117050258.63945.qmail@web52108.mail.yahoo.com> Message-ID: <20041117094642.GA28225@soto.kasei.com> On Tue, Nov 16, 2004 at 09:02:58PM -0800, Peter Speltz wrote: > Now my question is, why doesn't my driver have maypole::constants when i say > use base qw/Maypole::Application Maypole::Authentication::UserSessionCookie/; Constants need to be exported into your package. You can't inherit them from a superclass. Tony From paul.barry@itcarlow.ie Wed Nov 17 12:33:16 2004 From: paul.barry@itcarlow.ie (Paul Barry) Date: Wed, 17 Nov 2004 12:33:16 +0000 Subject: [Maypole] Apache2 In-Reply-To: <1100681111.13905.1.camel@localhost> References: <1100681111.13905.1.camel@localhost> Message-ID: <419B450C.6050601@itcarlow.ie> Sebastian Riedel wrote: >>pivot$ svn diff >>Index: lib/Apache/MVC.pm >>=================================================================== >>--- lib/Apache/MVC.pm (revision 280) >>+++ lib/Apache/MVC.pm (working copy) >>@@ -12,6 +12,7 @@ >> >> if (APACHE2) { >> require Apache2; >>+ require Apache::RequestIO; >> require Apache::RequestRec; >> require Apache::RequestUtil; >> require APR::URI; > > > Thanks, applied to Maypole and Catalyst. I've been struggling trying to get mod_perl2 to work ... and now it does! Thanks. May I suggest a 2.05 upload to CPAN so that any new Maypolers can automatically benefit from this fix? Regards. Paul. -- Paul Barry, Dept. of Computing & Networking, Institute of Technology, Carlow, Kilkenny Road, Carlow, Ireland. E-mail: paul.barry@itcarlow.ie Telephone: +353+59+9170400. Website: http://glasnost.itcarlow.ie/~barryp/index.html Public-key is: http://glasnost.itcarlow.ie/~barryp/paulbarry-key.asc From peterspeltz@yahoo.com Thu Nov 18 02:10:49 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Wed, 17 Nov 2004 18:10:49 -0800 (PST) Subject: [Maypole] M::A:UserSessCook logout error Message-ID: <20041118021049.97815.qmail@web52101.mail.yahoo.com> bouncing this off list while i trouble shoot it. getting this error when i call the logout sub -e: caught model error: Insecure dependency in unlink while running setgid at /usr/lib/perl5/site_perl/5.8.3/Apache/Session/Store/File.pm line 106. this is line 106 if (-e $directory.'/'.$session->{data}->{_session_id}) { unlink ($directory.'/'.$session->{data}->{_session_id}) || die "Could not remove file: $!"; } this is the logout which results in call to 106 above. tied(%{$r->{session}})->delete; # causing insecure dependency Is something in %{$r->{session}} tainted? thanks ===== pjs __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From brian@glassbrian.com Thu Nov 18 14:55:47 2004 From: brian@glassbrian.com (Brian Glass) Date: Thu, 18 Nov 2004 09:55:47 -0500 Subject: [Maypole] Re: Maypole responding to requests very slowly (or, how to get just one associated record instead of getting the world) In-Reply-To: <415C2E08.70605@morcor.com> References: <415C2E08.70605@morcor.com> Message-ID: <419CB7F3.9020401@glassbrian.com> Has any more thought been put into this problem? I'd be happy to help code the solution, but I don't think a consensus has been reached as to what to do about the problem. Matt Adams wrote: > ... I'd very much like to see Simon's suggestion for "AsForm to return > its own objects, which save state and only hit the database when > as_HTML is called on them." > > > Matt From brian@glassbrian.com Thu Nov 18 19:34:18 2004 From: brian@glassbrian.com (Brian Glass) Date: Thu, 18 Nov 2004 14:34:18 -0500 Subject: [Maypole] Re: Maypole responding to requests very slowly (or, how to get just one associated record instead of getting the world) In-Reply-To: <419CB7F3.9020401@glassbrian.com> References: <415C2E08.70605@morcor.com> <419CB7F3.9020401@glassbrian.com> Message-ID: <419CF93A.5080308@glassbrian.com> My temporary solution was to remove the {cgi} creation step from Maypole::View::Base::vars and then go through my templates (HTML::Mason) and change all the: $classmetadata->{cgi}->{$col}->as_HTML to: $classmetadata->{name}->to_field($col)->as_HTML It works great but it's a bit of a hack. It actually makes the application usable. Brian Glass wrote: > Has any more thought been put into this problem? I'd be happy to help > code the solution, but I don't think a consensus has been reached as > to what to do about the problem. > > > Matt Adams wrote: > >> ... I'd very much like to see Simon's suggestion for "AsForm to >> return its own objects, which save state and only hit the database >> when as_HTML is called on them." >> >> >> Matt > > > > From jester@panix.com Thu Nov 18 19:49:20 2004 From: jester@panix.com (Jesse Sheidlower) Date: Thu, 18 Nov 2004 14:49:20 -0500 Subject: [Maypole] model_class issues on 1.7->2.x upgrade? Message-ID: <20041118194920.GB6774@panix.com> Before I spend too much time debugging this, I thought someone might have run into this and could help out. I just upgraded Maypole from 1.7 to 2.04. Several applications were unaffected, but one relatively complex one, which has some authentication juju going on, had problems. I'm now throwing errors of the sort: caught authenticate error: Can't call method "can" on an undefined value at... with the relevant line, in the main module, being return $r->model_class->sub_authenticate($r) if $r->model_class->can("sub_authenticate"); Backing out 2.04 in favor of 1.7 fixes the problem. Anyone run into this before, or know the obvious place to start? Jesse Sheidlower From peterspeltz@yahoo.com Thu Nov 18 21:04:23 2004 From: peterspeltz@yahoo.com (Peter Speltz) Date: Thu, 18 Nov 2004 13:04:23 -0800 (PST) Subject: [Maypole] model_class issues on 1.7->2.x upgrade? In-Reply-To: <20041118194920.GB6774@panix.com> Message-ID: <20041118210423.10069.qmail@web52106.mail.yahoo.com> --- Jesse Sheidlower wrote: > > Before I spend too much time debugging this, I thought someone > might have run into this and could help out. > > I just upgraded Maypole from 1.7 to 2.04. Several applications > were unaffected, but one relatively complex one, which has some > authentication juju going on, had problems. I'm now throwing > errors of the sort: > > caught authenticate error: Can't call method "can" on an undefined > value at... > > with the relevant line, in the main module, being > > return $r->model_class->sub_authenticate($r) > if $r->model_class->can("sub_authenticate"); > What's the main module? You're driver? Are you going to a page that doesn't have a model class associated with it like a straight template? Wrap above code in an "if ($r->model_class) { warn "No model classs in sub authenticate; .. . } and see if everything works ok. Check error log for warnings and see what situations you get the warning. Maybe maypole 1.7 returns the base model class name if there is no model class and that's why you're getting an error in 2.04. > Backing out 2.04 in favor of 1.7 fixes the problem. > > Anyone run into this before, or know the obvious place > to start? > > Jesse Sheidlower > > _______________________________________________ > maypole mailing list > maypole@lists.netthink.co.uk > http://lists.netthink.co.uk/listinfo/maypole > This is not earth shattering info but maybe it will help if you don't know this: $r-model_class is the class name of the object/table your working with. Example Beer or Brewery. It gets set first thing in Maypole::handler_guts It is not getting set for some reason. Either bad things are happening or there is no model_class associated with the page, ie its a straight template. First make sure you have a class associated with that table. Maypole uses the model->class_of method to determine the class from the table name. see Maypole::Model::CDBI and Maypole::handler_guts sub. start at that point and work your way back to see why maypole doesn't get the model_class. YOu could try the Maypole Command Line debugger and run through it and diagnose the problem. ===== pjs __________________________________ Do you Yahoo!? Meet the all-new My Yahoo! - Try it today! http://my.yahoo.com From sf@flacks.net Thu Nov 18 23:59:30 2004 From: sf@flacks.net (Simon Flack) Date: Thu, 18 Nov 2004 23:59:30 +0000 Subject: [Maypole] (no subject) In-Reply-To: <20041114164158.M43016@flacks.net> References: <79F23DDE-34F9-11D9-8D2F-000A956D773E@thefeed.no> <20041114164158.M43016@flacks.net> Message-ID: <20041118235414.M19522@flacks.net> On Sun, 14 Nov 2004 17:47:01 +0000, Simon Flack wrote > Over the next week I'll take a more in-depth look at the codebase > and the mailing list archives and draw up a todo which I'll then > post to the list. Here's my view on the documentation. The manual has incomplete chapters (inicated on Maypole::Manual), but what is there needs to be updated to bring it in to line with Maypole 2.x. The API docs are pretty much complete, but by themselves aren't very useful. They'll be more useful when Maypole::Manual::Workflow is updated. And unit tests need to be written from the ground up. Now I've pretty much stated the obvious, I need to get something off my chest and eat some of my words. In a previous email, I said I'd like to see Maypole stabilise and have few (if any) backwardly incompatible changes. Now, in general I'm pretty happy with the model and the view, but I have a bit of problem with the controller. I think there have been both positive and negitive developments in that area. For example, I like Maypole::Application but IMO, the controller is quite bloated. Maypole's controller has several roles fused into one object: 1. A workflow as defined in ::Manual::Workflow, which processes... 2. A request object which is generated by... 3. Platform-specific components (e.g. CGI::Maypole, Apache::MVC) * * really, these just implement specific parts of [1]. All of that comes together with the magic of multiple inheritance. >From a user's point of view, I don't want to touch the workflow unless I really need to. I care most about setting up my data source, and writing templates that expose the request object. So let's see what we have if we split the current controller object in two: Controller: + config + debug + get_template_root + authenticate + exception + setup # handler # handler_guts - is_applicable - init - parse_location - parse_path - send_output - call_authenticate - call_exception - get_request Request object: + path + table + action + args + params / query + user + model_class + additional_data + objects + template_args + template + error + output + document_encoding + content_type [ + user ... ] I think that's a pretty clear separation of concerns. Model and view methods should be passed the request object. The request object needs to provide some access to the application configuration, possibly via $r->config or $r->app_class->config. Models and views shouldn't be able to mess about with the controller. I believe this separation will make Maypole easier to understand and use. It should also make it a lot easier to unit test. If I were writing M