FAQ
There are a couple of behaviours I'm not keen on, are they intended,
and would patches 'fixing' them be accepted?

When I set an elements' value to zero, it's not set in the output xml.

When I set an elements' label to the empty string, it's not set in the
output xml.

Also, I'd like an accessor to retrieve an element by name, so that I
don't have to store them all as they're created.
The elements are stored internally in html-widget as a list, meaning
multiple items can share the same name.
What would be the most sane behaviour of such an accessor?

If there's only one by that name, return it.
If there's more that one, return a list in array context, an array-ref
in scalar context.
??

Cheers,
Carl

Search Discussions

  • Nilson Santos Figueiredo Junior at Mar 1, 2006 at 3:04 pm

    On 3/1/06, Carl Franks wrote:
    There are a couple of behaviours I'm not keen on, are they intended,
    and would patches 'fixing' them be accepted?

    When I set an elements' value to zero, it's not set in the output xml.

    When I set an elements' label to the empty string, it's not set in the
    output xml.
    I think these patches would probably be accepted. Either way, it seems
    you'll need to modify the modules anyway. So you might as well just
    send the patch to the authors.
    Also, I'd like an accessor to retrieve an element by name, so that I
    don't have to store them all as they're created.
    The elements are stored internally in html-widget as a list, meaning
    multiple items can share the same name.
    What would be the most sane behaviour of such an accessor?
    I don't know exactly the innards of the modules you're talking about.
    But the simple approach is to keep a hash along with the list. So
    everytime you create an element, you add a corresponding entry in the
    hash table. And so on. This could be made as a subclass of the module
    or an actual patch which might be a nice feature (or not - depending
    on the author's opinion).

    -Nilson Santos F. Jr.
  • Sebastian Riedel at Mar 1, 2006 at 4:00 pm

    Am 01.03.2006 um 16:04 schrieb Nilson Santos Figueiredo Junior:
    On 3/1/06, Carl Franks wrote:
    There are a couple of behaviours I'm not keen on, are they intended,
    and would patches 'fixing' them be accepted?

    When I set an elements' value to zero, it's not set in the output
    xml.

    When I set an elements' label to the empty string, it's not set in
    the
    output xml.
    I think these patches would probably be accepted. Either way, it seems
    you'll need to modify the modules anyway. So you might as well just
    send the patch to the authors.
    Yes, thats considered a bug.
    Also, I'd like an accessor to retrieve an element by name, so that I
    don't have to store them all as they're created.
    The elements are stored internally in html-widget as a list, meaning
    multiple items can share the same name.
    What would be the most sane behaviour of such an accessor?
    I don't know exactly the innards of the modules you're talking about.
    But the simple approach is to keep a hash along with the list. So
    everytime you create an element, you add a corresponding entry in the
    hash table. And so on. This could be made as a subclass of the module
    or an actual patch which might be a nice feature (or not - depending
    on the author's opinion).
    A hash would solve nothing, we have to use a list because multiple
    elements with the same name are valid.
    I would call the methods get_elements/get_constraints/get_filters and
    just let them return a list.

    Patches welcome! :)


    --
    sebastian
  • Nilson Santos Figueiredo Junior at Mar 1, 2006 at 4:33 pm

    On 3/1/06, Sebastian Riedel wrote:
    A hash would solve nothing, we have to use a list because multiple
    elements with the same name are valid.
    Of course it would.
    It'd be a hash of arrays. Of course you could loop through the list
    everytime, looking for the elements, but it'd be *really* inefficient.

    -Nilson Santos F. Jr.
  • Sebastian Riedel at Mar 1, 2006 at 4:48 pm

    01.03.2006 17:33 Nilson Santos Figueiredo Junior:
    On 3/1/06, Sebastian Riedel wrote:
    A hash would solve nothing, we have to use a list because multiple
    elements with the same name are valid.
    Of course it would.
    It'd be a hash of arrays. Of course you could loop through the list
    everytime, looking for the elements, but it'd be *really* inefficient.
    It would be a optimisation, but not solve the problem.


    --
    sebastian
  • Sebastian Riedel at Mar 1, 2006 at 4:49 pm

    01.03.2006 17:33 Nilson Santos Figueiredo Junior:
    Of course it would.
    It'd be a hash of arrays. Of course you could loop through the list
    everytime, looking for the elements, but it'd be *really* inefficient.
    And don't forget it would make embedding/merging much more complicated!


    --
    sebastian
  • Carl Franks at Mar 8, 2006 at 4:11 pm

    On 01/03/06, Sebastian Riedel wrote:
    On 3/1/06, Carl Franks wrote:

    When I set an elements' value to zero, it's not set in the output
    xml.

    When I set an elements' label to the empty string, it's not set in
    the
    output xml.
    Yes, thats considered a bug.

    I've commited a fix for these, with tests.

    Carl
  • Carl Franks at Mar 8, 2006 at 5:18 pm

    On 01/03/06, Sebastian Riedel wrote:
    On 3/1/06, Carl Franks wrote:

    Also, I'd like an accessor to retrieve an element by name, so that I
    don't have to store them all as they're created.
    I would call the methods get_elements/get_constraints/get_filters and
    just let them return a list.

    Patches welcome! :)
    Committed!

    $w->get_constraints()
    $w->get_constraints( type => 'Integer' )
    $w->get_constraints( name => 'username' )

    $w->get_elements()
    $w->get_elements( type => 'Textfield' )

    $w->get_filters()
    $w->get_filters( type => 'LowerCase' )


    Carl
  • Aristotle Pagaltzis at Mar 1, 2006 at 6:00 pm
    * Carl Franks [2006-03-01 13:45]:
    If there's only one by that name, return it. If there's more
    that one, return a list in array context, an array-ref in scalar
    context.
    Please don?t. Every time I have to use such an API it makes me
    cry. :-( Making the type of the return value dependent on its
    value is a breathtaking pain in the rear end. It causes code
    that?s gunked up with gobs of `ref $foo eq 'ARRAY'` checks.

    Be consistent.

    If you want to return an array ref in scalar context, then do it
    regardless of how many elements it will have. It?s a bit of a
    pain to have `->[0]` everywhere, not to mention the visual noise,
    but it?s a lot less nasty than forcing people to save the return
    value and check its type to make sure the code does not
    unexpectedly break.

    Or do the simplest thing that could possibly work and just return
    a list of matching elements, regardless of context, leaving it
    up to the caller how many elements they want to keep. I?d favour
    this. The fewer clever special cases, the better.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Nilson Santos Figueiredo Junior at Mar 1, 2006 at 6:15 pm

    On 3/1/06, A. Pagaltzis wrote:
    Please don't. Every time I have to use such an API it makes me
    cry. :-( Making the type of the return value dependent on its
    value is a breathtaking pain in the rear end. It causes code
    that's gunked up with gobs of `ref $foo eq 'ARRAY'` checks.
    I'm not sure when you'd need to actually check anything like that.

    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;

    I, myself, actually like this sort of API since it allows *me* to
    choose what's more convenient instead of relying on the module
    author's choice.

    If you want consistent results, just code consistently.

    -Nilson Santos F. Jr.
  • Brian Kirkbride at Mar 1, 2006 at 6:23 pm

    Nilson Santos Figueiredo Junior wrote:
    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;

    I think that is what he was requesting, actually.

    His problem was with code like this:

    sub method {
    return $results[0] if scalar(@results) == 1;
    return wantarray ? @results : \@results;
    }

    Which really is a pain, IMHO.

    ---------------
    Brian Kirkbride
    deeperbydesign.com
  • Matt S Trout at Mar 2, 2006 at 2:35 pm

    On Wed, Mar 01, 2006 at 12:23:42PM -0600, Brian Kirkbride wrote:
    Nilson Santos Figueiredo Junior wrote:
    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;

    I think that is what he was requesting, actually.

    His problem was with code like this:

    sub method {
    return $results[0] if scalar(@results) == 1;
    return wantarray ? @results : \@results;
    }

    Which really is a pain, IMHO.
    IMO if you're going to return something else in scalar context you should
    ensure it numifies to the number of entries that would have been returned
    in list context. Otherwise code like this -

    my @foo = $obj->foo;
    my $x = scalar @foo;

    my $y = scalar $obj->foo;

    will result in $x and $y not being the same thing, which is horribly
    unintuitive - hence why DBIx::Class::ResultSet objects numify to the number
    of records.

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
  • Nilson Santos Figueiredo Junior at Mar 2, 2006 at 3:06 pm

    On 3/2/06, Matt S Trout wrote:
    my @foo = $obj->foo;
    my $x = scalar @foo;

    my $y = scalar $obj->foo;

    will result in $x and $y not being the same thing, which is horribly
    unintuitive - hence why DBIx::Class::ResultSet objects numify to the number
    of records.
    Altough I think that "horribly unintuitive" is an exageration - it is
    at most slightly unintuitive - and that I, myself, wouldn't write code
    like this (just a matter of programming style, really) this behaviour
    seems fine and coherent so it's probably a good thing to numify to the
    number of objects.

    -Nilson Santos F. Jr.
  • Aristotle Pagaltzis at Mar 2, 2006 at 4:02 pm
    * Brian Kirkbride [2006-03-02 15:20]:
    Nilson Santos Figueiredo Junior wrote:
    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;
    I think that is what he was requesting, actually.

    His problem was with code like this:

    sub method {
    return $results[0] if scalar(@results) == 1;
    return wantarray ? @results : \@results;
    }

    Which really is a pain, IMHO.
    Exactly.

    Some time ago I had to use a config module that worked like that.
    Banging your head against the wall is more fun than such an API,
    believe me. :-(

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Matt S Trout at Mar 1, 2006 at 6:29 pm

    On Wed, Mar 01, 2006 at 03:15:25PM -0300, Nilson Santos Figueiredo Junior wrote:
    On 3/1/06, A. Pagaltzis wrote:
    Please don't. Every time I have to use such an API it makes me
    cry. :-( Making the type of the return value dependent on its
    value is a breathtaking pain in the rear end. It causes code
    that's gunked up with gobs of `ref $foo eq 'ARRAY'` checks.
    I'm not sure when you'd need to actually check anything like that.

    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;

    I, myself, actually like this sort of API since it allows *me* to
    choose what's more convenient instead of relying on the module
    author's choice.
    Unless you're running under Template Toolkit, in which case the choice is
    always "list context".

    --
    Matt S Trout Offering custom development, consultancy and support
    Technical Director contracts for Catalyst, DBIx::Class and BAST. Contact
    Shadowcat Systems Ltd. mst (at) shadowcatsystems.co.uk for more information

    + Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +
  • Christopher H. Laco at Mar 1, 2006 at 6:46 pm

    Matt S Trout wrote:
    On Wed, Mar 01, 2006 at 03:15:25PM -0300, Nilson Santos Figueiredo Junior wrote:
    On 3/1/06, A. Pagaltzis wrote:
    Please don't. Every time I have to use such an API it makes me
    cry. :-( Making the type of the return value dependent on its
    value is a breathtaking pain in the rear end. It causes code
    that's gunked up with gobs of `ref $foo eq 'ARRAY'` checks.
    I'm not sure when you'd need to actually check anything like that.

    If you want an array ref call it like:

    my $result = Class->method;

    If you want a list of values call it like:

    my ($result) = Class->method;

    I, myself, actually like this sort of API since it allows *me* to
    choose what's more convenient instead of relying on the module
    author's choice.
    Unless you're running under Template Toolkit, in which case the choice is
    always "list context".
    Right. I learned that the hard way in Handel. :-/

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 187 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060301/32bea309/attachment.pgp
  • Aristotle Pagaltzis at Mar 1, 2006 at 7:49 pm
    * Nilson Santos Figueiredo Junior [2006-03-01 19:20]:
    On 3/1/06, A. Pagaltzis wrote:
    Please don't. Every time I have to use such an API it makes me
    cry. :-( Making the type of the return value dependent on its
    value is a breathtaking pain in the rear end. It causes code
    that's gunked up with gobs of `ref $foo eq 'ARRAY'` checks.
    I'm not sure when you'd need to actually check anything like
    that.

    If you want an array ref call it like:

    my $result = Class->method;
    Except Carl?s suggestion was that this would sometimes return a
    value, not an array ref; depending on whether there?s only one
    value or several.

    Regards,
    --
    Aristotle Pagaltzis // <http://plasmasturm.org/>
  • Garrett, Philip (MAN-Corporate) at Mar 1, 2006 at 7:08 pm
    -----Original Message-----
    From: catalyst-bounces at lists.rawmode.org
    [mailto:catalyst-bounces at lists.rawmode.org] On Behalf Of Nilson Santos
    Figueiredo Junior
    Sent: Wednesday, March 01, 2006 1:15 PM
    To: The elegant MVC web framework
    Subject: Re: [Catalyst] html-widget bug or design?
    On 3/1/06, A. Pagaltzis wrote:
    Please don't. Every time I have to use such an API it makes me cry.
    :-( Making the type of the return value dependent on its value is a
    breathtaking pain in the rear end. It causes code that's gunked up
    with gobs of `ref $foo eq 'ARRAY'` checks.
    I'm not sure when you'd need to actually check anything like that.
    * Carl Franks [2006-03-01 13:45]:
    If there's only one by that name, return it. If there's more that
    one, return a list in array context, an array-ref in scalar context.
    If you want an array ref call it like:

    my $result = Class->method;
    Are you sure it's an arrayref? What about the "if there's only one by
    that
    name, return it" rule?

    Philip

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedMar 1, '06 at 12:38p
activeMar 8, '06 at 5:18p
posts18
users8
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase