[albatross-users] Request for pre-specification enlightenment

Max Romantschuk max at provico.fi
Fri Aug 8 15:34:25 EST 2003


Please note: No time to proofread, should be working...


OK... I think Matt just saved me a huge bulk of research work, Thanks!

Here's the short version: I'm pretty much convinced the information supplied
will get me started quite easily. I'll return with specific questions when I get
that far.


As for the comparison of Albatross and ColdFusion... I haven't yet really used
Albatross so I don't really think I can pass proper judgement. I can tell you
that ColdFusion is a bit like Perl, great for rapid development but really
non-maintainable in the long run. From a linguistic perspective ColdFusion is
really ugly.

ColdFusion has some good things though, mostly excellent (read unified and easy
to use) database integration and bundled indexing and search capabilities.

In any case I wouln't recommend ColdFusion over PHP, Perl, Python or Java in a
larger application. For small applications most languages keep things bearable
if you know your stuff, so ColdFusion is OK for that.

The thing is I really use ColdFusion only because my boss makes me ;)


Quoting Matt Goodall <matt at pollenation.net>:
> 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 ...

I probably will do just that. An interface oprimized for editing usually looks
ugly, and vice versa.

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

Sounds very sensible.

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

I won't consider it, I will make sure to do so.


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

I will, as I want a unified structure. Also this lets me store multiple files of
the same name on the server (storing by an indexed name or in a database, then
serving separately), while avoiding overwrite / nameclash issues. 


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

This is still very open. I'm researching if I could hook into method calls on
the underlying logic level and make the authentication granular without huge
extra effort and/or overhead. In any case I don't know enough about the inner
workings of Albatross to approach this just yet...

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

Thanks, I'll have a look.


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

I prefer to have 2 images which happen to look the same. I've been on projects
where data was shared in multiple places for a bunch of reasons, and this may
force you into one of three situations:

1. Don't edit stuff in fear of messing up some other data hidden in place X.
2. Lock down data which is shared and/or build huge amounts of logic to check
all over the place.
3. Build a versioning system.

In any case, I'd rather have some duplication and keep things simple :)


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

That sounds like a good idea. I'll have to learn all about macros then. They
were those things in Excel, right? ;)


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

OK... for now I'll think we'll keep this between me and Fabian, but I promise to
make the code available, when it's ready.
 

> > 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 think I'll let mp3.com serve that for now... we'll see about version 2 ;)

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

Yes. I tried Zope, but found that it was just too huge and not quite as stable
as I wished for. I guess there are just too many moving parts to get your head
around with only so much free time to spare.

 
> > 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? :)

I laugh at your puny attempts to ridicule me. Hah!

(todo: insert joke about herring slapping)


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

I'll be sure to start crying once I get stuck first.


Thanks Matt!


.: Max Romantschuk
.: http://max.nma.fi/
.: http://www.mp3.com/romax/



More information about the Albatross-users mailing list