Age | Commit message (Collapse) | Author | Files | Lines |
|
that from schema
This allows doing some basic normalization (i.e. removing keys) from the
generated JSON.
|
|
|
|
|
|
|
|
|
|
|
|
Broken in previous commit.
|
|
- Add a 'custom_validations' setting
- Add tuwf->compile() to compile with that setting
- Add tuwf->validate() as alternative to formValidate()
The new tuwf->validate() uses internal state of TUWF::Request, which had
to be changed a bit to allow for more efficient validation.
Nested schemas in TUWF::Validate now also accept compiled schemas.
This stuff totally needs more documentation.
|
|
This should replace kv_validate() in the future. It's much more generic
and easier to extend.
Inspiration drawn from both kv_validate() and Brannigan.
|
|
|
|
|
|
|
|
I've tried various things to make TUWF::XML faster, but so far this is
the only change that actually has some effect. Can shave off about 1% to
3% of the page load time for pages that are heavy on TUWF::XML usage.
And '>' totally doesn't need to be escaped.
|
|
JSON::XS::encode_json() already does UTF-8 encoding for us, so we need
to treat its return value as binary.
|
|
This changes the way that before hooks signal whether to continue
processing or not, and is a breaking change for code that uses before
hooks with a false return value. This change does not affect the
pre_request_handler, so only code using the git version of TUWF is
affected.
This more generic control flow handling now also permits request
handlers for overlapping URL regexes, and tuwf->pass can be used to pass
control to subsequent handlers.
|
|
|
|
|
|
|
|
|
|
|
|
I think I should go over the entire tag list again before the next
stable release...
|
|
Apparently I wasn't using a full html5 reference. Or rather, html5 is
still quite a living standard.
|
|
Html;
Head sub {
End; # this would previously generate </html>, now it's an error.
};
|
|
|
|
Fixes an omission of 35776908b286b3f31a7d14f745f5ec6641c97fd6
|
|
|
|
Read: "I've no clue which style is best and everyone has their own
opinions, so let's just support everything!"
This is a breaking change for the :html5 group, but that group was only
added recently and did not yet make it into a stable TUWF release, so
there's little actual breakage.
|
|
|
|
Apparently %ENV doesn't like it when you decode_utf8() in-place, which
is, admittedly, not too surprising.
|
|
This fixes redirects in the scenario where the reqBaseURI() is not
correct, which may happen if there is a HTTPS-terminating proxy in
between that TUWF is not aware if (i.e. reqProtocol() is wrong) or when
the site is running on a non-standard port and this is not reflected in
reqHost().
I've always found the absolute Location header a silly requirement, so
I'm glad that RFC 7231 now allows a relative URI.
|
|
Seems much safer. I've not tested this patch as well as I'd like, I'll
do some more testing later to see if I broke something.
|
|
This only catches trivial malicious url-encoding attacks; Such control
codes can still get in through multipart form data or perhaps even URLs.
I'll see if I should protect against those other injection methods, too.
|
|
|
|
|
|
For the same reason that I removed the resInit call from resRedirect.
|
|
I removed the part about backward compatibility. Not that I will now
fully guarantee that there won't be any breaking changes, but there's a
bit too much TUWF-using code around that breaking major stuff is only
going to cause me a lot of work.
|
|
|
|
There are many of them, and some may clash with commonly exported
functions by other modules. So instead of ucfirst()ing only a few
special ones, I decided to be consistend and ucfirst everything. It's
slightly uglier, though. :(
|
|
This is kind-of a breaking change, but the HTML5 doctype is more
compatible than xhtml1-strict.
This change is a bit silly when everything else in TUWF::XML is still
built for XHTML rather than HTML5, but I'll add some proper HTML5
support in a bit.
|
|
|
|
Such as DBD::SQLite. Which is quite a pity, because param logging is
pretty damn useful. I'll see if it's easy to write a workaround for.
|
|
|
|
|
|
The primary motivation behind TUWF::hook() is to allow individual
modules to register their own hooks, without requiring some centralized
coordination.
While I was at it, I also noticed some odd behaviour around the old
post_request_handler and error_*_handlers, in which the response was not
even initialized in some cases. These changes should guarantee that a
response has always been initialized whenever any handler is called, and
that a dbCommit or dbRollback is always performed as appropriate.
|
|
This changes the format of the 'log_queries' logs a bit, in order to
support non-numeric bind parameters. It also changes the structure of
the tuwf->{_TUWF}{queries} array, which will break some debugging code
in VNDB.
The primary goal of this change is to make it easier to use TUWF with
other modules on CPAN. The following should now work, without losing the
logging & profiling that TUWF::DB offers:
use TUWF;
use SQL::Yapp dbh => sub { tuwf->dbh };
sub somefunc {
my @usernames = sqlFetch{SELECT username FROM users};
};
|
|
This moves *all* of an applications config & state into the TUWF object,
thus making it possible (but still quicky) to host multiple sites in one
process by assigning different objects to $TUWF::OBJ.
And while I'm normally not a huge fan of run-time checking of function
arguments, the TUWF::any() function typically is only ever called at
program initialization. This may catch some bugs that might otherwise be
a pain to debug.
|
|
Once again inspired by Dancer2. The main improvements over
TUWF::register() are:
- Support for other HTTP methods than HEAD/GET/POST
- HTTP method filtering in the routing code
- Differentiate between literal and regex routes
- Mandate 'tuwf->capture()'
- Include the leading slash, to make it more explicit that it matches
the entire path.
I've wanted to make that last change back in
55cbbb319a135dbddfbfdd989bc0cb364edef81d, but couldn't because that
would break a lot of code. TUWF::register() still works like it used to,
so these additions shouldn't break anything.
|
|
Another inspiration from Dancer2. While Dancer2 exports a whole bunch of
such functions, TUWF's functionality is already mostly contained in a
single object, so a single function will do nicely.
|
|
(Inspired by Dancer2's captures())
|
|
Just a minor cleanup.
|