launchpad-dev team mailing list archive

[Guilherme Salgado <salgado@xxxxxxxxxxxxx>]

On Sun, 2010-12-12 at 20:28 +0100, Jelmer Vernooij wrote:
> On Mon, 2010-12-13 at 08:17 +1300, Robert Collins wrote:
> > I've looked on the dev wiki, but found no useful pages in a full text
> > search for 'model browser' :)
> > 
> > The reason I ask, is that it might make things a little simpler for
> > reviewers and developers if there were some generally expected
> > guidelines.
> > 
> > Not that the guidelines are large: the core of it is 'rendering and
> > marshalling code should be in browser/, querying and mutating code
> > should be in model/'.
> 
> > The reasons for suggesting that as the guideline:
> >  - code in the model can be exposed on the API
> >  - code in the model can be declaritively secured
> >  - we don't need to do html rendering and other browser-connection
> > logic in the API
> > 
> > so separating out 'could be used in the API' into model/ nicely
> > decouples the two - and allows testing the core functionality without
> > html parsing etc.
> > 
> > However, perhaps I'm fundamentally confused here and we already have
> > strong guidelines - perhaps ones that disagree with this proposal -
> > that I overlooked? In which case, point me at em!
> As far as I know those are the guidelines we already have, at least
> that's how it was explained to me when I first started hacking on

Indeed.

> browser code. IIRC the import fascist also used to complain about
> importing from database modules directly into browser code.
> 

The reason the fascist does that is because browser code must use only
the secured utilities to get access to model code.  That's to ensure
browser code can't get access to non-security-proxied model code.

This should certainly be documented, but I don't think it's directly
related to what Robert is proposing?

-- 
Guilherme Salgado <https://launchpad.net/~salgado>

Attachment: signature.asc
Description: This is a digitally signed message part