#django

Hi, using CreateView, how to get all arguments from urlconf?

self.kwargs

not working, https://dpaste.de/F7Zw3/

Sewar: I believe that you wont have kwargs in __init__

try using an action funciton like: def get(self, request, *args, **kwargs) or def post

s/funciton/function

Sewar: It's pretty uncommon that you'll have a reason to override a view class's constructor. And request-time arguments aren't yet initialized at that point.

Right, try using def get_initial(self):

Or better yet, tell us what your actual question is.

haha, touche

I'm have a pk in url, the new object should be related to that when created

s/I'm/I

it

it's different model than the one being created/updated

So form_valid is probably a good place to do that.

I need that before form_valid, some stuff in the form page depend on the parent model data

sounds to me like using a CBGV is only making your life hard

What sort of stuff?

form validation

FunkyBob: And whose life is not made hard by CBGV? ;)

So you'll want to pass the object into the form, get_form_kwargs (and write your form constructor to accept the extra argument)

just kidding ... I know there are valid use cases

powellc: sure, just nowhere near as many as cases they are used :P

hehe, +1

mattmcc: that sounds like the perfect solution, thanks

thanks guys

I'm actually staring at some code of mine where I overrode the dispatch method on a CreateView ... at that point you might as well use functions :)

Eh, it depends.

There is definitely merit in being able to inherit other views and build up some complex use cases, I've enjoyed that benefit quite a bit

my last feature branch removed yet another CBV use

and, as usual, the code became simpler, clearer, and _shorter_

So just curious, has anyone brought a 1.4 or older project up to 1.5?

powellc I have not, but I'd be interested in the answer. Stuck on 1.3 still because of budget concerns.

powellc: I have

powellc: Just read through all the changes noted in the release notes.

haha, yeah, it's the template tags that are the doozy for us

most of the work was adjusting {% url %} tags, url imports.... not much else

Our problem is that we're an agency with a number of fairly subtantial codebases, and, like skeet70, a lack of budget

powellc: how so?

oh, and my code derived from InheritanceManager had to change

powellc: Well, take advantage of 'load url from future' first, so that you don't have to do a version upgrade.

yeah, don't have the benefit on the older codebases (1.3 and older) but with newer projects that certainly helps

Of course, part of that pain is not managing client expectations for how long their sites should go without a refactoring ... still supporting one client on 1.1

*sigh*

sigh indeed

I'm about to run up another VM... and _really_ want to migrate all my existing clients onto it from my other 2

and update/refresh them all in the process

Yeah, with our newer clients too, tox plus test coverage makes the switch much easier too ... just toss 1.5 in as another piece to test and fix until it passes

yeah

all of mine were cheapo sites...

if only ... :)

generally running on my own CMS app {gnocchi-cms}

delicious

so there's really no money in it for me to do work on them

right

but consolidating versions, and migrating everything to BCP... that's worth it

really really must find time to get to work on salsa, my next gen cms

am ver tempted to make it use django-cte-trees

neat, wasn't aware of cte-trees, that's slick

aye

I've grown disillusioned with CMS apps as of late ... but its so hard to convince a client to structure their site around data instead of pages (and sometimes that's just not possible)

Doesn't help that we've been using django-cms heavily ... great piece of OSS work, but man, don't you dare try to get your page data out of that database :)

eh?

basically, I was trying to abstract gnocchi-cms one step further..

django-cms just really fragments the page data, so the titles are in their own table, related to the page an then everything on the page is a plugin, so there are separate tables for each plugin type and so on

gnocchi seems pretty simply laid out though ... and I like the templates in the DB idea

sounds a little like where I was heading

yeah... gnocchi had some very specific goals-- one of which is "work within admin"

hehe, sorry

well, the Fragments on Pages were nice, but I wanted to go one step further

and let you share arbitrary content things across pages...

so I was going to turn Fragments into a tab/slot idea

as well as mark up templates with {% slot %} tags...

Yeah, and that's neat ... django-cms doesn't let you share plugins across pages

so you have fragmentation for fragmentations-sake, it seems

however, this is all for salsa.... and salsa would most certainly NOT use Admin

well, not really, there are use cases for plugins on pages, but it does make a mess of the DB

I actually like the idea of reusable slots

so when editing a Page, you select its Template, and then the console can scan that template and find what {% slot %}s are defined on it

then it can hint at what named fragment slots you should fill in

alo, gnocchi pages have no way to deal with posts...

but I figured a nice clean way to fix that for salsa

however... I've not had experience with other CMSs .. much.... and don't know how people really interact with them...

and every time I find someone who's willing to contribute their experience... they vanish :/

yeah, that's too bad

but I think I'm going to resurrect salsa... and go with my simple, direct idea

tricky part, now, will be building the UI :P

yah, good luck not using admin :)

well, I've been looking for a project to try out w2ui on

yeah, that's pretty slick