Re: Mantissa Wiki Tutorial

On 01:31 pm, [email protected] wrote:
>I've taking a running leap at Mantissa a couple of times, but have not
>yet managed to clear the rubble-strewn learning curve (mind the
>falling rocks) to reach any kind of fluency.

I'm sorry for that curve, but when you need to throw together a mountain 
quickly, sometimes the result is kind of rocky :).
>I can identify the
>components I want to bolt together, but it seems to take a lot more
>pain than I anticipate to actually do it.  It has been more than a
>year since my last attempt, but at the time I found it a slippery,
>moving target.  For most web utilities I seem to need to throw
>together (very little per-user data, if user accounts exist at all)
>Nevow is just too much fun *not* to use, and Mantissa was still pretty
>painful.

This use-case (throwing together an app with a simple "front page" and 
without much in the way of /private et. al. is something we will be 
specifically addressing.  Even though our apps are geared towards 
Mantissa (lots of per-user data, multiple communicating optional 
components), the inability to quickly throw together prototypes using a 
few lines of code in Mantissa is a serious problem; one that is 
affecting us internally quite often.  However, the underlying model of 
mapping model objects (in multiple databases) to view objects via access 
control will be much the same.  There will still be a few interfaces, 
adapters, and a plugin required to do anything with Mantissa.

In other words, much of the incidental complexity, which I would guess 
is causing the lion's share of your pain here, will be removed, but the 
inherent complexity of doing what Mantissa does will remain.   I don't 
know enough about your experiences to say which one is really the larger 
factor though.
>The Mantissa project boilerplate generator (which was pretty new the
>last time I looked) kind of illustrates what has kept me away.  With
>Nevow and a 30 line .tac file that can be comprehended at a glance,
>one can move mountains.  Mantissa wants to generate a tree of plugin
>files, templates, python, JS, and a database of databases to do
>exactly nothing.  You might be able to move the same mountain by
>mixing in 30 more lines, but it isn't easy, and it isn't really fun.

We might still have a boilerplate generation tool at the end of this 
phase, but the current one was really a misguided attempt to learn 
something from Rails.  The lesson from Rails is really: have less 
boilerplate so you don't need a pile of tools to generate all the 
boilerplate for you ;).
>On the other hand, as the number of isolated utilities I deal with
>grows, they become difficult to manage without some kind of organizing
>structure beyond my present static page of links, but I think my mini
>apps are individually not the sort of thing that Mantissa was designed
>to manage.

Quite possibly.  It sounds like you are in a grey area, where you may or 
may not find Mantissa useful once we've documented it and cleaned it up. 
It might be worth dealing with a slight impedance mismatch to get all 
the features that Mantissa offers (navigation, access control, a 
deployment environment where you can launch multiple applications 
simultaneously, etc) but it might still just be more hassle than it's 
worth.
>Is that changing?  Is "make as fun as vanilla Nevow" a development
>goal for Mantissa?  How should a developer decide which to target for
>a new application?

Making it fun is definitely a goal.  Perhaps *the* goal :).

Developers will still have to decide for themselves, but my hope is that 
Mantissa will soon provide a pleasant enough experience that it will be 
the default choice, unless your application is somewhat specialized (no 
database, need to integrate with an existing database, no user accounts 
at all, an incompatible model of access control, URL compatibility with 
an existing site that has incompatible "controller" semantics, etc).