[albatross-users] Request for pre-specification enlightenment

[Matt Goodall]

On Thu, 2003-08-07 at 07:54, Max Romantschuk wrote:

> Now, here's what we wish to do:
> 
> A simple content management system, consisting of two main parts. The site-view,
> which is what all the nice users will see, and the admin-view, which we will see.
> 
> These two views need to show the same data, but in different perspective
> (presentation versus content-creation).

Just a thought but, depending on how integrated you want the site- and
admin-view parts to be, you *might* want to think about creating two,
distinct applications. Obviously, they can share common modules.
Whatever you think of that idea ...

For the site-view you will almost certainly want to use the random page
mixins which will allow the site's pages to be bookmarked by users and
indexed by search engines.

      * http://object-craft.com.au/projects/albatross/albatross/app-random.html
      * http://object-craft.com.au/projects/albatross/albatross/mixin-randpage-module.html

You may also want to consider overriding get_page_from_uri() (from the
RandomPageModuleMixin) in your application class to handle your pure
content rendering requirements. That will allow you to have URLs like
/about_me and /weblog/2003-08-08 rather than /index.php?pg=about_me, for
example.

      * http://object-craft.com.au/projects/albatross/albatross/mixin-randpage-module.html
      * http://object-craft.com.au/projects/albatross/wiki/get_5fpage_5ffrom_5furi_28_29_20example

You can also use the above technique with methods of the ResponseMixin
to send other type of data, such as images, to the browser. Obviously,
letting the web server handle this is more efficient but you could then
store your images in a content store/database along with all the other
content if you wanted to.

      * http://object-craft.com.au/projects/albatross/wiki/Sending_20non_2dHTML_20content

The admin-view can be either random or not, it depends on your
preference. The one thing I would point out is that the non-random page
mixins (PageObjectMixin and PageModuleMixin) provide a nicer page
lifecycle that gives you more control over session management. That can
be very useful for data editing as it provides obvious hooks (page_enter
and page_leave) for when to create and destroy session data.

      * http://object-craft.com.au/projects/albatross/albatross/mixin-page-module.html


> The system should meet the following requirements:
> 
> There must be a simple but extendable authentication framework. 

You might consider putting the authentication checks in your application
class rather than in the page modules to avoid code duplication. The
Albatross application classes and mixins will probably have a convenient
method you can override to add the authentication hooks.

Some time ago now, Sheila King posted some example code which included
authentication. I'm not sure how it was implemented but that might help
you if the code is still available. You'll have to search through the
mailing list archive for more on that.


> The system will use a simple tree-based approach to organize content. The tree
> determines the navigation at the same time.

As Tim Churches mentioned, the <al-tree> tag will help if you need to
render trees structures.

      * http://object-craft.com.au/projects/albatross/albatross/tag-tree.html

> The tree approach enables some neat tricks to be done with relative ease. A
> document can serve as a parent for images shown in the document. An image
> gallery can serve as a parent for images shown in the gallery, etc.

Sounds like you could have a different template for each type of
"object" that is being displayed - one for a document, one for an image
gallery, one for a full-size image etc.

What about the case when two documents both include a single image?
Might the concept of an image library be better? That probably depends
on how far you want to take the application.


> There should also be a master-template showing the navigation and other global
> stuff. An area of the master template is reserved for the actual content to be
> displayed. The master teplate should therefore be able to switch the view in the
> content area based upon context.

Sounds like a job for the (horribly named) macros mechanism. Your
document template file (for example) could be something like:

<al-expand name="master">
  <al-setarg name="title">... document title ...</al-setarg>
  ... document content ...
</al-expand>

where all the navigation, layout etc is contained in a the "master"
macro.

      * http://object-craft.com.au/projects/albatross/albatross/tug-content2.html

I have no idea why I hate the term macro but I do, so there ;-).

> 
> The following features are planned:
>   Documents, consisting of XHTML-data

You should have no problem here. The Albatross templating system does
very little messing around with your HTML content. The provided HTML
custom tags have a philosophy of passing any unrecognised attributes
through to the HTML code unchanged.


>   Files and Images
>   Weblog
>   Image gallery

I can't think of why any of these would be difficult for Albatross

As as aside, I have considered writing a gallery application myself ...
just so that I can remove all remnants of PHP from my computer ;-). The
other application I really want is a combined weblog/wiki, something
like SnipSnap but in Python rather than Java so not *all* the RAM is
used up ;-).

Here are some pointers to other tools that might be useful:

      * Python Imaging Library, http://www.pythonware.com/products/pil
      * Some form of structured text processor, i.e.
              * docutils, http://docutils.sourceforge.net
              * PyTextile, http://diveintomark.org/projects/pytextile
              * etc


> My current homepage is at http://max.nma.fi/ Feel free to take a look at what
> I'm trying to replace.

I'm not sure how effective Albatross would be as a streaming media
server for your MP3s. ;-)


> I realize this description is vague, and that the approach I've envisioned may
> not suit the Albatross environment. I therefore hope that the members of the
> list can help us in finding a sensible approach, while still maintaining our goals.

I think Albatross can handle this type of application relatively easily,
it's quite flexible and very easy to use (at least, I think so). Of
course, just writing it in Python provides a number of benefits.

I would not recommend trying to implement a full CMS in Albatross, or
anything else for that matter, when something like Zope
(http:///www.zope.org) is available. Although, Albatross is more fun and
**considerably** more light weight.


> Now then... bring on the hailstorm of bashing please.

Oh right, why didn't you say so earlier! What a ridiculous idea for an
application this is! You come in here asking for guidance, even daring
to use the letters P, H & P together and you expect us to jump in and
help. Ahem ... will that do? :)


Hope this helps. As you can probably tell, Albatross has ways of doing
most things quite nicely but it's really not difficult to use. Please
ask if there is anything you are unsure of.

Cheers, Matt

-- 
Matt Goodall, Pollenation Internet Ltd
w: http://www.pollenation.net
e: matt at pollenation.net
t: +44 (0)113 2252500