#pyramid

and would be great to start on that branch

would save me 2 whole steps explaining and reorganizing things to get them to new-scafoold state

but it really have one view

I do have more interesting scaffold to reason about

(not finished yet)

I added a 404 view to the scaffold already

fwiw

+1

would argue that exception view also makes sense

wanted to add a forbidden too but it didn't really fit into the scaffold that has no permissions

mcdonc: functional scaffold would be really cool, I think.

at the very least to get a newcomer more acclimated.

Ugh, so much whitespace creeps into templates with Mako.

if you could finish it by the weekend too, that'd be great

chameleon ftw Aankhen``

s/templates/documents/

Method__: I used Mako because it seemed like it had the least friction with Pyramid out-of-the-box. Converting at this point would be a major undertaking, heh.

I mean, doesnt pyramid use chameleon out of the box?

Iunno, the examples I saw initially used Mako.

I suppose it doesnt use /anything/ out of the box

At this point I’d say that actually speaking there’s almost no difference between the two in terms of ease of integration.

it's truly amazing how difficult it is to explain to people that pyramid has no default rendering engine and jinja2/mako/chameleon are all officially supported

Yeah, exactly.

I just got the impression initially that Mako was The Default.

no idea where to put it in the docs... as it's already in there..

raydeo: I thought the scaffolds use chameleon

so?

thats what i mean by "out of the box"

maybe the scaffolds need a big huge disclaimer

mcdonc: raydeo http://wklej.to/kgM3N

or to make a decision and disclaim that it can be changed easily?

thats how I like to structure my applications

Ergo: I wish my project was structured anywhere near that

the scaffold templates are polyglot templates.. they work as either mako or chameleon ;)

a quine?

Ergo: yeah i'm not a fan of that layout type

the mako template renders a chameleon template

mcdonc: that makes as even then :P

well it kind matters in this case

kinda

what would be really cool in the docs is provide examples for various template languages. like a tabbed view

because if we refactor the scaffolds, people are way too lazy to think to reorganize

and i'd hope to convince you that the by-type layout is not as useful as the by-feature

the scaffolds are currently by-type

there's no reason to change them if we just sorta pile on to that

mcdonc: for the 150-200k LOC project i worked at where tons and tons of things were shared, I would probably have to slit my wrists if it would be by-feature

in Ergo's example I would've made them all separate projects

Ergo: yeah thats a bit ad-hominem ;)

so I would argue it depends a bit on what are you working on, for CMS-type applications it probably works great

ultimately everything is a cms

why would you have been unhappy with by-feature

the sooner you accept this the sooner you will be at peace

i mean, how are you confident that you would have been

I would say that for scaffold - there is actually too little code to actually "organize" things

yep

but we could add more of course

I need to do some refactoring but, this is the structure for pcblueprint.com http://imgur.com/Tzuv3vC sort of by type. a lot of cms-style things.

i know that "by-feature" approach is often advocated by JS frameworks like angular etc.

but then again - those things are strongly component based

by "some" I of course mean a shitton.

i'm ignorant of that, tbh

mcdonc: lucky you

the "best thing" changes every month

i base my preference for by-feaure on https://github.com/Pylons/substanced/tree/maste...

it's hard to tell if people mean it's a bad idea from experience or it's a bad idea because they fail to comprehend it or it's a bad idea because they did a bad job when they tried it ;-)

(as people are probably sick of me linking to ;)) )

i like that layout because when a new feature gets added, it's obvious where it should go

what when its not obvious at all?

and all of the templates/tests/views/models can be bound up into a logical unit

for that feature

is there a pyramid best-practices doc somewhere? maybe that would solve some of this

I'm not sure it's so obvious mcdonc ;-)

lol

well it's obvious when you know the problem domain anyway i think

its not when you dont, i think

(really unobvious lots of times yeah))

it's fairly difficult to navigate if you don't know what you're looking for

i think you could argue that by-type has that problem too though right

and most people just grep anyway

less-so... at least you know if you want a view or a template or what to start

I guess I'm not most people

grep is a last resort

I mean - that application works great when you build an "application" - when you build a "portal" of hundred custom pages - things become blurred, but then again it is a fairly specific business case

But it might be jsut me being used to specific way of doing things

yeah I agree that by-feature works much better in a framework than an application

i guess i'd ask you now that you've done it "by-type" once, do you know enough about the problem domain to do it "by-feature" now?

mcdonc: I'd wish...

i'd guess the answer would be yes, because you figured out what the components are at this point

even in an app there are feature boundaries though right

features in an app are very blurry

certainly they cross component-boundaries of the app many times

yeah

assuming a flat namespace of features has never been my experience :(

components? maybe

well, maybe i'd argue that once you really understand the problem, a by-feature layout (flat or nested, depending on complexity) lays within the bounds of human perception

but you're right, when you're just starting a project, it's not obvious at all

what I really love about Pyramid is the fact that it’s simple to refactor to/from a feature-based folder tree layout

config.scan() rocks

along with named routes

^^

oh you want to move your route somewhere totally different? k.

for both back and front I prefer the by-feature or «domain» appeoach

i wonder how we can impart that realization to other people kamalgill ;))

heh, yeah

its really hard

mcdonc: an example: here you have a normal langing page https://www.points2shop.com/ - this shares lets say 60% of the code https://www.surveyrewardz.com/ - but based on domain name the remaining 40% can differ per domain (and that part can be shared with multiple different features) , when you have to put up with that kind of business needs - per-feature doesn't work well

but as I said - its very special case - because of various business needs

its not a very special case actually

we did that kind of thing all the time

that app's user model is 1mb size probably now :P

(but we used a tree, so it was a bit easier)

anyways - I think it's a matter of preference to some degree

yep

I had two projects at work that shared a ton of the same code

</agitation>

;)

If i could rewrite things, now that I know what was needed, I could probably by-feature and it would work fine

make maintaining your schema across projects super easy

by feature is easier to share imho, if well done

the actual process is dumping shit into "utils.py" and then as you discover features move it out ;)

I once got a request to make another application that reuses 80% of the code of first one - namely pylons controllers code, with decorators that prevent the code to get shared

but that's a bitter pill to swallow for new devs ;))

by-feature is a good place to start

each feature tends to look like (models, views, templates) though

yep

so the scaffold starts by-feature with only one feature :p

lol thats about right

raydeo: aren't you supposed to be electioneering? Or have I got the wrong state?

haha

hehe... one app per feature... microservices :P

making pyramid great again?

more like pain in the ass :P

Method__: code should never be shared across projects. If you find you're doing it, write a library.

i'm fine with that analysis and doing per-type scaffolding... my only beef is walking up to some monstrous project two years in that has 400 templates in templates/ ;)

mcdonc loves django style pluggable apps with separate models, views templates ;-)

also: unicorns

lol if i love them it's not because i've seen them ;)

Charlie_X: meh.

all registered as services?

by-feature can mean less name contention