old version of @website.route would wrap the base method within a
decorator, and endpoint_is_enumerable had to dig into the decorator to
get the original function (and be able to inspect it).
@website.route has been simplified and no longer wraps the function,
just adds a pair of attributes to it (and so does the base
@http.route), so don't dig into anymore, inspect rule.endpoint
directly.
bzr revid: xmo@openerp.com-20131202102525-8jsondrr1649c8t8
# Through the menu
Rather than output a generic error (500 due to an IntegrityError),
return a templated 409 letting the user either visit the
page-which-already-exists-with-the-name-he'd-picked or open the page
creation dialog again for a second round.
An alternative would be to promote the website.prompt use to
full-blown dialog as a result of selecting "New Page" and handle the
"page already exists" case without even closing the dialog.
# Through the link dialog
Added an RPC call to check if a page already exists (essentially a
cheaper version of opening /page/whatever and checking whether it's a
200 over JSON-RPC), if the page matching the completion term already
exists, do *not* add the choice of creating the page, only provide
completions from existing pages.
bzr revid: xmo@openerp.com-20131126160148-wrk4zvz9istscwa0
After discussion and addition of support for the methods parameter (on
@route), it's been determined that:
* POST endpoint must set up method correctly
* **kw on GET endpoints must be completely optional, mandatory query
arguments should be added as formal parameters without a default
values
* URLs can thus be generated for methods with **kw, simply by ignoring
it entirely
bzr revid: xmo@openerp.com-20131119154254-vp0zfnzjvi451vv0
* add filtering in enumerate_pages directly
* make ModelConverter use name_search for generation
todo: per-request name_get caching/coalescing?
bzr revid: xmo@openerp.com-20131119102117-p7de3t93qex1n28q
I don't see a good way to reverse `/page/<path:path>` for Website.page
during pages listing, so reintoduce explicit handling of that crap.
Ideally it would be possible to plug in new converters per db and
create some sort of PageConverte, *or* add a reverse operation to
controllers on top of converters (-> controller-specific url
generation even with un-generable converters).
bzr revid: xmo@openerp.com-20131112120814-ekt1rzlzj06pzypw
* most controllers turn out to be complete cork and thus can't be
reversed
* fixup a pair of simple controllers
TODO:
* fixup more controllers
* how can labels/page names be produced?
* grouping/categories of links?
At a high level, workings are pretty simple:
* iterate on all rules (every url pattern produces a werkzeug rule)
* check if the url can make sense as a link: GET, http, no auth or
public auth, coming from the CMS (no web client links) and all
converters can generate values for themselves (e.g. a url with an
`int` converter can't be generated as there is no finite set of
integers, let alone one small enough to make sense to show to users)
* check if the controller function bound to the URL can use the URLs
we can generate (no **kwargs as that means arbitrary get|post
parameter, no query param without a default value (a query param is
a parameter which does not come from a URL/rule converter))
* use rule converter(s) to generate a matrix of values, and build urls
from these
bzr revid: xmo@openerp.com-20131108132615-2n7t1vj8hz9v9eis
context was not passed while setting request.website
forced to refactor a bit in order to make true model methods but stopped
because it will be duplicated work when migrating to the new api
bzr revid: fme@openerp.com-20131107151400-9dmtgz7xs34qmbmq
Fabien Pinckaers
Xavier Morel
Fabien Meghazi
Christophe Matthieu
Antony Lesuisse