ppf = page part form
Note: This is a long post and English is not my native language, so forgive me if its a bit unstructured or sounds gruff.
Well, this might be true for the most of us
I've read all of the comments and I understand there is a need to define multiple "elements" of sorts. These elements you would like to combine into a whole which you can then place on a page. Correct?
Not exactly, but close. The page_parts would be the one to do the job. They build the core of Frog/Wolf and the ppf plug-in. The only thing the plug-in does is the representation of these page parts for the administrator/editor. Right now only one page part can be shown at a time, the plug-in renders those page parts after a set of rules (e.g. text field, images, select boxes, lists, etc.)
Should these elements be form elements or can they be anything?
It boils all down to form elements, because this is the only thing how the end user can interact with the system.
Apart from that question, my initial reaction: my gut feeling is that this introduces too much complexity for the goals set for Wolf CMS core.
Well, my intention is not to add this to the core, BUT to add the possibility to the core if you do not want to add this to the core. If, and I only say if, this would be in the core, the whole edit interface would be described as a ppf definition. So each page has some kind of "layout definition" for the editing.
[...] introduces too much complexity for the goals set for Wolf CMS core
Well, this depends. The tab navigation for the page_parts is complex, too. We must clearly separate the use cases here.
Designer/Administrator: ensures that the page parts will be there for a page and define a form what/how the client enters the content. Currently the designer/administrator can't and must explain the creation of page_parts, inheritance for default content, etc
End user: just sees extra fields that must be filled
Sure we can argue about the use case, and I admit for simple page oriented projects it does not make much sense. My initial use case was an interface with has both sides, like cards in a deck with front and back side. I wanted to separate the content for the front and the flip side in frog and used page_parts for this. After some discussions, my customer requested me to have everything in sight --displayed at one page. This was how the ppf plug-in was born.
[...] However, I have yet to see a clearly defined description of that need.
[...] The answer I got was someone describing an implementation, not a need.
[...] This leads me to believe that the users themselves don't entirely know what they want or that we're trying to solve multiple, differing things.
Abstract: the need is to provide a flexible interface for content editing that depends on the type of content.
if the content type is a simple blog entry, it would be an excerpt and the body (or only the body with some "more" stop word)
if the type of content is a product, I would think of: description, order number, stock, price, etc.
if the type of content is a game review: there would be different types of information the user can not add to the existing text field in an unstructured way.
And here comes the thin line between writing an own plug-in for the content type, or use a more generic approach. And so to say it's not always that simple to choose between specific and generic. The benefit of a specific plug-in is to add custom checks (validation, help text, consistency, etc.) as well as the whole management and the own data model. On the other hand the generic approach enables not programmers (like designers) to create those interfaces with little effort. Think of it like PHP myAdmin for databases
Ideally, this would be transformed into a plugin. Hopefully M's plugin fits the bill exactly, otherwise some changes might be needed. (or an extra plugin)
As far as I can see, a plug-in (does not necessarily need do be mine), must be able to hook into the rendering of the editing interface. This could be implemented with some kind of delegate (either function or object), but I'm getting ahead of myself talking about implementation.
As far as I'm concerned, Wolf CMS should provide the core services and functionality (read API) to allow a whole host of plugins.
I'm with you.
As for the Flex CMS idea referenced by M - My initial feeling is that this is definitely too much complexity.
Well, I just wanted to highlight that if I (or someone else) writes such a plug-in this might be used for inspiration.
Currently, Wolf CMS is easy enough to explain to my mother aged 63. She uses it regularly to update her small site. True, there are a few niggles that need clearing up to improve simplicity and usability but these are small. This is something I wouldn't even try with Drupal.
I do not need to tell you that there are different use cases. Your mother will never edit HTML, PHP, or SQL to update her site as well as a photo editor to change the header. The ppf could even more add usability for the end user. The ppf definitions are managed by the technical responsible (supplier/designer/admin) and not by the end users. And please don't tell me filling out a form is more complex than navigation through a tab interface to edit content that belongs to the page.
So I guess my question is what do we want to do with Wolf?
Generic question, generic answer: edit and manage (structured) content
PS: your mother example reminds me, that having personas (Alan Cooper with "the inmates are running the asylum", his page about personas, other collection of articles) for Wolf would be a good thing. Instead of always stretching the capabilities of our examples. I can explain more if required.