I never though somebody sould have more than 1000 revisions. Let's think about a good solution. The one you propose may be ok.
On Aug 2, 3:54 pm, Bruno Rocha <rochacbr...@gmail.com> wrote: > - Page History > page history does not works on > GAE,http://web2pybrasil.appspot.com/init/plugin_wiki/page_history/home Fails > and raises a ticket > > There is a limit to history entries per page? > > I mean, if I edit a page too many times this will create too many entries in > plugin_wiki_page_history > I think it needs a limit, may be 20 entries per page like a FIFO > > 2010/8/1 Bruno Rocha <rochacbr...@gmail.com> > > > > > I am developing and writing a lot with plugin_wiki (cube2py). I already > > have some suggestions, observations and have also found some bugs. > > As I'm finding more issues, I will posting here in this thread. If someone > > else has something to add, enjoy the thread. > > > I am working now on this page : > >http://web2pybrasil.appspot.com/cursoweb2py/ > > > * > > * > > *Bugs I Found:* > > > -* **Comments Widget* > > I noticed that the comments widget is restricted to logged in users, the > > code that generates the widget has requires_login (), this is great for > > protecting users not logged in to write. > > however, as the same widget generates the form for adding a comment, and > > also generates a list of comments to display, it is not possible to display > > existing comments to a user who is not logged. > > I suggest dividing into two widgets, one to generate the form of insertion, > > and this would be protected. And another to generate a list of existing > > comments, and this would free reading. this last could be used in another > > place eg: to show recent comments for a page. > > > -* Searches with crud.search and jqgrid on GAE* > > I got error using crud.search and jqgrid widgets, as GAE does not allow to > > perform LIKE, StartsWIth, EndsWith, Contains, etc, while do not have any > > workarround, I think that options should be disabled When it is detected > > that is working in GAE > > > *Suggestions:*( Too many things. Sorry ) > > > - *Widget_Builder:* > > Binds the code generated by widget builder direct to the page content > > editor, I think it is not hard to do with JavaScript, preventing the > > copy-paste when using widget builder > > > - *Widget* *Messages customization* > > Include the total capacity for customize the output messages in the > > standard widgets. "load_action" and "load_url" eg uses AJAX and display > > the message "loading", it would be nice to have how to pass as a parameter, > > a new message to be displayed, it is usefull for translating. > > > - *Blank lines, white space:* > > Markdown for example set spaces by using two blank spaces at the end of > > each line to make a break, I'm developing a lot with plugin_wiki and had to > > create a function just to give me white space and blank lines. > > ``{{=br(2)}}``:template > > > - *Categories:* > > wiki or any other type of page created with plugin_wiki, IMHO, will need > > some kind of category management. it is not difficult to implement as > > standard, without having to create custom widgets, as I had to do. > > > - *Search: * > > I created a custom widget that performs searches in titles, slugs, and body > > of the pages, and it is running on GAE, I believe this should be used as a > > widget placed on the meta-header, or meta-sidebar for example. but could > > be part of the plugin itself, considering that this is a basic need of any > > wiki page. > > > - *Link Targets:* > > I do not think there is a specific reason not to open external links in a > > wiki page, wikipedia does, it would be interesting to receive the parameter > > "target" by default in the marking of a [[link]] as [[linktitle > >http://linkurl blank]] > > > - *Preview and Saving: * > > It is very annoying having to submit the page every time we need to save, > > then to have a preview, the saving could happen with AJAX and have option to > > view a Preview window. > > > - *Lists:* > > In ordered and unordered lists creates with - and +, Needs a way to create > > sublevels with lists, maybe -- and ++ > > - A Topic > > -- Subtopic of A Topic > > --- Subtopic of a subtopic of A Topic > > -- Another subtopic of A Topic > > > + A Topic > > ++ Subtopic of A Topic > > +++ Subtopic of a subtopic of A Topic > > ++ Another subtopic of A Topic > > > - *Page auto reference:* > > It would be interesting to have a variable that works as ALIAS to reference > > the page itself, when I need to reference the current page into a widget I > > use {{= request.args(0)}} would be more interesting to use something like > > "THISPAGE" > > > - *Wiki Pages management: * > > Wiki Pages management "plugin_wiki / index" tends to get a little confusing > > as the number of existing pages grows, it would be interesting to have > > pagination, search, categorization. > > > - *Meta Pages: * > > As a developer I use a lot the page meta-code, but as the code grows, > > things start getting difficult to administer, would have the option to > > create more pages like meta-code, for example meta-code- xxx, > > meta-code-something, meta-code-anynameigive, and they have the same > > operation of the meta-code. > > > By Now , that's it. As Im using I will send more thoughts about it. > > I am available for any help or tests you need. > > > {{=thanks}} > > > --- > > rochacbruno.com.br > > @rochacbruno > > > 2010/8/1 mdipierro <mdipie...@cs.depaul.edu> > > > Fornow you can post here.Please send your comments asap because I am > >> about to revise it and write a book chapter about it. > > >> On 1 Ago, 04:55, Bruno Rocha <rochacbr...@gmail.com> wrote: > >> > Sorry again, I am creating a new thread about plugin_wiki. > > >> > I wonder if there is any public place where we can write suggestions, > >> > criticisms, and send questions exclusively about plugin_wiki, markmin > >> and > >> > cube2py? > > >> > -- > > >> >http://rochacbruno.com.br > > > -- > > >http://rochacbruno.com.br > > -- > > http://rochacbruno.com.br
