search

uottawa-wcms / content_snippets

GNU General Public License v2.0
0 stars 0 forks source link

Difference between Content Snippets and FPP #2

Open sylus opened 11 years ago

sylus commented 11 years ago

Hey @uottawa-wcms,

Now that FPP has full translation support can you highlight the differences between this module and FPP. Was it not possible to extend FPP to fulfill requirements?

Just hoping to have an issue to refer people to should questions arise :)

uottawa-wcms commented 11 years ago

I have a few beefs with FPP, but they are something we could perhaps extend to fix. Snippets evolved from an original, very simple idea, to be almost a clone of FPP quite by accident, so they may not be needed any more.

Perceived challenges with FPP that I wanted to address with Snippets:

  1. FPP appeared to be tightly integrated with the Panels interface (in that I was editing content through the Panels interface). Content Snippets only manage their placement and display through Panels, they do not expose any content through the Panels interface. This supports our goal of decoupling content management from Panels.
  2. We've also exposed the list of content snippets under Admin > Content which seems to be a far more sensible place. Managing them through FPP was a huge pain and not at all intuitive for users.
  3. Thanks to our decoupled design and the new Entity CRUD UI module and updated DLE, Snippets are dual-languaged. It would be more difficult to offer a usable DLE experience for FPP as their form is embedded in Panels (thus it is smaller and not controlled centrally like the Entity CRUD UI forms are).
  4. FPP -was- facing translation issues at the time, but those have since been fixed.
  5. FPP itself is a very unintuitive name for what the user is attempting to accomplish. It's a developer's name for a developer's tool, whereas Content Snippet is an editor's name for an editor's tool.
  6. FPP may be usable this way as well, but we explicitly designed CS to work with EntityReference as well, so that you can link a snippet to a node or bean and render it appropriately.
  7. Finally, I wanted full support for template files and view modes, similar to what nodes have.

It does seem like there's a lot of overlap, but I very much feel like FPP has been built for developers and I'm not a fan of that for many of our use cases (though it may make sense for some applications). CS provides a smoother workflow, more similar to how content works. When combined with the Bean project as well, I feel like it provides a unified editing experience where all the "content" of the site can be accessed from under the "Content" menu (and the new Entity menu in a future release of Entity CRUD UI), whereas FPP just does not provide the same experience.

Also, in building this myself, I was able to more fully leverage Entity CRUD UI and the new entity-based DLE to provide a much better experience than if I were to hack FPP in to the DLE like I did the nodes.

If you have thoughts on how we can meet these requirements by using FPP, I am all ears - contrib over custom any day. But it looked like the best option at the time to meet our goals quickly (especially since the translation issue was dragging on and on... an issue I did not run into while creating CS since I took translation into account from the beginning).

uottawa-wcms commented 11 years ago

Oh, also, we're looking at a few more usability enhancements, specifically:

While I'm sure we could leverage FPP for those, it seemed simpler to build our own as well in case special hooks were needed to accomplish the tasks. We'll need to hack it for nodes and views and stuff, so less hacking I have to do, the better.