App::I...equest(3pm)

πŸ“¦
version 0.57 Β· 2 versions
  • 0.57 Β· debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking (latest)
  • 0.57 Β· ubuntu jammy
, in debian bookworm, debian trixie, ubuntu noble, ubuntu resolute, ubuntu stonking

πŸ’– App::Info::Request β€” the lil request object that carries the tea πŸ’–

okay so bestie, this is the manual for App::Info::Request, which lives in the User Contributed Perl Documentation section of the man pages (3pm). pull up a chair, grab a strawberry πŸ“, and let's get into it.


✨ NAME ✨

App::Info::Request β€” it's the App::Info event handler request object. that's it, that's the name, no notes πŸ’…


🌸 SYNOPSIS 🌸

here's the vibe, fr fr β€” inside an App::Info::Handler subclass you do this:

# In an App::Info::Handler subclass:
sub handler {
    my ($self, $req) = @_;
    print "Event Type:  ", $req->type;
    print "Message:     ", $req->message;
    print "Error:       ", $req->error;
    print "Value:       ", $req->value;
}

look at her go πŸ‘‘ that's the whole flow right there.


πŸ¦‹ DESCRIPTION πŸ¦‹

okay so picture this: objects of this class get passed to the handler() method of App::Info event handlers. and ngl, this class is mostly gonna be your fave if you're the kind of person who implements App::Info::Handler subclasses. that's the audience. that's you, probably πŸ™ˆ

the way it works is: every single event triggering method in App::Info constructs a brand new App::Info::Request object and initializes it with its own arguments. then that App::Info::Request object is the sole argument passed to the handler() method of any and all App::Info::Handler objects chilling in the event handling chain. periodt.

so if you wanna build your own App::Info event handler? this is literally the object you have to be besties with. go read the App::Info::Handler documentation for the deets on making custom event handlers, iykyk.

each of the App::Info event triggering methods constructs an App::Info::Request object with different attribute values. so pls pls pls consult the documentation for the event triggering methods in App::Info, because that's where the values assigned to the App::Info::Request object are documented. then, in your event handler subclass, check whatever the type() method hands back so you know what kind of event request you're dealing with and can handle it appropriately. vibe check first, always πŸ’…


🌈 INTERFACE 🌈

the following sections document the App::Info::Request interface. buckle up, it's a short ride but it's a cute one πŸŽ€

πŸŽ€ Constructor πŸŽ€

new

my $req = App::Info::Request->new(%params);

this method is used internally by App::Info to construct new App::Info::Request objects and hand them off to event handler objects. generally you won't need it β€” unless you're testing custom App::Info::Handler classes, in which case go off, bestie 🫢

the parameters to new() are passed as a hash of named parameters that correspond to their like-named methods. the supported parameters are:

  • type
  • message
  • error
  • value
  • callback

see the object methods documentation below for the details on these object attributes. no skimming, okay? 😀

πŸ’œ Object Methods πŸ’œ

key

my $key = $req->key;

returns the key stored in the App::Info::Request object. the key is what the App::Info subclass uses to uniquely identify the info it's harvesting β€” like the path to an executable, for example. request handlers might use it to check stuff, like whether an option was passed on the command-line. iconic behavior honestly.

message

my $message = $req->message;

returns the message stored in the App::Info::Request object. typically it's informational, or an error message, or a prompt message. it's giving "here's what's happening" energy ✨

error

my $error = $req->error;

returns any error message associated with the App::Info::Request object. this one is typically there so you can display it to users when callback() returns false. it's the sad-but-informative one 😭

type

my $type = $req->type;

returns a string representing the type of event that triggered this request. the types are the same as the event triggering methods defined in App::Info. as of this writing, the supported types are:

  • info
  • error
  • unknown
  • confirm

be sure to consult the App::Info documentation for more details on the event types β€” don't be out here guessing, bestie πŸ™ˆ

callback

if ($req->callback($value)) {
    print "Value '$value' is valid.\n";
} else {
    print "Value '$value' is not valid.\n";
}

executes the callback anonymous subroutine supplied by the App::Info concrete base class that triggered the event.

  • if the callback returns false, then $value is invalid. πŸ’€
  • if the callback returns true, then $value is valid and can be assigned via the value() method. slay πŸ”₯
ngl important detail: the value() method itself calls callback() if it was passed a value to assign. see its documentation below for more info. don't say i didn't warn you.

value

my $value = $req->value;
if ($req->value($value)) {
    print "Value '$value' successfully assigned.\n";
} else {
    print "Value '$value' not successfully assigned.\n";
}

when you call value() without an argument, it simply returns the value currently stored by the App::Info::Request object. typically that value is the default value for a confirm event, or a value assigned to an unknown event.

when you pass it an argument, value() attempts to store that argument as a new value. BUT β€” and this is the plot twist 🫒 β€” value() calls callback() on the new value first:

  • if callback() returns false, then value() returns false and does not store the new value.
  • if callback() returns true, on the other hand, then value() goes ahead and stores the new value and returns true. periodt πŸ’…

🧚 SUPPORT 🧚

this module is stored in an open GitHub repository <http://github.com/theory/app-info/>. feel free to fork and contribute! we love a collaborative queen πŸ‘‘

please file bug reports via GitHub Issues <http://github.com/theory/app-info/issues/> or by sending mail to bug-App-Info@rt.cpan.org <mailto:bug-App-Info@rt.cpan.org>. don't be shy, they wanna hear it πŸ’Œ


πŸ‘‘ AUTHOR πŸ‘‘

David E. Wheeler <david@justatheory.com>

absolute legend, we stan 🫢


🌟 SEE ALSO 🌟

  • App::Info documents the event triggering methods and how they construct App::Info::Request objects to pass to event handlers.
  • App::Info::Handler: documents how to create custom event handlers, which must make use of the App::Info::Request object passed to their handler() object methods.

the following classes subclass App::Info::Handler, and thus offer good exemplars for using App::Info::Request objects when handling events:

  • App::Info::Handler::Carp
  • App::Info::Handler::Print
  • App::Info::Handler::Prompt

go read them, they're giving ✨inspiration✨


Copyright (c) 2002-2011, David E. Wheeler. Some Rights Reserved.

this module is free software; you can redistribute it and/or modify it under the same terms as Perl itself.


and that's the whole page, bestie!! this one came out of perl v5.36.0 on 2022-12-06 β€” thanks for reading the whole thing, you're the main character fr fr πŸŽ€βœ¨πŸ’…πŸ¦‹πŸŒΈπŸ’–

πŸ“¦ where this page comes from