Steve, the way I had this working, you could share things with a natural order (blog posts, a custom even model I had made) between sites but not pages, due to the ordering complexities you mentioned. There was not performance difference between using a FK and a m2m for the site[s] field. I think we could incorporate this to allow sharing Displayable/SiteRelated models with a natural order and just not support sharing pages. If someone was really keen on sharing pages they could easily create their own models/admin to do that in a separate app without having to worry about using a custom/patched version of Mezzanine. For reference for anyone following along, here were my changes, https://bitbucket.org/joshcartme/mezzanine/compare/sites_m2m..stephenmcd/mezzanine:default#diff
Basically I think it will add some more flexibility to Mezzanine without any drawbacks and we can continue to not support sharing pages between sites to avoid the complexity of that. Alexander, I haven't done anything else towards this besides what is discussed above. If you do work on this please let me know any drawbacks you come across. On Sun, Feb 15, 2015 at 9:05 PM, Stephen McDonald <st...@jupo.org> wrote: > This probably doesn't have much chance of being included - it will most > likely introduce an unwarranted increase in the complexity of how the page > tree works. For example, all of a sudden you need to deal with the ordering > of shared pages in the context of each site. Certainly not unsolvable, but > probably not in a clean and simple way. > > Just some food for thought before embarking on anything. :-) > > On Mon, Feb 16, 2015 at 12:55 PM, Alexander Kominek < > alexander.komi...@gmail.com> wrote: > >> Hey Josh, >> >> I'm trying to set up M2M for sites on one of my current sites and I >> stumbled across this thread. Has any more work been completed on this in >> the last year to bring it up to date with the latest version of Mezzanine? >> If not, I'll probably end up updating it, but I just wanted to make sure >> I'm not duplicating any work. >> >> Thanks! >> >> >> >> On Monday, January 7, 2013 at 3:28:15 PM UTC-7, Josh Cartmell wrote: >>> >>> Thanks again Steve, that blog post and your pointers helped me figure >>> out a good direction to take. For anyone else tracking along I moved the >>> migrations into a separate app which is here: >>> https://bitbucket.org/joshcartme/mezz_sites_m2m >>> >>> One thing to note is that I had to change the calls to the orm since the >>> migrations no longer reside in the app they modify. If this ever makes it >>> into Mezzanine core we would probably want to change the orm calls back to >>> the way they were. >>> >>> On Mon, Jan 7, 2013 at 8:56 AM, Josh Cartmell <joshc...@gmail.com> >>> wrote: >>> >>>> Thanks Steve, that post is pretty useful. I'll give it a go. >>>> >>>> >>>> On Sun, Jan 6, 2013 at 12:06 PM, Stephen McDonald <st...@jupo.org> >>>> wrote: >>>> >>>>> Luke Miller (ex-colleague of mine) wrote a good post on how he does it: >>>>> >>>>> http://dodgyville.tumblr.com/post/23028930440/new-fields- >>>>> in-mezzanine-without-editing-or-creating-a >>>>> >>>>> >>>>> On Mon, Jan 7, 2013 at 7:05 AM, Josh Cartmell <joshc...@gmail.com> >>>>> wrote: >>>>> >>>>>> Thanks Steve, I didn't realize I could put migrations in a different >>>>>> app so that's very helpful! >>>>>> >>>>>> >>>>>> On Sat, Jan 5, 2013 at 3:01 PM, Stephen McDonald <st...@jupo.org> >>>>>> wrote: >>>>>> >>>>>>> I haven't had a chance to look at this yet myself. As for the >>>>>>> migrations, you could probably put your one into a separate app, and >>>>>>> if/when your changes get merged into the main project, just fake the >>>>>>> (redundant) migration for it. >>>>>>> >>>>>>> >>>>>>> On Sat, Jan 5, 2013 at 12:00 PM, Josh Cartmell <joshc...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hey everyone, I just wanted to check in and see if this is still on >>>>>>>> the radar at all? >>>>>>>> >>>>>>>> I'm about to use this in a project so if it's not does anyone have >>>>>>>> any >>>>>>>> suggestions for how I should manage migrations? Would I just need >>>>>>>> to >>>>>>>> always edit every future migration to reflect the divergent db >>>>>>>> schemas? >>>>>>>> >>>>>>>> Thanks for all the feedback thus far. >>>>>>>> >>>>>>>> On Nov 19 2012, 12:42 pm, Josh Cartmell <joshcar...@gmail.com> >>>>>>>> wrote: >>>>>>>> > Sounds good, thanks Steve! >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > On Mon, Nov 19, 2012 at 11:54 AM, Stephen McDonald < >>>>>>>> st...@jupo.org> wrote: >>>>>>>> > > I haven't gone over the code in detail yet, just waiting for >>>>>>>> some space to >>>>>>>> > > be able to do that. But as far as what we've discussed so far >>>>>>>> I'm all in >>>>>>>> > > favour of the feature and approach. >>>>>>>> > >>>>>>>> > > On Tue, Nov 20, 2012 at 6:51 AM, Josh Cartmell < >>>>>>>> joshcar...@gmail.com>wrote: >>>>>>>> > >>>>>>>> > >> In regards to the changes I have made I just did a little >>>>>>>> performance >>>>>>>> > >> profiling (using Django debug toolbar) and surprisingly the >>>>>>>> same number of >>>>>>>> > >> queries are executed to render the About page of a vanilla >>>>>>>> Mezzanine >>>>>>>> > >> project regardless of whether you are using a foreign key or >>>>>>>> the m2m >>>>>>>> > >> versions of sites that I implemented. I'm wondering if >>>>>>>> Django's current >>>>>>>> > >> site manager does some sort of performance tweaking since it is >>>>>>>> > >> specifically built to handle m2m's or foreignkeys. I haven't >>>>>>>> made any >>>>>>>> > >> improvements in regards to performance. >>>>>>>> > >>>>>>>> > >> With that in mind the changes I have made so far may be >>>>>>>> basically ready >>>>>>>> > >> to be pulled. What do you think Steve et al? >>>>>>>> > >>>>>>>> > >> On Fri, Nov 16, 2012 at 4:06 PM, Stephen McDonald < >>>>>>>> st...@jupo.org> wrote: >>>>>>>> > >>>>>>>> > >>> Previously discussed here just for reference: >>>>>>>> > >>>>>>>> > >>>https://groups.google.com/group/mezzanine-users/browse_ >>>>>>>> thread/thread/... >>>>>>>> > >>>>>>>> > >>> On Sat, Nov 17, 2012 at 8:07 AM, Robert Moggach < >>>>>>>> r...@dashing.tv> wrote: >>>>>>>> > >>>>>>>> > >>>> It doesn't instinctively make sense if you only have 3 or 4 >>>>>>>> one off >>>>>>>> > >>>> pages that are 1 or 2 deep but if you're dealing with big >>>>>>>> datasets and >>>>>>>> > >>>> multiple sites it starts to make alot of sense. It wouldn't >>>>>>>> affect small >>>>>>>> > >>>> sites adversely to implement, only add flexibility. If you >>>>>>>> start to have >>>>>>>> > >>>> page structures that are 5 or 6 deep with many siblings at >>>>>>>> each level, it's >>>>>>>> > >>>> a clear winner to use modified preorder tree traversal. >>>>>>>> > >>>>>>>> > >>>>http://en.wikipedia.org/wiki/Tree_traversal >>>>>>>> > >>>>>>>> > >>>> Take a look at how feinCMS implements their menu structure >>>>>>>> using >>>>>>>> > >>>> MPTT... >>>>>>>> > >>>>>>>> > >>>> Abstracting the presentation logic from the content logic is >>>>>>>> a good >>>>>>>> > >>>> thing. >>>>>>>> > >>>>>>>> > >>>> On Fri, Nov 16, 2012 at 10:32 AM, Robert Moggach < >>>>>>>> r...@dashing.tv>wrote: >>>>>>>> > >>>>>>>> > >>>>> performance and flexibility >>>>>>>> > >>>>>>>> > >>>>> Sent from my iPhone. >>>>>>>> > >>>>>>>> > >>>>> On Nov 16, 2012, at 12:25 AM, Ahmad Khayyat < >>>>>>>> akhay...@gmail.com> >>>>>>>> > >>>>> wrote: >>>>>>>> > >>>>>>>> > >>>>> On Friday, November 9, 2012 1:11:42 AM UTC-5, Robert >>>>>>>> Moggach wrote: >>>>>>>> > >>>>>>>> > >>>>>> New to this so excuse me if I'm missing something, >>>>>>>> ultimately >>>>>>>> > >>>>>> shouldn't it be something that allows for the following >>>>>>>> > >>>>>> flexibility/assumptions? >>>>>>>> > >>>>>>>> > >>>>>> 1) a page can be a member of multiple sites >>>>>>>> > >>>>>> 2) a page instance can have multiple parent pages per site >>>>>>>> > >>>>>> 3) a page has a notion of order with respect to it's >>>>>>>> siblings >>>>>>>> > >>>>>>>> > >>>>>> Seems like the inherent tree structure logic should be >>>>>>>> abstracted >>>>>>>> > >>>>>> from the content to allow for better performance, >>>>>>>> flexibility of position >>>>>>>> > >>>>>> and multiple instances of a single content object within a >>>>>>>> given site. >>>>>>>> > >>>>>>>> > >>>>>> I've used django-mptt and been happy with it's performance. >>>>>>>> > >>>>>> django-treebeard might be well suited to this as well. >>>>>>>> > >>>>>>http://www.djangopackages.com/grids/g/trees-and-graphs/ >>>>>>>> > >>>>>>>> > >>>>>> This will keep the essential logic of an object's >>>>>>>> > >>>>>> content/status/metadata separate from it's more arbitrary >>>>>>>> and site-specific >>>>>>>> > >>>>>> position logic. >>>>>>>> > >>>>>>>> > >>>>> I've been thinking about this for a bit, specifically: what >>>>>>>> does a >>>>>>>> > >>>>> flexible tree such as that provided by treebeard or mptt >>>>>>>> add, that is >>>>>>>> > >>>>> needed and not available using a simple parent-reference >>>>>>>> (page has >>>>>>>> > >>>>> foreign-key to page) tree? >>>>>>>> > >>>>>>>> > >>>>> 1) wouldn't a menu per site solve this? >>>>>>>> > >>>>> 2) Is this really needed? Do you list one page multiple >>>>>>>> times in the >>>>>>>> > >>>>> same menu? I guess I need an example to appreciate the need >>>>>>>> for this. >>>>>>>> > >>>>> More importantly, how do you handle the URL? >>>>>>>> > >>>>> A) does the URL change with the parent (multiple URLs, >>>>>>>> same page? >>>>>>>> > >>>>> bad for SEO?); or >>>>>>>> > >>>>> B) do you use one URL for all instances >>>>>>>> (structure-independent >>>>>>>> > >>>>> URL?) >>>>>>>> > >>>>> 3) This can still be done using a simple foreign-key based >>>>>>>> tree, maybe >>>>>>>> > >>>>> with an extra field. >>>>>>>> > >>>>>>>> > >>>>> If I'm starting from scratch, why would I want to use mptt >>>>>>>> or >>>>>>>> > >>>>> treebeard instead of the simple foreign-key approach? >>>>>>>> > >>>>>>>> > >>> -- >>>>>>>> > >>> Stephen McDonald >>>>>>>> > >>>http://jupo.org >>>>>>>> > >>>>>>>> > > -- >>>>>>>> > > Stephen McDonald >>>>>>>> > >http://jupo.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Stephen McDonald >>>>>>> http://jupo.org >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Stephen McDonald >>>>> http://jupo.org >>>>> >>>> >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Mezzanine Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mezzanine-users+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Stephen McDonald > http://jupo.org > > -- > You received this message because you are subscribed to the Google Groups > "Mezzanine Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mezzanine-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Mezzanine Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
