markmin, t2, t3, cube9 etc. (important update)

[mdipierro]

# Preamble

As you know T2 and T3 are deprecated. Some time ago I started a
reimplementation of T3 called cube9. I got stuck. I now re-factored it
completely

-----
http://code.google.com/p/cube9/ (requires web2py trunk)
-----

It uses markmin:

-----
http://web2py.com/examples/static/markmin.html
-----

cube9 is not completely finished by it works and it already much much
better than T2/T3.

# What is cube9?

Cube 9 is a possible replacement for the welcome app. It is identical
to welcome except that

- has a different layout
- contains a plugin called plugin_wiki (a plugin on steroids)
- use a JS menu

## What is plugin_wiki?

Plugin_wiki allows a developed (auth.user_id==1 or anybody member of
group 'editor') to create dynamic pages on the fly by visiting

``http://127.0.0.1:8000/cube9/plugin_wiki/page/my-new-page-slug``

In fact you do not need cube9 to run plugin_wiki, you can use it for
any web2py app. You can use it to add help pages. You can use to allow
your users to edit pages.

Pages are edited using markmin (via a modified markitup JS editor to
support markmin).
This email is written using markmin syntax.

## Why plugin_wiki is a plugin on steroids?

Because it includes under one name (plugin_wiki) other plugins as
embeddable widgets (mediaplyer, comments, tags, multiselect, and more)
and there is a way to access them using the markmin syntax.

## A first example

For example to include a youtube video in a page you do

``
name: youtube
code: x1w8hKTJ2Co
``:widget

- The double reversed quotes tell markmin to deal with content in a
special way.
- The :widget tells plugin_wiki to override default behavior and treat
this as an embedded widget
- the content is treated as parameters (youtube being the name of the
widget and x1w8hKTJ2Co being the name of the youtube video you want to
embed).

There are MANY widgets you can already embed.

## More examples

### Tagging

``
name: tags
``:widget

### jqGrid list users

``
name: jqgrid
table: auth_user
``:widget

### Enbedding a form

``
name: create
table: auth_user
``:widget

### Embedding template code

``
counting... {{for i in range(10):}}{{=i}}{{pass}}
``:template


## Inner workings

For a list of widgets look into the static methods of
PluginWikiWidgets in models/plugin_wiki.py. The arguments of the
methods translate into variables. For example

``
class PluginWikiWidgets: # in models/plugin_wiki
@staticmethod
def abd(x,y=6): ....
``:code_python

is called by

``
name: abc
x=5
``:widget

(y is optional because y has a default, 6).

### List of Widgets

Here is a list of widgets as of today:

``
def read(table,record_id=None): ...
def
create(table,message='',next='',readonly_fields='',hidden_fields='',default_fields=''): ...
def
update(table,record_id='',message='',next='',readonly_fields='',
hidden_fields='',default_fields=''): ...
def select(table,query_field='',query_value='',fields=''): ...
def search(table,fields=''): ...
def jqgrid(table,fieldname=None,fieldvalue=None,col_widths='',

_id=None,fields='',col_width=80,width=700,height=300): ...
def pie_chart(data,names,width=300,height=150,align='center'): ...
def bar_chart(data,names,width=300,height=150,align='center'): ...
def youtube(code,width=400,height=250): ...
def vimeo(code,width=400,height=250): ...
def mediaplayer(src,width=400,height=250): ...
def comments(table='None',record_id=None): ...
def tags(table='None',record_id=None): ...
def tag_cloud(): ...
``:code_python

### Global variables

there are two important globals variables:

+ plugin_wiki_editor = True # or false to disable the wiki
+ plugin_wiki_level = 3 # for everything, 2 for wiki+widgets, 1 for
normal wiki (no code, widgets)

## Conclusions:

There is more to this already implemented and there is more to come.
For start you can run everything on GAE. Some pages with slug meta-*
have special meaning and can be used to edit header, footer, menu,
sidebar of cube9 layout. meta-code can be used to define new tables,
procedures and services.

For security reasons code and widgets can be disabled.

I will make a video about this as soon as I have the time (and free up
enough memory).

Please test it and send me comments. Enjoy!

Massimo


P.S. I apologize for these names.

[Júlio Monteiro]

Hello Massimo,

Looks very promising! Will try it today, as soon as I get home.

Also I like the name too, better than T(n). :)

A question: would it be possible to set "plugin_wiki_level" per page so you can have special system pages and other pages users can edit or create?

Or even better, certain admin users could create full power pages and normal user could only create content pages. What do you think?

Cheers,

Julio Monteiro

[mdipierro]

A few clarifications....

The plugin_wiki that ships with cube9 has full revision history and
logging (including for pages that contain code)

The philosophy is the same as T3. Evey URL is a wiki. You program by
editing pages. You can widgets in the code (crud, media, social, etc)
or native web2py template code. Everything is in the database.

Pages can be public, private and roles (they set permissions using
web2py role based access control)

Pages can have attachments and link them. They are managed via model
popup form.

Some widgets use ajax under the hood.

You can move plugin_wiki into your existing app and add pages/url this
way.

Massimo

On 7 Lug, 07:27, mdipierro <mdipie...@cs.depaul.edu> wrote:
> # Preamble
>
> As you know T2 and T3 are deprecated. Some time ago I started a
> reimplementation of T3 called cube9. I got stuck. I now re-factored it
> completely
>
> -----

>    http://code.google.com/p/cube9/(requires web2py trunk)

[mdipierro]

You can do that. Just create logic in db.py to determine which page is
being requested and then set it.

On 7 Lug, 07:42, Júlio Monteiro <jmonte...@gmail.com> wrote:
> Hello Massimo,
>
> Looks very promising! Will try it today, as soon as I get home.
> Also I like the name too, better than T(n). :)
>

> A question: would it be possible to set "*plugin_wiki_level*" per page so

> you can have special system pages and other pages users can edit or create?
> Or even better, certain admin users could create full power pages and normal
> user could only create content pages. What do you think?
>
> Cheers,
> Julio Monteiro
>

> On Wed, Jul 7, 2010 at 9:27 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > # Preamble
>
> > As you know T2 and T3 are deprecated. Some time ago I started a
> > reimplementation of T3 called cube9. I got stuck. I now re-factored it
> > completely
>
> > -----

> >  http://code.google.com/p/cube9/(requires web2py trunk)

[mdipierro]

I am going to remane this cu29 since it has been brought to my
attention that there is a cube9.net and we do not want problems....

On 7 Lug, 07:51, mdipierro <mdipie...@cs.depaul.edu> wrote:
> You can do that. Just create logic in db.py to determine which page is
> being requested and then set it.
>
> On 7 Lug, 07:42, Júlio Monteiro <jmonte...@gmail.com> wrote:
>
> > Hello Massimo,
>
> > Looks very promising! Will try it today, as soon as I get home.
> > Also I like the name too, better than T(n). :)
>
> > A question: would it be possible to set "*plugin_wiki_level*" per page so
> > you can have special system pages and other pages users can edit or create?
> > Or even better, certain admin users could create full power pages and normal
> > user could only create content pages. What do you think?
>
> > Cheers,
> > Julio Monteiro
>
> > On Wed, Jul 7, 2010 at 9:27 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > # Preamble
>
> > > As you know T2 and T3 are deprecated. Some time ago I started a
> > > reimplementation of T3 called cube9. I got stuck. I now re-factored it
> > > completely
>
> > > -----

> > >  http://code.google.com/p/cube9/(requiresweb2py trunk)

[Júlio Monteiro]

Can we suggest names?

What about "cube2py" or "w2cube" or even simply "cube29"?

Julio Monteiro

[Jonathan Lundell]

On Jul 7, 2010, at 5:27 AM, mdipierro wrote:

> As you know T2 and T3 are deprecated. Some time ago I started a
> reimplementation of T3 called cube9. I got stuck. I now re-factored it
> completely
>
> -----
> http://code.google.com/p/cube9/ (requires web2py trunk)
> -----
>
> It uses markmin:
>
> -----
> http://web2py.com/examples/static/markmin.html
> -----

With markmin (or perhaps cu29 -- why that?), how does one reference local wiki pages without using their full URL? For example, in Wikipedia, this is a link: [[web2py]]. But in markmin it creates an anchor.

[Jonathan Lundell]

On Jul 7, 2010, at 5:42 AM, mdipierro wrote:

> The philosophy is the same as T3. Every URL is a wiki.

Would you elaborate a little on that statement, please?

[Thadeus Burgess]

This looks really awesome!

Name suggestion: Cube^2

--
Thadeus

[mdipierro]

you link pages with

[[this is the link text page:this-is-the-slug]]

and you include attachments with

[[this is an image attachment:id center 200px]]

On 7 Lug, 10:05, Jonathan Lundell <jlund...@pobox.com> wrote:
> On Jul 7, 2010, at 5:27 AM, mdipierro wrote:
>
> > As you know T2 and T3 are deprecated. Some time ago I started a
> > reimplementation of T3 called cube9. I got stuck. I now re-factored it
> > completely
>
> > -----

> >  http://code.google.com/p/cube9/(requires web2py trunk)

[mdipierro]

The idea is that any web app is a set of pages that contain stuff.
Some are public some are not, some have other permissions, some are
listed in a hierarchical menu some not. Therefore it should be
possible to develop as app as one creates a wiki, by adding pages and
filling the pages.

In web2py every URL is mapped into a action. An action is a function +
template.

In cu29 every URL (technically only those URL managed by the
plugin_wiki/page action) is a page. The page is described by the
markmin syntax and it can contain stuff because markmin allows to
include high level widgets (not to be confused with
db.table.field.widget).

You can have both together if you apply plugin_wiki from cu29 to your
apps.

Hope it makes sense.

[Jonathan Lundell]

On Jul 7, 2010, at 8:30 AM, mdipierro wrote:

> The idea is that any web app is a set of pages that contain stuff.
> Some are public some are not, some have other permissions, some are
> listed in a hierarchical menu some not. Therefore it should be
> possible to develop as app as one creates a wiki, by adding pages and
> filling the pages.
>
> In web2py every URL is mapped into a action. An action is a function +
> template.
>
> In cu29 every URL (technically only those URL managed by the
> plugin_wiki/page action) is a page. The page is described by the
> markmin syntax and it can contain stuff because markmin allows to
> include high level widgets (not to be confused with
> db.table.field.widget).
>
> You can have both together if you apply plugin_wiki from cu29 to your
> apps.
>
> Hope it makes sense.

Yes, thanks.

One more thing, for those of us who haven't followed the whole history (two more things, I guess): why 'cube'? why '9'?

[mdipierro]

I just made them up. In my IT departement they use the world cubes to
diffrent ways to view the same data. Mixing numbers and text makes it
less likely the name is trademarked. Turned out it is trademarked. :-(

cu29 refers to copper. It does not seem to be taken.

I am very bad with names. I am not attached to any of them.

My only concern is that I have been threatened to be sued before for
trademark issues and want to prevent that from happening again.

Massimo

[Chris S]

I've just loaded this from the mercurial source listed on google
code. Running on GAE (local dev server) and using the Web2py trunk
I'm getting:

ReservedWordError: Cannot define property using reserved word
'parent'. If you would like to use this name in the datastore consider
using a different name like parent_ and adding name='parent' to the
parameter list of the property definition.
<code object <module> at 03EE4E78, file "C:\Users\chris.sanders
\Documents\Misc\workspace\WebDev\applications\cube9/models/
db_cube9.py", line 1>

I'm not sure if that's an issue of me not having the absolute latest
trunk, but it seems like it's just an incompatibility with GAE in the
current varriable definition.

[mdipierro]

There should not be a db_cube9.py in the project.

Massimo

[mdipierro]

http://vimeo.com/13154869

On 7 Lug, 07:27, mdipierro <mdipie...@cs.depaul.edu> wrote:

> # Preamble
>
> As you know T2 and T3 are deprecated. Some time ago I started a
> reimplementation of T3 called cube9. I got stuck. I now re-factored it
> completely
>
> -----

>    http://code.google.com/p/cube9/(requires web2py trunk)

[mdipierro]

The google code repository is corrupted. There are lots of files that
do not belong there.... I will close it and open a new one later
today. Let's agree on a new name.

On 7 Lug, 12:31, mdipierro <mdipie...@cs.depaul.edu> wrote:
> http://vimeo.com/13154869
>
> On 7 Lug, 07:27, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> > # Preamble
>
> > As you know T2 and T3 are deprecated. Some time ago I started a
> > reimplementation of T3 called cube9. I got stuck. I now re-factored it
> > completely
>
> > -----

> >    http://code.google.com/p/cube9/(requiresweb2py trunk)

[Albert Abril]

I should say that the template used (seen in the video) is very pretty.

[Jonathan Lundell]

On Jul 7, 2010, at 8:25 AM, mdipierro wrote:

> you link pages with
>
> [[this is the link text page:this-is-the-slug]]

So page: is recognized by the wiki plugin?

If I'm understanding the syntax, and I may not be, I have a suggestion.

[[name]] and [[name#anchor]] should be wiki links; [[#anchor]] remains a link to a local anchor, wiki or not.

[[=name]] defines an anchor.

So (again if I'm following you), [[name]] would be a shortcut for [[name page:name]].

My reasoning is that [[link]] is so established (and convenient) a wiki notation that it should be preserved, and that defining an anchor is much less frequent, so the extra '=' is not much of a burden.

[Júlio Monteiro]

Back to naming, should we vote?

Here are the suggestions so far:

1) cu29

2) cube2py

3) w2cube

4) cube29

5) Cube^2

For me +1 for cube2py and +1 for cube29.

Which ones do you people prefer?

Cheers,

Julio Monteiro

[Kenneth]

I vote +1 cube2py and Cube^2 +1

Kenneth

[Albert Abril]

Same as Kenneth

I vote +1 cube2py and Cube^2 +1

[yamandu]

From those I prefer cube2py because of similarity with web2py and the
most important, sound!
I would like to sugest too, how about mix a little bit and come with
Wube ?

[mdipierro]

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?

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.

Massimo

[Jonathan Lundell]

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.

[mdipierro]

I do not have a strong opposition and I see the advantages in terms of
notation but I have two problems:

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

[Scott]

I just checked out the cube2py repository from code.google.com and am
attempting to run it on the Source branch of web2py 1.79.2 (2010-06-08
22:45:26). Attempting to run it generates this error:

Traceback (most recent call last):
File "C:\Users\scott\Documents\workspace\web2py\gluon
\restricted.py", line 178, in restricted
exec ccode in environment
File "C:\Users\scott\Documents\workspace\web2py\applications\cube2py/
views\default/user.html", line 40, in <module>
AttributeError: 'Auth' object has no attribute 'navbar'

I checked the included db.py and sure enough auth.navbar is not
defined. Suggestions?

Thanks in advance!

[Mathieu Clabaut]

I guess you should update web2py from the development repository (on google code)

-Mathieu

[mdipierro]

download the nigthly build from web2py.com/examples/default/dowload

On 8 Lug, 09:46, Mathieu Clabaut <mathieu.clab...@gmail.com> wrote:
> I guess you should update web2py from the development repository (on google
> code)
>
> -Mathieu
>

[selecta]

I like it very much, however I have the requirement of adding a wiki
with a wysiwyg interface, any chances on implementing that within
cube2py ... maybe using elRTE or is this just not feasible?
anyway nice work :)

On Jul 7, 2:27 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> # Preamble
>

> As you know T2 and T3 are deprecated. Some time ago I started a
> reimplementation of T3 called cube9. I got stuck. I now re-factored it
> completely
>
> -----
>    http://code.google.com/p/cube9/(requires web2py trunk)
> -----
>
> It uses markmin:
>
> -----
>    http://web2py.com/examples/static/markmin.html
> -----
>

> create(table,message='',next='',readonly_fields='',hidden_fields='',default­_fields=''): ...

[Scott]

I downloaded the nightly build and it's working correctly. Thanks!

[Jonathan Lundell]

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.

[aure]

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

[mdipierro]

Please feel free to propose for new features. That was exactly the
intention.

[Albert Abril]

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.

[mdipierro]

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.
>

[mdipierro]

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.

[Scott]

I think this should replace the Welcome application and the
documentation should be integrated into the web2py book. I'm
impressed with the complete rewrite! I like the way that you get
web2py-admin-esque functionality without having to use the admin
directly, and it all works through Google App Engine. It certainly
makes page creation easier.

Out of curiosity, would you need to use a custom routes.py to remove
(rewrite) "plugin_wiki" from the URL? I'd probably want to hide that
from casual users.

A few suggestions and questions:
- Consider an internally-hosted chart generator (e.g. jqPlot) in lieu
of Google Charts API; this will allow the charts to generate behind
corporate firewalls
- Can the tag cloud be made hyper-linkable? That is to say, clicking
on a word in the tag cloud might show a list of relevant tagged pages.
- What is the future direction of cube2py? It seems that most of the
functionality coded in the View can be replaced with cube2py and
markmin. It also replaces some of the code normally located in the
Controller such as CRUD and jqGrid functionality. If this is the
case, is it the intent to replace the admin with cube2py?

Thanks!

[mdipierro]

Answers below

On 9 Lug, 21:42, Scott <blueseas...@gmail.com> wrote:
> I think this should replace the Welcome application and the
> documentation should be integrated into the web2py book.  I'm
> impressed with the complete rewrite!  I like the way that you get
> web2py-admin-esque functionality without having to use the admin
> directly, and it all works through Google App Engine.  It certainly
> makes page creation easier.
>
> Out of curiosity, would you need to use a custom routes.py to remove
> (rewrite) "plugin_wiki" from the URL?  I'd probably want to hide that
> from casual users.
>
> A few suggestions and questions:
> - Consider an internally-hosted chart generator (e.g. jqPlot) in lieu
> of Google Charts API; this will allow the charts to generate behind
> corporate firewalls

This is a good point. I will do it.

> - Can the tag cloud be made hyper-linkable?  That is to say, clicking
> on a word in the tag cloud might show a list of relevant tagged pages.

Can be done but right now there is a logic problem. Which pages should
the tags link to? I guess wiki pages with the names of the tags?

> - What is the future direction of cube2py?  It seems that most of the
> functionality coded in the View can be replaced with cube2py and
> markmin.  It also replaces some of the code normally located in the
> Controller such as CRUD and jqGrid functionality.  If this is the
> case, is it the intent to replace the admin with cube2py?

It cannot be a replacement. In admin you edit files and code is in
files. With cube2py you edit only the database and code is in the
database. I think they must coexist.

> Thanks!

[Scott]

Thank you Massimo! My comments are below.

> > - Can the tag cloud be made hyper-linkable?  That is to say, clicking
> > on a word in the tag cloud might show a list of relevant tagged pages.

> Can be done but right now there is a logic problem. Which pages should
> the tags link to? I guess wiki pages with the names of the tags?

Yes, I envisioned a list of wiki pages with that associated tag.
Something like:
Page Name (hyperlinked) | Synopsis (first 30 characters or so) |
Associated Tags | Date Modified

> > - What is the future direction of cube2py?  It seems that most of the
> > functionality coded in the View can be replaced with cube2py and
> > markmin.  It also replaces some of the code normally located in the
> > Controller such as CRUD and jqGrid functionality.  If this is the
> > case, is it the intent to replace the admin with cube2py?

> It cannot be a replacement. In admin you edit files and code is in
> files. With cube2py you edit only the database and code is in the
> database. I think they must coexist.

Thank you for the explanation.

[weheh]

I am very impressed by the capabilities of this system. Less so by the
name, which is non-descriptive and possibly confusing to newbies, like
T2 and T3 in the past. I think it will be more self-descriptive if the
name has wiki or some variant thereof in it. Nothing great is coming
to mind, but I'll throw out some ideas here:

- wikiweb2py
- webiki2py
- wikieb2py
- web2py2wiki
- wiki2web2py
- web2pyiki
- web2pwiki
- web2piki
- web2wiki
- wiki2py

If I had a couple of beers, I could probably do a lot better :)

[Álvaro Justen]

I like so much the name cube9!
PLEASE don't put it 'cu29' because 'cu' in Portuguese is...well, not a
good word. :-)

--
Álvaro Justen - @turicas
 http://blog.justen.eng.br/
 21 9898-0141

[aure]

Comment below

I understand that it cannot be a replacement. And this creates a
difficulty for beginners (like me...) as it is sometimes hard to see
where to put/do what, as there might be different ways to do things.
This can become problematic because not all ways are as robust/clean/
efficient/secure... as they should be. Therefore I believe it would be
nice and welcome if a few examples/guidelines/explanations regarding
this issue would be givenn somewhere...

Thanks!


> > Thanks!
>
>

[Jonathan Lundell]

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:
>
> 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.

It's pretty common (and useful) in Wikipedia. And it needn't be literally the slug. As in Wikipedia,

[[link]]

would imply that 'link' is the text and slug(link) the slug for the URL. In Wikipedia, that's most commonly the space-to-underscore conversion, so

[[some link]]

becomes

<a href="some_link">some link</a>

I agree that coupling is an issue, but is the answer to make the wiki syntax worse? I think that the wiki should be a first-class user of its syntax. That is, it shouldn't be necessary to compromise its syntax just so markmin can be 100% shared.

How about explicitly initializing markmin (at least optionally)? Give it a base address, that slugs could be appended to. Or subclass markwiki from markmin?

Or at the very least allow a shortcut.

[[name page:slug]]

could use the Wikipedia convention

[[name|slug]]

with [[name|]] implying [[name|name]]

Alternatively (see base addresses below), [[name page:slug]] could be abbreviated [[name :slug]], and [[name :]] would imply [[name page:name]] as above.

One more thing wrt the "base address" idea above. Suppose we were using the new wiki as the basis for a web2py reference wiki. One of the things that the wiki needs to do is to link to some external standard references. This is not an attempt at a real syntax--just something to give the general idea.

[[base:slice http://www.web2pyslices.com/main/slices/take_slice/%(slug)]]

and then:

[[Audit trail slice:35]]

...would do the obvious thing.

So we could have base addresses defined for slices, the manual, the Python reference pages, etc.

Side note: the base address definition format needn't be a command in wiki syntax; it could be an initialization call related to the plugin. In particular, we don't want to have to embed it in every page (though the *ability* to do so would be handy). Or every page could implicitly "include" a master page, if present.

[Timmie]

Hello,
cube2py looks awesome.

> It uses markmin:
>
> -----
>    http://web2py.com/examples/static/markmin.html
> -----

I wonder why the syntax was not derived from restructured text or
alike?

[mdipierro]

I found restructured text to be too complex to parse.

[Timmie]

> I foundrestructuredtext to be too complex to parse.
What marup language do you use as template?
Is there any markup format you use as design schedme for markmin?

[mdipierro]

No that I can think of.

[Tim Michelsen]

> No that I can think of.

Would be good if you could use one of the major markup languages as input:
http://en.wikipedia.org/wiki/List_of_lightweight_markup_languages

Currently, your markmin seems to be like Texy (http://texy.info/en/)

A look at converters show how is the life could be:
* http://txt2tags.sourceforge.net/
* http://johnmacfarlane.net/pandoc/

So I may suggest to adapt markmin to one of the major lanuages and then
use a converter.

Regards.

[Bruno Rocha]

Texy features are very good http://texy.info/en/syntax

but the syntax is ugly...

I would like markmin to implement all that features in a beauty way.

2010/8/2 Tim Michelsen <timmic...@gmx-topmail.de>

--

http://rochacbruno.com.br

[Timmie]

> Texy features are very goodhttp://texy.info/en/syntax

> but the syntax is ugly...
>
> I would like markmin to implement all that features in a beauty way.

OK, but being able to convert text from other formats (HTML, ODF,
wiki) into markmin would be good. Thus I suggest to lean on existing
markup.

[mdipierro]

This has been in trunk for some time:

>>> from gluon.html import markmin_serializer
>>> html='<div><h1>Header</h1><p><a href="http://google.com">link</a><b>bold</b></div>'
>>> TAG(html).flatten(markmin_serializer)
'#Header\n\n[[link http://google.com]]**bold**\n\n'

You can use it to convert markdown syntax:

>>> from gluon.contrib.markdown import WIKI
>>> md = '#Header\n\n[link](http://google.com)*bold*\n\n'
>>> TAG(WIKI(md).xml()).flatten(markmin_serializer)
"#Header\n\n [[link http://google.com]]''bold''\n\n "

[mdipierro]

and the markitup js that ships with plugin_wiki has been modified to
support markmin too.

On Aug 3, 3:20 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> This has been in trunk for some time:
>
> >>> from gluon.html import markmin_serializer
> >>> html='<div><h1>Header</h1><p><a href="http://google.com">link</a><b>bold</b></div>'
> >>> TAG(html).flatten(markmin_serializer)
>

> '#Header\n\n[[linkhttp://google.com]]**bold**\n\n'

>
> You can use it to convert markdown syntax:
>
> >>> from gluon.contrib.markdown import WIKI
> >>> md = '#Header\n\n[link](http://google.com)*bold*\n\n'
> >>> TAG(WIKI(md).xml()).flatten(markmin_serializer)
>

> "#Header\n\n [[linkhttp://google.com]]''bold''\n\n "

[Timmie]

> This has been in trunk for some time:
>
> >>> from gluon.html import markmin_serializer
> >>> html='<div><h1>Header</h1><p><a href="http://google.com">link</a><b>bold</b></div>'
> >>> TAG(html).flatten(markmin_serializer)
>

> '#Header\n\n[[linkhttp://google.com]]**bold**\n\n'

>
> You can use it to convert markdown syntax:
>
> >>> from gluon.contrib.markdown import WIKI
> >>> md = '#Header\n\n[link](http://google.com)*bold*\n\n'
> >>> TAG(WIKI(md).xml()).flatten(markmin_serializer)
>

> "#Header\n\n [[linkhttp://google.com]]''bold''\n\n "

What about adding a converter option to pligin_wiki:
User pastes markdown but internally markmin is saved.

Regards.

[mdipierro]

why?