fragments deprecated?

[Martin J. Laubach]

  I just stumbled over the (now non existant) description of the fragment mechanism. As far as I can tell, the use of fragments is now totally deprecated (at least there is no documentation any more; the deprecation timeline does not mention it though) and instead a dance with overriding page base templates should be done.

  I'm not sure I like that, for the following reasons:

1. The Application Content should not need to know about the page base template. It is a basic proposition that integrating 3rd party components should not need major rework of the application. (Though the need for using app_reverse works against that proposition already, I wish we could find a better solution than app_reverse!). This new method now tightly couples the implementation of the app and the structure of the base page template making it impossible to re-use them verbatim in some other site!
   
2. Inheriting from the base template actually does something totally different than just setting a fragment for overriding eg. the page title. You cannot have other content types on the same page as the app content now will totally override the base page. The content of the region with the app content is lost, it is no longer possible to put eg. a RichText before an app content. We use that all the time.
   
3. What this new method of returning a tuple from the app does is basically just the same as the @standalone decorator already did, so why have yet another implementation?

  In summary, it looks as if there are aspects that were overlooked when declaring this the new way to go. I agree that fragments are not pretty, but this is a serious regression.

  Cheers,

    mjl

[Marc Egli]

We use fragments a lot in content types to push some javascript to the bottom of a page. Is there another way to achieve this without fragments?

[Matthias Kestenholz]

On Wed, Mar 27, 2013 at 4:42 PM, Martin J. Laubach <goo...@emsi.priv.at> wrote:

  I just stumbled over the (now non existant) description of the fragment mechanism. As far as I can tell, the use of fragments is now totally deprecated (at least there is no documentation any more; the deprecation timeline does not mention it though) and instead a dance with overriding page base templates should be done.

I don't think we ever had documentation. True, I'm not using fragments too much anymore but they cannot be replaced easily and are not deprecated.

 

  I'm not sure I like that, for the following reasons:

1. The Application Content should not need to know about the page base template. It is a basic proposition that integrating 3rd party components should not need major rework of the application. (Though the need for using app_reverse works against that proposition already, I wish we could find a better solution than app_reverse!). This new method now tightly couples the implementation of the app and the structure of the base page template making it impossible to re-use them verbatim in some other site!
   
2. Inheriting from the base template actually does something totally different than just setting a fragment for overriding eg. the page title. You cannot have other content types on the same page as the app content now will totally override the base page. The content of the region with the app content is lost, it is no longer possible to put eg. a RichText before an app content. We use that all the time.
   
3. What this new method of returning a tuple from the app does is basically just the same as the @standalone decorator already did, so why have yet another implementation?

  In summary, it looks as if there are aspects that were overlooked when declaring this the new way to go. I agree that fragments are not pretty, but this is a serious regression.

These are all good points. You are not forced to use the new way, though, and I do not plan to remove the support to use ApplicationContent as at the beginning.

Yes, the removal of the reverse() monkey patch and the introduction of app_reverse() make integration of unmodified apps harder. I think it's worth it though -- no more fighting with the imports until it does not break anymore.

So maybe the way forward would be to add some real documentation for the fragment mechanism?


Thanks,
Matthias

[Martin J. Laubach]

  Oh, I assumed there was some docs because I tried to look up the reference for answering a post here; but if there never were any then things are not as gloomy as I had the impression they were. I thought I had missed a crucial change in AppContent direction.

  So basically the way forward here would be to add some docs to the fragment part (and perhaps tone down the "this is the new way" paragraph a bit). I can do that, no worries.

[Martin J. Laubach]

Yes, the removal of the reverse() monkey patch and the introduction of app_reverse() make integration of unmodified apps harder. I think it's worth it though -- no more fighting with the imports until it does not break anymore.

  Yes, agreed, things work much better now.

  I still would like to find a way to drop an unmodified django app and have it "just work", that's on my wish list for this year :-)
 

[Simon Schmid | FEINHEIT]

@Marc:

I usually use the "Extra media for content types" mechanism described here: http://feincms-django-cms.readthedocs.org/en/latest/contenttypes.html#extra-media-for-content-types for extra javascript specific for one content type. 

2013/3/28 Marc Egli <eg...@allink.ch>

We use fragments a lot in content types to push some javascript to the bottom of a page. Is there another way to achieve this without fragments?

--
You received this message because you are subscribed to the Google Groups "Django FeinCMS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-feincm...@googlegroups.com.
To post to this group, send an email to django-...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.