Re: List of Plone content types

[Lucas Rocha <lucasr gnome org>]

Hey,

2009/5/18 Carsten Senger <senger rehfisch de>:
> Hi,
>
> Lucas Rocha schrieb:
>>
>> Hi,
>>
>> We need to define a list of content types which should be implemented
>> for the first release of the website. IIUC, content types, in Plone
>> lingo, are basically the types of content objects (events, news,
>> pages, images, etc) which should have a custom display in our website.
>>
>> My guess (which still depends on what exactly the content will look
>> like) is that we'll be surely working with those content types in the
>> 2.28 release:
>>  - Page (title, intro, content)
>
> Every Page has a description field. This is a plain text field and used in
> listings, search results etc. I changed the description to be required, but
> removed it from the document view template. Authors can add an
> introductional paragraph to their texts where it is suitable for the text.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=454564

Ok.

>>  - News (date, title, intro, content)
>>  - Front page (banner, news entries, intro, content, promo banners,
>> promo texts, etc)
>
>>
>>
>> Anything else?
>>
>> Some notes/questions to CMS guys:
>>  - Not sure Front page is actually a content type in Plone terms
>
> It is a hard coded template atm with config fields for the banner and the
> feeds.

Is that the final plan for the implementation of front page? During
the meeting I saw someone commenting about the Collage.

>>  - I guess pages can have subpages, right?
>
> You can add folders and they have subpages.

Oh, true.

>>  - Should we consider pages with different layouts as different
>> content types? For example, page with "banner + two text columns", or
>> "banner + text", etc.
>
> A content type can have different "views" that can be selected for the
> content object. But the content type has a fixed number of fields.
>
> It's easier to talk about requirements so plone guys can say how this can be
> done in plone with as few extra work as possible.
>
> I suggest to take a short tour through plone so the involved people know how
> the basic features of plone work and we can agree where we need changes or
> additions. Otherwise we will not necessary talk about the same things. The
> amount of volunteer work on the cms is limited and I want to avoid
> unnecessary work.

Ok, so the strategy you're proposing is to keep the default Plone
behavior as much as possible to avoid unnecessary extra work, right?
That makes sense to me. I'm guessing we won't require too many custom
views for our pages (based on the previously proposed content). But I
might be missing a lot of details due to my Plone ignorance.

In that case, I guess it's better to wait until we have clear
definition of the content and design before deciding about the work
needed on custom content type views? What do you think?

> Maybe we can do this in something like a shared desktop session so someone
> (I can do that) can explain what plone provides out of the box and how it
> works.

I'd say that this is not necessary. Let's make sure we have the
content/design requirements for custom views before deciding on the
custom views work.

--lucasr