On 28 May 2012 20:54, Lennart Regebro <regebro@...> wrote:
> On Mon, May 28, 2012 at 7:56 PM, Martin Aspeli <optilude+lists@...> wrote:
>> The idea of the "category" mechanism in Deco (as implemented in
>> plone.app.page) is that you can basically save a new TTW/GS-only FTI
>> on the fly, which uses the same basic schema and class as the default
>> (Dexterity-based) plone.page type, but which has a unique name, a
>> unique portal_type (for searching), possibly its own permission, a
>> specific default page layout (which you creates with a 'save as new
>> category' type operating on an existing content item), and possibly a
>> specific set of behaviours (e.g. to enable a content-lead image to be
>> used in listings agnostic of the content type through adaptation).
> OK, the difference between Deco and not Deco in this case is that in
> the non-Deco case, the News Item would have it's own portal type, it's
> own behaviors, it's own view and it's own schema, and in the Deco case
> it would have it's own portal type, it's own behaviors, it's own view,
> but share the schema with the default page type?
Technically, it'd have the same view in the Zope/CMF sense, since the
view of a Deco type is just 'render the body content HTML blob that
contains tile references in the markup. It would, however, have a
different *default* body content HTML blob with the layout of a news
item and tile references + placeholders where the title, description,
main text, image etc. go.
> So, then I have some new questions:
> 1. Since the schemas are equivalent in the non-Deco case as well (as
> the lead image would be a part of the behavior's schema) is there
> really a difference?
I'm not sure it's a given that the lead image would be part of a
behaviour. Ditto things like start/end date for Event. But yes, we
could make it less different and this would smoothen the migration
path. In fact, that's probably a very good idea.
> 2. Wouldn't it be better from a user experience point of view for
> managers if these types did *not* share the schema? It seems like a
> needless extra level of indirection if you edit the schemas separately
> from the portal types with Deco.
The schema is separate from the portal type in Dexterity, in that each
FTI references a schema (by XML blob, XML file reference or reference
to a python object, all of which resolve to a zope.interface schema).
For a Deco type, the schema contains no fields. It gets DC metadata
from the standard Dexterity DC metadata behaviours, and Deco layout
support from the ILayoutAware behaviour.
It makes little difference to content managers, really.
> With non-Deco Dexterity
There is no such thing as "Deco Dexterity" or "non-Deco Dexterity".
Dexterity is a content type framework. Deco is a WYSIWYG editor. Tiles
is a portlets/viewlets-like page snippets building mechanism. Blocks
is a rendering engine that can render page layouts with tiles into
site layouts with tiles.
Deco just lets you edit the page layout and insert tiles, which Blocks
then renders. The default Page type that uses Deco and stores the HTML
Deco produces is created with Dexterity.
>, you edit
> schemas TTW per portal type. Can't the same happen with Deco?
Sure. Deco is just something you get by applying a behaviour to a
Dexterity content type. It drives a whole bunch of adapter logic that
triggers the Deco UI and Blocks rendering engine.
In practice, I wouldn't expect non-programmers to care about that.
Administrators will probably do one of two things:
- If they want something that is like a web page and they want to
standardise a few layouts, they'll use the Deco UI to build up the
layout they want, then save that as a reusable category of page
(implementation: create a new FTI that's a clone of the page FTI with
some fields changed) that then becomes available to add around the
site. The UI for adding may be "add page" and then "choose category"
kind of like you open Word, click New and then pick a template from a
list of standard layouts.
- If they want something that is like managing structured data (staff
directory, invoice tracking, whatever), they'll use the Dexterity
control panel to define a series of fields (and hopefully a TTW
workflow editor to define workflow; it would be cool if they could
also use a Deco-like editor to create a view for that content type and
lay out display widgets for those fields, but I think this may blow a
few more minds so let's pretend you didn't read that).
> In that
> case when you create a new category/layout/portal_type, the schema
> would be copied as well, which would make the two use cases
> equivalent, except that you have a new TTW editor for making view
That's basically what happens. Except there isn't really a schema to
worry about, since the default Page schema is empty (there are no
type-specific fields, all the fields we care about comes from
behaviours, and the list of behaviours is copied).
Note that you can switch or modify the schema Dexterity types even
after creation. It's all just metadata of the FTI.
>>> Therefore, I still don't understand why the introduction of Deco needs
>>> we have to throw out p.a.ct.
>> I guess the point is that having a separate "News Item" type with its
>> own schema becomes pointless when you can have an configuration of
>> plone.page with a particular behaviour enabled (content lead image)
>> and default layout (image on the left or whatnot), and that in this
>> model the content author experience is to edit a (possibly
>> fixed-layout) Deco page not editing separate fields on an edit form
>> (image, description, image, etc).
> Yeah, I don't think I see why Deco makes a difference there. If the
> lead image is a part of the behavior, the schemas are equivalent. But
> making them the *same* actual schema is from a user experience point
> of view just confusing.
The end user doesn't really see the schema, though. It's an
implementation detail. I think we should just implement it however is
>> Similar argument could be made for Event, Folder (since Deco pages are
>> folderish, thus removing the need for the confusing default page
>> concept), etc.
>> Dylan's argument is, I think, that we can disrupt once by doing
>> everything at once.
> I still don't understand what the second disruption is.
Once to migrate to Dexterity (lots of infrastructure change and data
migration, add-ons that expect ATCT break, some UI changes). Again to
replace the default types with Deco page categories (lots of UI
I think there is a way to build p.a.contenttypes that's relatively
future-proof with Deco, though, and we should do that. I volunteer to
QA that bit.
> Obviously the
> migration to Dexterity is a massive disruption, but I still don't get
> why the move to Deco is or has to be a disruption at all. Hence I'm on
> both's side. :-) I think we should ship Plone 5 without Deco, and that
> we can include it in Plone 5.x without causing any disruptions at all.
If we go for full Deco, the other major change is that we lose
portlets in favour of tiles and we (kind of) lose main_template in
favour of a blob of HTML with tiles into which the page layout is
merged (and if we really go crazy, the site layout HTML blob can be
edited with Deco as well). That's quite a big disruption in a 5.x
release. I'd probably rather call it Plone 6. It can still come
quickly, though. A similar argument should be made about major UI
changes (since you'll no longer click edit and see a list of form
fields, you'll just see the page light up with editable regions).