[WF-Infra] WorldForge website needs

Philippe Jadin philippe at 123piano.com
Tue Oct 30 17:30:14 PST 2001


Hans Häggström wrote:

<snip good explanations of what we are trying to do>

> >4. 'Template' support in creation of new projects areas
> >(Not an absolute necessity immediately, but needed longterm)
> 
> *agree*
> This is something that I'd love to see too.  We could have a form for
> adding a new effort of some type, with checkboxes for wether
> to create an own news section, what sidebar sections are needed,
> and so on.


I think we could create a skeleton of a canonical project area. We could
create the folder structures needed with some default content in them,
and when needed, we would simply copy paste this skeleton.

We should also provide default "left bars" methods, such as
"screenshots", news, team, etc...
 
> Structured text is supported, as is HTML and plain text.
> 
> There's some interest in supporting DocBook documents too,
> but I don't know anything about the status of that.

If we use some specialized zope product that handle xml, it would be
quite easy to support xml (and then docbook):

http://www.zope.org/Members/rbickers/DocBookDocument
http://www.zope.org/Members/karl/ParsedXML/ParsedXML
 
> Currently we just have a bar with the different main areas of the site
> listed.  But listing the N first items under each could be done too,
> to make navigation to a specific place faster, and give some general
> idea of what the areas contain.
> 
> The items to show would be selected based on sorting order, and
> three dots might be used to indicate that there's other entries (that can
> be seen
> by going to the main page for that area).

Agreed, we could say "show the 8 subareas, sorted by order"
 
> Good point.
> We'll work on getting the top area navigation to show the subareas then.

I still think we should not limit "too much" the number of subarea we
show : if we have 9 subfolders under /project and we limit on 8, it's a
bit boring :). For games it's not a problem of course... (we can sort
them alphabetically or so)
 
> *nod*
> 
> The page edit form currently looks like this:
> http://moria.mit.edu:8080/wf/new/project/folder_edit_form
> 
> We also have an "Add Page" form, and an "Add News Item" form (currently
> the same as adding a page, but will probably be specialized for news items
> later).

I'd like to explain a bit more what we could do to ease editing of
"special areas"

We could define some "key folders" (folders with a "reserved ID" for
special purpose), for example news, team, screenshots, requests,
downloads...

Those special folders would be "detected" by the editing tool, and in
those case, an appropriate editing interface would be provided (for
example the news editing tool would be a simplified version of the page
editing tool).

Those tools would be shared by the whole site, and would be "trigered"
when you are in those "special" folder (they are special because of
their ID, nothing fancy).

This would fit well with the idea of having a skeleton for future
projects (create a news folder where needed, and the news editing
interface will be automagically displayed instead of the standard page
editing interface).
 

> For this we could perhaps have some system in the page edit form,
> or a separate "Add Image" / "Add File" link.

Either an ftp link, or a link to the zope interface, or again an
interface wrapper (like the current one for page editing).
 
> Also, often it is preferable to use the Media Repository to store the graphics,
> so that it is as easy as possible to reuse in other pages and for other
> purposes,
> or to update it when needed.

We could provide a link to the repository... 

A "recommended_repository_area" property could be added to send the user
to the most interesting part of the repository to add his work (if
possible). 

The repository could also send the user back to where he was, or giving
him the right link to add to his page after image submission (a pre
highlighted textarea containing the link, ready to be pasted in the
document).
 
> >10. Editing permissions
> >
> >Permissions should be able to be limited to subareas,
> >that is to say, individual products of the WF project. For
> >instance, if a developer needs to edit pages for fooclient,
> >they should be restricted to editing in that area. They
> >should not be able to wander into barclient and edit that
> >product's pages, unless they happen to be an active
> >developer on both products. Adding editors to more than
> >one area should be rather trivial to accomplish.

Zope built in, and one of the most interesting feature btw. (create a
user where needed)

hth

Phil



More information about the Infra mailing list