I see message Dancer::layout has been deprecated since version 1.3050. use 'set layout => "value"' But why was it done? For example: get '/' => sub { # do something my $message = template 'message', $data, {layout=>''}; # sending email with $message or inserting parsed data to DB # do something else template 'index', $data; }; So, in the new way I should read current setting('layout'), save it, set up new layout and restore old layout after if the old-style layout setup will be deprecated. This is ugly! Is there any other ways to do it beautiful? May be it is better to do it optional and not to deprecate this feature? -- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
Hello, Nick On 21/05/2011 22:15, Nick Knutov wrote:
I see message
Dancer::layout has been deprecated since version 1.3050. use 'set layout => "value"'
But why was it done?
For example:
get '/' => sub { # do something my $message = template 'message', $data, {layout=>''}; # sending email with $message or inserting parsed data to DB # do something else template 'index', $data; };
So, in the new way I should read current setting('layout'), save it, set up new layout and restore old layout after if the old-style layout setup will be deprecated. This is ugly!
No, this seems a bug. Will look into it now. Cheers
On 21/05/2011 22:17, ambs wrote:
Hello, Nick
On 21/05/2011 22:15, Nick Knutov wrote:
I see message
Dancer::layout has been deprecated since version 1.3050. use 'set layout => "value"'
But why was it done?
For example:
get '/' => sub { # do something my $message = template 'message', $data, {layout=>''}; # sending email with $message or inserting parsed data to DB # do something else template 'index', $data; };
So, in the new way I should read current setting('layout'), save it, set up new layout and restore old layout after if the old-style layout setup will be deprecated. This is ugly!
Nick, Are you sure you do not have a line with 'layout "foo";' anywhere else in the code? Thanks
Oh, yes, found it, my mistake. On 22.05.2011 3:29, ambs wrote:
Are you sure you do not have a line with 'layout "foo";' anywhere else in the code?
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
+1 for teamwork! :) On Sun, May 22, 2011 at 12:34 AM, ambs <ambs+dancer@perl-hackers.net> wrote:
On 21/05/2011 22:33, Nick Knutov wrote:
Oh, yes, found it, my mistake.
Great, thanks :)
On 22.05.2011 3:29, ambs wrote:
Are you sure you do not have a line with 'layout "foo";' anywhere else in the code?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
But anyway, why this changes was done? The new way may be a little bit beautiful or stylish, but the old way is shorter. On 22.05.2011 3:34, ambs wrote:
On 21/05/2011 22:33, Nick Knutov wrote:
Oh, yes, found it, my mistake.
Great, thanks :)
On 22.05.2011 3:29, ambs wrote:
Are you sure you do not have a line with 'layout "foo";' anywhere else in the code?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
-- Best Regards, Nick Knutov http://knutov.com ICQ: 272873706 Voice: +7-904-84-23-130
On 21/05/2011 22:40, Nick Knutov wrote:
But anyway, why this changes was done?
The new way may be a little bit beautiful or stylish, but the old way is shorter.
The idea is two fold: 1. reduce the amount of exported method/functions by Dancer; 2. make interaction with config variables homogeneous (using set for them all) Cheers
On 22.05.2011 3:34, ambs wrote:
On 21/05/2011 22:33, Nick Knutov wrote:
Oh, yes, found it, my mistake.
Great, thanks :)
On 22.05.2011 3:29, ambs wrote:
Are you sure you do not have a line with 'layout "foo";' anywhere else in the code?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Sat, May 21, 2011 at 5:42 PM, ambs <ambs+dancer@perl-hackers.net> wrote:
On 21/05/2011 22:40, Nick Knutov wrote:
But anyway, why this changes was done?
The new way may be a little bit beautiful or stylish, but the old way is shorter.
The idea is two fold:
1. reduce the amount of exported method/functions by Dancer; 2. make interaction with config variables homogeneous (using set for them
Is config->{layout} = 'foo' the same as set layout => 'foo'? -Naveed
all)
Cheers
On 22.05.2011 3:34, ambs wrote:
On 21/05/2011 22:33, Nick Knutov wrote:
Oh, yes, found it, my mistake.
Great, thanks :)
On 22.05.2011 3:29, ambs wrote:
Are you sure you do not have a line with 'layout "foo";' anywhere else in the code?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Saturday 21 May 2011 23:19:18 Naveed Massjouni wrote:
Is config->{layout} = 'foo' the same as set layout => 'foo'?
In general, you shouldn't change the hashref returned by config(), but use set() instead. Some settings, when changed via set(), trigger a hook to handle that change (e.g. initialise a template engine when 'template' is used, set up a catch-all route when 'auto_page' is used, etc). Changing them directly, bypassing set(), means those triggers won't fire. The 'layout' setting, however, doesn't have any trigger, so changing it directly wouldn't hurt; I still wouldn't recommend it though, for future- proofing. In fact, it might make sense for us to change config() to return a tied hash which emits warnings if you try to change any values, to discourage people from using it to change settings directly, bypassing set(). Cheers -- David Precious ("bigpresh") http://www.preshweb.co.uk/ "Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz)
On 22 May 2011 13:46, David Precious <davidp@preshweb.co.uk> wrote:
On Saturday 21 May 2011 23:19:18 Naveed Massjouni wrote:
Is config->{layout} = 'foo' the same as set layout => 'foo'?
In general, you shouldn't change the hashref returned by config(), but use set() instead. Some settings, when changed via set(), trigger a hook to handle that change (e.g. initialise a template engine when 'template' is used, set up a catch-all route when 'auto_page' is used, etc). Changing them directly, bypassing set(), means those triggers won't fire.
The 'layout' setting, however, doesn't have any trigger, so changing it directly wouldn't hurt; I still wouldn't recommend it though, for future- proofing.
In fact, it might make sense for us to change config() to return a tied hash which emits warnings if you try to change any values, to discourage people from using it to change settings directly, bypassing set().
That can be a good idea, but we should be extremely cautious with ties : they are slow, and a bit magic. But a careful implementation can be the perfect solution in this case.
Cheers
-- David Precious ("bigpresh") http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Mon, May 23, 2011 at 5:11 AM, damien krotkine <dkrotkine@gmail.com> wrote:
On 22 May 2011 13:46, David Precious <davidp@preshweb.co.uk> wrote:
On Saturday 21 May 2011 23:19:18 Naveed Massjouni wrote:
Is config->{layout} = 'foo' the same as set layout => 'foo'?
In general, you shouldn't change the hashref returned by config(), but use set() instead. Some settings, when changed via set(), trigger a hook to handle that change (e.g. initialise a template engine when 'template' is used, set up a catch-all route when 'auto_page' is used, etc). Changing them directly, bypassing set(), means those triggers won't fire.
The 'layout' setting, however, doesn't have any trigger, so changing it directly wouldn't hurt; I still wouldn't recommend it though, for future- proofing.
In fact, it might make sense for us to change config() to return a tied hash which emits warnings if you try to change any values, to discourage people from using it to change settings directly, bypassing set().
I'm not sure if I like this. Consider complex user defined configurations. I like being able to do: config->{foo}{bar}{poo} = 42; Can that even be done via set() ? -Naveed
That can be a good idea, but we should be extremely cautious with ties : they are slow, and a bit magic. But a careful implementation can be the perfect solution in this case.
Cheers
-- David Precious ("bigpresh") http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support it for the rest of your life". (Michael Sinz) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
I'm not sure if I like this. Consider complex user defined configurations. I like being able to do: config->{foo}{bar}{poo} = 42; Can that even be done via set() ?
There is a proposal for that to be possible with set. Probably this is a good time to ask other core devels if my proposal is to be applied or not :) Cheers ambs
damien krotkine <dkrotkine@gmail.com> wrote:
That can be a good idea, but we should be extremely cautious with ties : they are slow, and a bit magic.
Another possibility would be to use lock_hash() from Hash::Util (core since Perl 5.8.0); that forbids modification of the hash, but in a way that doesn't affect lookup speed. The only downside is that you can still modify arrays and hashes that are stored (by reference) in the hash: use Hash::Util qw<lock_hash>; my %hash = (array => [], hash => {}, string => 'foo'); lock_hash(%hash); push @{ $hash{array} }, 1; # allowed $hash{hash}{nested}++; # allowed $hash{string} = 1; # forbidden (replaces a stored value) $hash{new_key} = 1; # forbidden (adds a key) delete $hash{array}; # forbidden (deletes a key) -- Aaron Crane ** http://aaroncrane.co.uk/
"Nick Knutov" <mail@knutov.com> wrote:
I see message
Dancer::layout has been deprecated since version 1.3050. use 'set layout => "value"'
But why was it done?
For example:
get '/' => sub { # do something my $message = template 'message', $data, {layout=>''}; # sending email with $message or inserting parsed data to DB # do something else template 'index', $data; };
So, in the new way I should read current setting('layout'), save it, set up new layout and restore old layout after if the old-style layout setup will be deprecated. This is ugly!
No, setting the layout via the 'layout' option to the template() keyword should still be supported - it's just the layout() keyword which has been deprecated. So, layout 'foo'; Becomes: set layout => 'foo'; You can still override the layout setting when calling layout: template 'foo', \%tokens, { layout => 'bar'; -- David Precious <davidp@preshweb.co.uk> Sent from my phone so please excuse brevity / poor quoting style etc
participants (7)
-
Aaron Crane -
ambs -
damien krotkine -
David Precious -
Naveed Massjouni -
Nick Knutov -
sawyer x