I think I forgot to post this: http://www.slideshare.net/mdipierro/cube2py-4709237
It is a summary of what is available. To use this in your own app, export plugin_wiki from admin and re- import it in your app. On 9 Lug, 07:50, mdipierro <mdipie...@cs.depaul.edu> wrote: > That would belong to admin not to cube2py although we could expose it > there. In principle you only need to edit routes.py (look into > applications/admin/controllers/default.py, def edit()) and then call > gluon.rewrite.load(routes='routes.py'). > > The problem is logical. If you use admin to edit routes and mess up > admin may not work anymore and you lose the ability to fix it. > > Massimo > > On 9 Lug, 07:10, Albert Abril <albert.ab...@gmail.com> wrote: > > > I thought about the idea of making a frontend (i.e. in the web admin) to > > edit routes.py and make more customizable the urls. > > But don't know how implement it. > > > On Fri, Jul 9, 2010 at 12:48 PM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > > Please feel free to propose for new features. That was exactly the > > > intention. > > > > On 9 Lug, 03:02, aure <aureliengir...@googlemail.com> wrote: > > > > Great news! Thanks for the work Massimo! > > > > > Being new to both, I myself still hesitate for my project between > > > > choosing a CMS and struggle with the programming vs. choosing web2by > > > > and struggle with all the things which come "for free" in a CMS... And > > > > Cube2py starts to bridge the gap in some ways :-) > > > > > I am sure that having these new features will bring more people to > > > > web2py. > > > > > Aurelien > > > > > On Jul 9, 12:20 am, Jonathan Lundell <jlund...@pobox.com> wrote: > > > > > > On Jul 7, 2010, at 3:47 PM, mdipierro wrote: > > > > > > > I do not have a strong opposition and I see the advantages in terms > > > of > > > > > > notation but I have two problems: > > > > > > I'm tied up today, so just a quick note. I understand and generally > > > agree with your caveats. I have a couple of thoughts on the subject that > > > I'll come back with. > > > > > > > The page:slug notation is handled by plugin_wiki, not by markmin. > > > > > > markmin just treats url, #anchor, url#anchor, page:slug all in the > > > > > > same way. plugin_wiki replaces the page:.. with /app/plugin_wiki/ > > > > > > page/.... after markmin has done its job. > > > > > > This decoupling was intentional to allow markmin to work without > > > > > > web2py and without plugin_wiki conventions. > > > > > > Your first suggestion would introduce coupling. Moreover it would > > > > > > provide a shortcut that encourage users to display the slug as text > > > of > > > > > > the link. I am not convinced this is a good idea. > > > > > > > Massimo > > > > > > > On 7 Lug, 17:24, Jonathan Lundell <jlund...@pobox.com> wrote: > > > > > >> On Jul 7, 2010, at 3:14 PM, mdipierro wrote: > > > > > > >>> Right now you can do links with > > > > > > >>> url > > > > > >>> [[name url]] > > > > > >>> [[name #anchor]] > > > > > >>> [[name url#anchor]] > > > > > >>> [[name page:slug]] > > > > > > >>> and define an anchor with > > > > > > >>> [[anchor]] > > > > > > >>> If I understand your suggestions: > > > > > >>> 1) also allow > > > > > >>> [[url]] > > > > > >>> [[url#anchor]] > > > > > >>> [[#anchor]] > > > > > >>> [[page:slug]] > > > > > >>> to allow un-named links. Q: how can a link not have a name? > > > > > > >> In your notation, I was thinking: > > > > > > >> [[slug]] would imply [[slug page:slug]] > > > > > > >> 'slug' would be used verbatim as the name, and with slug-encoding > > > > > >> as > > > the slug. > > > > > > >> A link would always have a name; it would just be implicit. That's > > > the Mediawiki convention, though they use a vertical bar to separate an > > > optional name from the slug. > > > > > > >>> 2) use [[=anchor]] to define an anchor to avoid conflict with 1. > > > > > > >>> if we do 1, we must do 2 but I would prefer [[!anchor]] then. > > > > > > >> Sure. > > > > > > >> Or [name:anchor], which corresponds to the html that it generates.
