folderish collections, contenttypes and dexterity

classic Classic list List threaded Threaded
21 messages Options
12
c.ledermann c.ledermann
Reply | Threaded
Open this post in threaded view
|

folderish collections, contenttypes and dexterity

Happy new year ;)

To revive the discussion about 'making everything folderish' in Plone.

The reason I am writing is that I played with kotti in the last year and after
the initial confusion on how to organize my content it had me sold on the
'everything is a container' paradigm.

Quote from https://github.com/collective/collective.folderishtypes :

The reason for this package is, that in my experience it's easier to
group related content together at one place. An article about
something fancy might have an image gallery associated with it as well
as some pdf-downloads. With this package you can put everything inside
the article. Another use case is that you can structure content
hierarchically and don't need to define "default pages" - a concept
hard to understand and handle (see:
http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
)

Alexander Limi also wished folderish content back in 2008: "#10:
Content re-use is overrated — people like
folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/

/Quote

With the change from Archetypes to dexterity we have the opportunity
to make this
paradigm shift.

I do not suggest that folders as contenttypes should 'go away'
altogether there are use cases
for a 'raw' folder and to abandon that type could potentially result
in a nightmare for migrations and
for add on developers who developed custom views for folders. Also
folders should still 'behave' in the way
we are used to (e.g. select content item as default view)

In addition content types should have a (below content?) viewlet to
display their contents
which can be turned on or off (thus turning a plone page into a rich
folder comparable
to topics in plone 2 vs plone 3)

Also I miss the nested collections. With the non folderish approach it
takes more effort to have
drill down collection hierarchies (first build a folder structure, add
a collection in every folder,
assign all the criteria, make it the default item) which i love and use a lot.

Looking forward for your thoughts and opinions on this


--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
ibi ibi
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

+gazillion on making everything folderish.

The folder + default view concept unnecessarily complicates content
management and it's a pain to explain to my clients (and for them to
use). Maybe for some types it would make sense to be non-folderish, but
I don't see a reason why Document, Event, News Item etc. couldn't be
folderish.

happy new year all :)

cheers,
ibi

On 01/07/2013 11:45 AM, Christian Ledermann wrote:

> Happy new year ;)
>
> To revive the discussion about 'making everything folderish' in Plone.
>
> The reason I am writing is that I played with kotti in the last year and after
> the initial confusion on how to organize my content it had me sold on the
> 'everything is a container' paradigm.
>
> Quote from https://github.com/collective/collective.folderishtypes :
>
> The reason for this package is, that in my experience it's easier to
> group related content together at one place. An article about
> something fancy might have an image gallery associated with it as well
> as some pdf-downloads. With this package you can put everything inside
> the article. Another use case is that you can structure content
> hierarchically and don't need to define "default pages" - a concept
> hard to understand and handle (see:
> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
> )
>
> Alexander Limi also wished folderish content back in 2008: "#10:
> Content re-use is overrated — people like
> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>
> /Quote
>
> With the change from Archetypes to dexterity we have the opportunity
> to make this
> paradigm shift.
>
> I do not suggest that folders as contenttypes should 'go away'
> altogether there are use cases
> for a 'raw' folder and to abandon that type could potentially result
> in a nightmare for migrations and
> for add on developers who developed custom views for folders. Also
> folders should still 'behave' in the way
> we are used to (e.g. select content item as default view)
>
> In addition content types should have a (below content?) viewlet to
> display their contents
> which can be turned on or off (thus turning a plone page into a rich
> folder comparable
> to topics in plone 2 vs plone 3)
>
> Also I miss the nested collections. With the non folderish approach it
> takes more effort to have
> drill down collection hierarchies (first build a folder structure, add
> a collection in every folder,
> assign all the criteria, make it the default item) which i love and use a lot.
>
> Looking forward for your thoughts and opinions on this
>
>
> --
> Best Regards,
>
> Christian Ledermann
>
> Nairobi - Kenya
> Mobile : +254 702978914
>
> <*)))>{
>
> If you save the living environment, the biodiversity that we have left,
> you will also automatically save the physical environment, too. But If
> you only save the physical environment, you will ultimately lose both.
>
> 1) Don’t drive species to extinction
>
> 2) Don’t destroy a habitat that species rely on.
>
> 3) Don’t change the climate in ways that will result in the above.
>
> }<(((*>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

--
Jure Cerjak
Termitnjak d.o.o.

Web: http://www.termitnjak.com
Tel: +386 (0)40 162-740
Email: [hidden email]
Skype: jurecerjak


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by c.ledermann

On 07/01/2013, at 11:45 PM, Christian Ledermann <[hidden email]> wrote:

> Happy new year ;)
>
> To revive the discussion about 'making everything folderish' in Plone.
>
> The reason I am writing is that I played with kotti in the last year and after
> the initial confusion on how to organize my content it had me sold on the
> 'everything is a container' paradigm.
>
> Quote from https://github.com/collective/collective.folderishtypes :
>
> The reason for this package is, that in my experience it's easier to
> group related content together at one place. An article about
> something fancy might have an image gallery associated with it as well
> as some pdf-downloads. With this package you can put everything inside
> the article. Another use case is that you can structure content
> hierarchically and don't need to define "default pages" - a concept
> hard to understand and handle (see:
> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
> )
>
> Alexander Limi also wished folderish content back in 2008: "#10:
> Content re-use is overrated — people like
> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>
> /Quote
>
> With the change from Archetypes to dexterity we have the opportunity
> to make this
> paradigm shift.
>
> I do not suggest that folders as contenttypes should 'go away'
> altogether there are use cases
> for a 'raw' folder and to abandon that type could potentially result
> in a nightmare for migrations and
> for add on developers who developed custom views for folders. Also
> folders should still 'behave' in the way
> we are used to (e.g. select content item as default view)
>
> In addition content types should have a (below content?) viewlet to
> display their contents
> which can be turned on or off (thus turning a plone page into a rich
> folder comparable
> to topics in plone 2 vs plone 3)
>
> Also I miss the nested collections. With the non folderish approach it
> takes more effort to have
> drill down collection hierarchies (first build a folder structure, add
> a collection in every folder,
> assign all the criteria, make it the default item) which i love and use a lot.
>
> Looking forward for your thoughts and opinions on this

I think most people feel the same way and the plan is to make everything folderish with deco.

see https://github.com/plone/buildout.deco/blob/master/docs/faq.rst#what-happens-to-content-types

The deco concepts are elegant and simplify many things, not just folders. I think that given any major UI change takes a lot of effort and testing deco is better bang for our buck than just introducing the everything-folderish part by itself.

There is work underway in finishing deco but it needs more time and people.

>
>
> --
> Best Regards,
>
> Christian Ledermann
>
> Nairobi - Kenya
> Mobile : +254 702978914
>
> <*)))>{
>
> If you save the living environment, the biodiversity that we have left,
> you will also automatically save the physical environment, too. But If
> you only save the physical environment, you will ultimately lose both.
>
> 1) Don’t drive species to extinction
>
> 2) Don’t destroy a habitat that species rely on.
>
> 3) Don’t change the climate in ways that will result in the above.
>
> }<(((*>
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
johannes raggam johannes raggam
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by c.ledermann
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm a fan of folderish stuff, which was the reason why i wrote
collective.folderishtypes. I use it for nearly every client project
since then.

Please note, there are two portlets included in collective.folderishtypes:

- - collective.folderishtypes.listing: This is based on the
folder_listing view and displays all folder contents as the
folder_listing view does.

- - collective.folderishtypes.contextual_contents: This one allows you
to define the content types to display in the portlet. It is very
useful if you want to display downloads, images and the like in
different portlets.

This addon is obsolete for Dexterity based content types. We can
define them to be folderish with a click or a simple configuration
statement.


Cheers,
Johannes Raggam




On 01/07/2013 11:45 AM, Christian Ledermann wrote:

> Happy new year ;)
>
> To revive the discussion about 'making everything folderish' in
> Plone.
>
> The reason I am writing is that I played with kotti in the last
> year and after the initial confusion on how to organize my content
> it had me sold on the 'everything is a container' paradigm.
>
> Quote from https://github.com/collective/collective.folderishtypes
> :
>
> The reason for this package is, that in my experience it's easier
> to group related content together at one place. An article about
> something fancy might have an image gallery associated with it as
> well as some pdf-downloads. With this package you can put
> everything inside the article. Another use case is that you can
> structure content hierarchically and don't need to define "default
> pages" - a concept hard to understand and handle (see:
> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
>
>
)

>
> Alexander Limi also wished folderish content back in 2008: "#10:
> Content re-use is overrated — people like
> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>
>  /Quote
>
> With the change from Archetypes to dexterity we have the
> opportunity to make this paradigm shift.
>
> I do not suggest that folders as contenttypes should 'go away'
> altogether there are use cases for a 'raw' folder and to abandon
> that type could potentially result in a nightmare for migrations
> and for add on developers who developed custom views for folders.
> Also folders should still 'behave' in the way we are used to (e.g.
> select content item as default view)
>
> In addition content types should have a (below content?) viewlet
> to display their contents which can be turned on or off (thus
> turning a plone page into a rich folder comparable to topics in
> plone 2 vs plone 3)
>
> Also I miss the nested collections. With the non folderish approach
> it takes more effort to have drill down collection hierarchies
> (first build a folder structure, add a collection in every folder,
> assign all the criteria, make it the default item) which i love and
> use a lot.
>
> Looking forward for your thoughts and opinions on this
>
>
> -- Best Regards,
>
> Christian Ledermann
>
> Nairobi - Kenya Mobile : +254 702978914
>
> <*)))>{
>
> If you save the living environment, the biodiversity that we have
> left, you will also automatically save the physical environment,
> too. But If you only save the physical environment, you will
> ultimately lose both.
>
> 1) Don’t drive species to extinction
>
> 2) Don’t destroy a habitat that species rely on.
>
> 3) Don’t change the climate in ways that will result in the above.
>
> }<(((*>
>
> ------------------------------------------------------------------------------
>
>
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
> current with LearnDevNow - 3,200 step-by-step video tutorials by
> Microsoft MVPs and experts. SALE $99.99 this month only -- learn
> more at: http://p.sf.net/sfu/learnmore_122412 
> _______________________________________________ Plone-developers
> mailing list [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>


- --
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: [hidden email]
web:  http://programmatic.pro
      http://bluedynamics.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDqvbQACgkQW4mNMQxDgAd/NwCg1jx0eGJrsC9YtAzTZZM3/nLy
SVsAn0zm6EqLqnc61DHGgrb+9zeHQ8Kh
=wig3
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
johannes raggam johannes raggam
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by ibi
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/2013 12:25 PM, Jure Cerjak wrote:
> +gazillion on making everything folderish.
>
> The folder + default view concept unnecessarily complicates content
>  management and it's a pain to explain to my clients (and for them
> to use). Maybe for some types it would make sense to be
> non-folderish, but I don't see a reason why Document, Event, News
> Item etc. couldn't be folderish.

Regarding the default view concept: I often have the requirement to
have redirects to submenu entries / subfolders, which should be also
displayed in the menu. This could be done with the default view and a
navtree customization or - what I prefer - via a redirect to the first
content in a folder.
Thats the purpose of collective.folderishtraverse, which provides a
traverse_view view.

Cheers,
Johannes Raggam

>
> happy new year all :)
>
> cheers, ibi
>
> On 01/07/2013 11:45 AM, Christian Ledermann wrote:
>> Happy new year ;)
>>
>> To revive the discussion about 'making everything folderish' in
>> Plone.
>>
>> The reason I am writing is that I played with kotti in the last
>> year and after the initial confusion on how to organize my
>> content it had me sold on the 'everything is a container'
>> paradigm.
>>
>> Quote from
>> https://github.com/collective/collective.folderishtypes :
>>
>> The reason for this package is, that in my experience it's easier
>> to group related content together at one place. An article about
>> something fancy might have an image gallery associated with it as
>> well as some pdf-downloads. With this package you can put
>> everything inside the article. Another use case is that you can
>> structure content hierarchically and don't need to define
>> "default pages" - a concept hard to understand and handle (see:
>> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
>>
>>
)
>>
>> Alexander Limi also wished folderish content back in 2008: "#10:
>> Content re-use is overrated — people like
>> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>>
>>
>>
/Quote

>>
>> With the change from Archetypes to dexterity we have the
>> opportunity to make this paradigm shift.
>>
>> I do not suggest that folders as contenttypes should 'go away'
>> altogether there are use cases for a 'raw' folder and to abandon
>> that type could potentially result in a nightmare for migrations
>> and for add on developers who developed custom views for folders.
>> Also folders should still 'behave' in the way we are used to
>> (e.g. select content item as default view)
>>
>> In addition content types should have a (below content?) viewlet
>> to display their contents which can be turned on or off (thus
>> turning a plone page into a rich folder comparable to topics in
>> plone 2 vs plone 3)
>>
>> Also I miss the nested collections. With the non folderish
>> approach it takes more effort to have drill down collection
>> hierarchies (first build a folder structure, add a collection in
>> every folder, assign all the criteria, make it the default item)
>> which i love and use a lot.
>>
>> Looking forward for your thoughts and opinions on this
>>
>>
>> -- Best Regards,
>>
>> Christian Ledermann
>>
>> Nairobi - Kenya Mobile : +254 702978914
>>
>> <*)))>{
>>
>> If you save the living environment, the biodiversity that we have
>> left, you will also automatically save the physical environment,
>> too. But If you only save the physical environment, you will
>> ultimately lose both.
>>
>> 1) Don’t drive species to extinction
>>
>> 2) Don’t destroy a habitat that species rely on.
>>
>> 3) Don’t change the climate in ways that will result in the
>> above.
>>
>> }<(((*>
>>
>> ------------------------------------------------------------------------------
>>
>>
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
>> current with LearnDevNow - 3,200 step-by-step video tutorials by
>> Microsoft MVPs and experts. SALE $99.99 this month only -- learn
>> more at: http://p.sf.net/sfu/learnmore_122412 
>> _______________________________________________ Plone-developers
>> mailing list [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>


- --
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: [hidden email]
web:  http://programmatic.pro
      http://bluedynamics.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDqvrMACgkQW4mNMQxDgAfnNwCgzZN10e3wdFv4CCocLBkDqU0r
fzQAoJdZUPhSwecjU2rHURlsaghnz0sc
=YNP2
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
yuri-2 yuri-2
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

Why folderish is not just a behaviour? I mean, to move a type to be
folderish now with Dexterity you've to do like here:

https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa

- <property name="klass">plone.dexterity.content.Item</property>
+ <property name="klass">plone.dexterity.content.Container</property>

that means to change the base class.

I think it is for some backward compatibility or whatever else?


Il 07/01/2013 13:25, johannes raggam ha scritto:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 01/07/2013 12:25 PM, Jure Cerjak wrote:
>> +gazillion on making everything folderish.
>>
>> The folder + default view concept unnecessarily complicates content
>>   management and it's a pain to explain to my clients (and for them
>> to use). Maybe for some types it would make sense to be
>> non-folderish, but I don't see a reason why Document, Event, News
>> Item etc. couldn't be folderish.
> Regarding the default view concept: I often have the requirement to
> have redirects to submenu entries / subfolders, which should be also
> displayed in the menu. This could be done with the default view and a
> navtree customization or - what I prefer - via a redirect to the first
> content in a folder.
> Thats the purpose of collective.folderishtraverse, which provides a
> traverse_view view.
>
> Cheers,
> Johannes Raggam
>
>> happy new year all :)
>>
>> cheers, ibi
>>
>> On 01/07/2013 11:45 AM, Christian Ledermann wrote:
>>> Happy new year ;)
>>>
>>> To revive the discussion about 'making everything folderish' in
>>> Plone.
>>>
>>> The reason I am writing is that I played with kotti in the last
>>> year and after the initial confusion on how to organize my
>>> content it had me sold on the 'everything is a container'
>>> paradigm.
>>>
>>> Quote from
>>> https://github.com/collective/collective.folderishtypes :
>>>
>>> The reason for this package is, that in my experience it's easier
>>> to group related content together at one place. An article about
>>> something fancy might have an image gallery associated with it as
>>> well as some pdf-downloads. With this package you can put
>>> everything inside the article. Another use case is that you can
>>> structure content hierarchically and don't need to define
>>> "default pages" - a concept hard to understand and handle (see:
>>> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
>>>
>>>
> )
>>> Alexander Limi also wished folderish content back in 2008: "#10:
>>> Content re-use is overrated — people like
>>> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>>>
>>>
>>>
> /Quote
>>> With the change from Archetypes to dexterity we have the
>>> opportunity to make this paradigm shift.
>>>
>>> I do not suggest that folders as contenttypes should 'go away'
>>> altogether there are use cases for a 'raw' folder and to abandon
>>> that type could potentially result in a nightmare for migrations
>>> and for add on developers who developed custom views for folders.
>>> Also folders should still 'behave' in the way we are used to
>>> (e.g. select content item as default view)
>>>
>>> In addition content types should have a (below content?) viewlet
>>> to display their contents which can be turned on or off (thus
>>> turning a plone page into a rich folder comparable to topics in
>>> plone 2 vs plone 3)
>>>
>>> Also I miss the nested collections. With the non folderish
>>> approach it takes more effort to have drill down collection
>>> hierarchies (first build a folder structure, add a collection in
>>> every folder, assign all the criteria, make it the default item)
>>> which i love and use a lot.
>>>
>>> Looking forward for your thoughts and opinions on this
>>>
>>>
>>> -- Best Regards,
>>>
>>> Christian Ledermann
>>>
>>> Nairobi - Kenya Mobile : +254 702978914
>>>
>>> <*)))>{
>>>
>>> If you save the living environment, the biodiversity that we have
>>> left, you will also automatically save the physical environment,
>>> too. But If you only save the physical environment, you will
>>> ultimately lose both.
>>>
>>> 1) Don’t drive species to extinction
>>>
>>> 2) Don’t destroy a habitat that species rely on.
>>>
>>> 3) Don’t change the climate in ways that will result in the
>>> above.
>>>
>>> }<(((*>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills
>>> current with LearnDevNow - 3,200 step-by-step video tutorials by
>>> Microsoft MVPs and experts. SALE $99.99 this month only -- learn
>>> more at: http://p.sf.net/sfu/learnmore_122412
>>> _______________________________________________ Plone-developers
>>> mailing list [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>
> - --
> programmatic  web development
> di(fh) johannes raggam / thet
> python plone zope development
> mail: [hidden email]
> web:  http://programmatic.pro
>        http://bluedynamics.com
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDqvrMACgkQW4mNMQxDgAfnNwCgzZN10e3wdFv4CCocLBkDqU0r
> fzQAoJdZUPhSwecjU2rHURlsaghnz0sc
> =YNP2
> -----END PGP SIGNATURE-----
>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

On 1/7/13 5:11 AM, Yuri wrote:

> Why folderish is not just a behaviour? I mean, to move a type to be
> folderish now with Dexterity you've to do like here:
>
> https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa
>
> - <property name="klass">plone.dexterity.content.Item</property>
> + <property name="klass">plone.dexterity.content.Container</property>
>
> that means to change the base class.
>
> I think it is for some backward compatibility or whatever else?
>
>
The Item class does not set up a BTree structure for storing contents,
and does not have the various methods used for interacting with a
container (__getitem__, __setitem__, etc)

You can just use Container for everything from the start if you want, of
course. The tradeoff is about 100-200 extra bytes written to the ZODB
each time the item is modified.

David

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by c.ledermann
On 1/7/13 2:45 AM, Christian Ledermann wrote:

> Happy new year ;)
>
> To revive the discussion about 'making everything folderish' in Plone.
>
> The reason I am writing is that I played with kotti in the last year and after
> the initial confusion on how to organize my content it had me sold on the
> 'everything is a container' paradigm.
>
> Quote from https://github.com/collective/collective.folderishtypes :
>
> The reason for this package is, that in my experience it's easier to
> group related content together at one place. An article about
> something fancy might have an image gallery associated with it as well
> as some pdf-downloads. With this package you can put everything inside
> the article. Another use case is that you can structure content
> hierarchically and don't need to define "default pages" - a concept
> hard to understand and handle (see:
> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
> )
>
> Alexander Limi also wished folderish content back in 2008: "#10:
> Content re-use is overrated — people like
> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>
> /Quote
>
> With the change from Archetypes to dexterity we have the opportunity
> to make this
> paradigm shift.
>
> I do not suggest that folders as contenttypes should 'go away'
> altogether there are use cases
> for a 'raw' folder and to abandon that type could potentially result
> in a nightmare for migrations and
> for add on developers who developed custom views for folders. Also
> folders should still 'behave' in the way
> we are used to (e.g. select content item as default view)
>
> In addition content types should have a (below content?) viewlet to
> display their contents
> which can be turned on or off (thus turning a plone page into a rich
> folder comparable
> to topics in plone 2 vs plone 3)
>
> Also I miss the nested collections. With the non folderish approach it
> takes more effort to have
> drill down collection hierarchies (first build a folder structure, add
> a collection in every folder,
> assign all the criteria, make it the default item) which i love and use a lot.
>
> Looking forward for your thoughts and opinions on this
>
>
>
I generally like the idea of making everything folderish, but I have a
couple specific concerns:

a. I think someone pointed out that versioning and/or staging doesn't
work as well with folderish items.
b. Say I have, in current Plone, a folder with a default page and a
whole bunch of contained items. Currently, if I decide I want a
different type to show up when the root of that folder is shown, it's
very easy. If we get rid of the concept of default pages, it would
require creating a new item, moving all the contained items, deleting
the original item, and then renaming the new item. A couple of those
steps would require lengthy reindexing due to the many contained items.


------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

On 08/01/2013, at 6:46 AM, "David Glick (Plone)" <[hidden email]> wrote:

> On 1/7/13 2:45 AM, Christian Ledermann wrote:
>> Happy new year ;)
>>
>> To revive the discussion about 'making everything folderish' in Plone.
>>
>> The reason I am writing is that I played with kotti in the last year and after
>> the initial confusion on how to organize my content it had me sold on the
>> 'everything is a container' paradigm.
>>
>> Quote from https://github.com/collective/collective.folderishtypes :
>>
>> The reason for this package is, that in my experience it's easier to
>> group related content together at one place. An article about
>> something fancy might have an image gallery associated with it as well
>> as some pdf-downloads. With this package you can put everything inside
>> the article. Another use case is that you can structure content
>> hierarchically and don't need to define "default pages" - a concept
>> hard to understand and handle (see:
>> http://www.sixfeetup.com/blog/plone-vs.-drupal-core-features-comparison
>> )
>>
>> Alexander Limi also wished folderish content back in 2008: "#10:
>> Content re-use is overrated — people like
>> folderish"http://limi.net/articles/18-things-i-wish-were-true-about-plone/
>>
>> /Quote
>>
>> With the change from Archetypes to dexterity we have the opportunity
>> to make this
>> paradigm shift.
>>
>> I do not suggest that folders as contenttypes should 'go away'
>> altogether there are use cases
>> for a 'raw' folder and to abandon that type could potentially result
>> in a nightmare for migrations and
>> for add on developers who developed custom views for folders. Also
>> folders should still 'behave' in the way
>> we are used to (e.g. select content item as default view)
>>
>> In addition content types should have a (below content?) viewlet to
>> display their contents
>> which can be turned on or off (thus turning a plone page into a rich
>> folder comparable
>> to topics in plone 2 vs plone 3)
>>
>> Also I miss the nested collections. With the non folderish approach it
>> takes more effort to have
>> drill down collection hierarchies (first build a folder structure, add
>> a collection in every folder,
>> assign all the criteria, make it the default item) which i love and use a lot.
>>
>> Looking forward for your thoughts and opinions on this
> I generally like the idea of making everything folderish, but I have a
> couple specific concerns:
>
> a. I think someone pointed out that versioning and/or staging doesn't
> work as well with folderish items.
> b. Say I have, in current Plone, a folder with a default page and a
> whole bunch of contained items. Currently, if I decide I want a
> different type to show up when the root of that folder is shown, it's
> very easy. If we get rid of the concept of default pages, it would
> require creating a new item, moving all the contained items, deleting
> the original item, and then renaming the new item. A couple of those
> steps would require lengthy reindexing due to the many contained items.
>

I think this becomes somewhat less of an issue with deco since you can
have many if your type-ness represented by tiles which can be added
and removed and you have less hard coded types overall.
All so keep in mind with current plone you have the opposite problem.
If you want to go from a page type to folderish you need to rename it,
create a folder then move that page into the folder and make it
default content. So which ever way, if we have semantic meaning of
type modeled using plone classes you run into problems. Moving "type"
into a property of an object that can be changed at runtime I think is
the direction we need to go in. At least for 90% of content types.



>
> ------------------------------------------------------------------------------
> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
> MVPs and experts. SALE $99.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122412
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122412
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Sean Upton Sean Upton
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by David Glick (Plone)
On Mon, Jan 7, 2013 at 10:40 AM, David Glick (Plone)
<[hidden email]> wrote:
> You can just use Container for everything from the start if you want, of
> course. The tradeoff is about 100-200 extra bytes written to the ZODB
> each time the item is modified.

Would it be possible (and benign) to use some kind of __getstate__()
hack to prevent writing an empty _tree and instead write some sentinel
value for empty/not-in-use?

Sean

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
David Glick (Plone) David Glick (Plone)
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

On 1/7/13 5:04 PM, Sean Upton wrote:
> On Mon, Jan 7, 2013 at 10:40 AM, David Glick (Plone)
> <[hidden email]> wrote:
>> You can just use Container for everything from the start if you want, of
>> course. The tradeoff is about 100-200 extra bytes written to the ZODB
>> each time the item is modified.
> Would it be possible (and benign) to use some kind of __getstate__()
> hack to prevent writing an empty _tree and instead write some sentinel
> value for empty/not-in-use?
>
It would probably be saner to modify BTreeFolder2 to create the _tree
lazily rather than using __getstate__. I'm not sure it's worth the
effort though.
David

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Sean Upton Sean Upton
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by yuri-2
On Mon, Jan 7, 2013 at 6:11 AM, Yuri <[hidden email]> wrote:

> Why folderish is not just a behaviour? I mean, to move a type to be
> folderish now with Dexterity you've to do like here:
>
> https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa
>
> - <property name="klass">plone.dexterity.content.Item</property>
> + <property name="klass">plone.dexterity.content.Container</property>
>
> that means to change the base class.
>
> I think it is for some backward compatibility or whatever else?

Of course, this does not work without a catch for existing content --
you will need to write your own migrations for the items after
changing the klass property in the FTI.

It is always, IMHO, advisable to have your own custom content class
always, so changing your assumptions from Item to Container only
involves changing a superclass in your code and re-using existing
migration code in plone.app.folder.migration.BTreeMigrationView (which
seems simpler because it is in-place, does not require a tool like
zodbupdate or a copy of item data).

Sean

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Timo Stollenwerk Timo Stollenwerk
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

Am 08.01.2013 02:10, schrieb Sean Upton:

> On Mon, Jan 7, 2013 at 6:11 AM, Yuri <[hidden email]> wrote:
>> Why folderish is not just a behaviour? I mean, to move a type to be
>> folderish now with Dexterity you've to do like here:
>>
>> https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa
>>
>> - <property name="klass">plone.dexterity.content.Item</property>
>> + <property name="klass">plone.dexterity.content.Container</property>
>>
>> that means to change the base class.
>>
>> I think it is for some backward compatibility or whatever else?
>
> Of course, this does not work without a catch for existing content --
> you will need to write your own migrations for the items after
> changing the klass property in the FTI.
>
> It is always, IMHO, advisable to have your own custom content class
> always, so changing your assumptions from Item to Container only
> involves changing a superclass in your code and re-using existing
> migration code in plone.app.folder.migration.BTreeMigrationView (which
> seems simpler because it is in-place, does not require a tool like
> zodbupdate or a copy of item data).

This also might become less of an issue once we use
plone.app.contenttypes (dexterity-based ATContentTypes replacement). One
of the goals of the upcoming sprint in Munich will be to factor out most
(if not all) of the content type functionality into behaviors. If the
default content types are just an name/fti with some behaviors attached,
it will become really easy to just write some folderish replacements
that use the same behaviors as the standard default types.

Timo

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Matt Barkau (public) Matt Barkau (public)
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by David Glick (Plone)


On Mon, Jan 7, 2013 at 11:45 AM, David Glick (Plone) <[hidden email]> wrote:
I generally like the idea of making everything folderish, but I have a
couple specific concerns:

a. I think someone pointed out that versioning and/or staging doesn't
work as well with folderish items.

Factors in this area include:
 - Working copies (AKA in-place staging) of folders also copy children by default. This preserves default view pages, but wouldn't be needed for an 'everything folderish' Plone.
 - The working-copied children can contain references to original version items like inline images, which can be misleading & breakable.
 - There's no default way to say that you only want to make a working copy of only the parent, and not the children.
 - Working copies of folders just under the site root (containing many children) can be huge, and even time out.
 - Other cousins of folders like form folders probably should copy the children though, so then there has to be clear differentiation between folderish types whose children are working-copied, and those that aren't.  Without a clear differentiation, the current situation is "...prone to generate extreme frustration with users who expect the *other* behavior."

So far, I haven't been able to think of a scenario where it would be necessary to make a working copy of an archetypes Folder including its children.  Even if you were redoing a large section (folder) of the site, you usually would not maintain a 1:1 correspondence between all old and new pages, so there wouldn't be much benefit to checking in a working copy of an entire folder structure at once.  I don't think there would be enough benefit to warrant the performance hit and complexity, even if everything worked without error, so I'm in favor of versioning & working copies being for the parent (container) only.

References:
http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html
http://plone.293351.n2.nabble.com/plone-app-iterate-Why-is-working-copy-support-tied-to-versioning-td7498463.html
http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-td6182294.html
http://stackoverflow.com/questions/6457438/how-to-check-in-a-working-copy-if-the-default-workflow-is-plone-workflow-or-intr
https://dev.plone.org/ticket/7372
http://plone.293351.n2.nabble.com/The-checkout-and-check-in-operation-of-plone-iterate-changes-the-folder-sort-order-td6382589.html
https://dev.plone.org/ticket/12257
https://dev.plone.org/ticket/7529
https://dev.plone.org/ticket/11906 <-- why was this closed?

 
b. Say I have, in current Plone, a folder with a default page and a
whole bunch of contained items. Currently, if I decide I want a
different type to show up when the root of that folder is shown, it's
very easy. If we get rid of the concept of default pages, it would
require creating a new item, moving all the contained items, deleting
the original item, and then renaming the new item. A couple of those
steps would require lengthy reindexing due to the many contained items.

I think that in the 'pages folderish' Plone, you'd teach people a different approach / mental model.  For instance, in the current approach you'd change the default view on /about from /about/our-story to /about/our-mission.  The need could be stated by a user something like, "I originally put all of the success stories under /about/our-story, but now I need to have them under /about/our-mission."  In the 'pages folderish' Plone, you'd instruct the user to select and cut the child pages from under the old location, and paste them into the new location.  The only folks I've seen who don't have an issue learning default view pages are those who've had less experience with something like Wordpress and more experience putting a static index.html in place on a plain web server folder.

Here's a lame attempt to reify this:
The physical analog with folders would be that current Plone folders are like 3-ring binders which let you yank out (or copy) any page and stick it in the clear front cover pocket:
http://mychocolatemoments.com/wp-content/uploads/2012/08/lesson-plan-book.jpg
The proposed change would be to eliminate the binder's clear front cover pocket, and instead give you an erasable front cover surface like a whiteboard:
http://www.hellotrade.com/c-line-products/self-stick-dry-erase-sheets.html
I've seen that people want to edit the whiteboard directly, rather than pulling sheets out to stick them in the cover.  I think that's because the cover is supposed to describe all of the contents, and individual sheets usually only describe a subset of them.  And consumer 'office stores' now only sell the kind with the whiteboard on the cover.  :)

Are there examples out in the wild where people think in terms of swapping out default 'cover' pages from within the folder (which aren't based on having learned the Plone / web server index.html approach)?


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
yuri-2 yuri-2
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by Timo Stollenwerk
Il 08/01/2013 07:20, Timo Stollenwerk ha scritto:

> Am 08.01.2013 02:10, schrieb Sean Upton:
>> On Mon, Jan 7, 2013 at 6:11 AM, Yuri<[hidden email]>  wrote:
>>> Why folderish is not just a behaviour? I mean, to move a type to be
>>> folderish now with Dexterity you've to do like here:
>>>
>>> https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa
>>>
>>> -<property name="klass">plone.dexterity.content.Item</property>
>>> +<property name="klass">plone.dexterity.content.Container</property>
>>>
>>> that means to change the base class.
>>>
>>> I think it is for some backward compatibility or whatever else?
>> Of course, this does not work without a catch for existing content --
>> you will need to write your own migrations for the items after
>> changing the klass property in the FTI.
>>
>> It is always, IMHO, advisable to have your own custom content class
>> always, so changing your assumptions from Item to Container only
>> involves changing a superclass in your code and re-using existing
>> migration code in plone.app.folder.migration.BTreeMigrationView (which
>> seems simpler because it is in-place, does not require a tool like
>> zodbupdate or a copy of item data).
> This also might become less of an issue once we use
> plone.app.contenttypes (dexterity-based ATContentTypes replacement). One
> of the goals of the upcoming sprint in Munich will be to factor out most
> (if not all) of the content type functionality into behaviors. If the
> default content types are just an name/fti with some behaviors attached,
> it will become really easy to just write some folderish replacements
> that use the same behaviors as the standard default types.
>
> Timo
>

Bingo!

That was my question, if the "folderish" being of a content type could
be "moved" to a dexterity behaviour. Timo says "yes", If I understand
well...

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Timo Stollenwerk Timo Stollenwerk
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

Am 08.01.2013 08:28, schrieb Yuri:

> Il 08/01/2013 07:20, Timo Stollenwerk ha scritto:
>> Am 08.01.2013 02:10, schrieb Sean Upton:
>>> On Mon, Jan 7, 2013 at 6:11 AM, Yuri<[hidden email]>  wrote:
>>>> Why folderish is not just a behaviour? I mean, to move a type to be
>>>> folderish now with Dexterity you've to do like here:
>>>>
>>>> https://github.com/lzdych/plone.app.layoutpage/commit/478564912d46a7232041fa645d1c0d93d2fb2faa
>>>>
>>>> -<property name="klass">plone.dexterity.content.Item</property>
>>>> +<property name="klass">plone.dexterity.content.Container</property>
>>>>
>>>> that means to change the base class.
>>>>
>>>> I think it is for some backward compatibility or whatever else?
>>> Of course, this does not work without a catch for existing content --
>>> you will need to write your own migrations for the items after
>>> changing the klass property in the FTI.
>>>
>>> It is always, IMHO, advisable to have your own custom content class
>>> always, so changing your assumptions from Item to Container only
>>> involves changing a superclass in your code and re-using existing
>>> migration code in plone.app.folder.migration.BTreeMigrationView (which
>>> seems simpler because it is in-place, does not require a tool like
>>> zodbupdate or a copy of item data).
>> This also might become less of an issue once we use
>> plone.app.contenttypes (dexterity-based ATContentTypes replacement). One
>> of the goals of the upcoming sprint in Munich will be to factor out most
>> (if not all) of the content type functionality into behaviors. If the
>> default content types are just an name/fti with some behaviors attached,
>> it will become really easy to just write some folderish replacements
>> that use the same behaviors as the standard default types.
>>
>> Timo
>>
>
> Bingo!
>
> That was my question, if the "folderish" being of a content type could
> be "moved" to a dexterity behaviour. Timo says "yes", If I understand
> well...

That might be a misunderstanding. Maybe I did not explain it well. What
I'm saying is that if everything that a content type really does (fields
and functionality) is a behavior, it is really easy to create new
folderish content types (document, news item, etc.) that replace the
standard content types.

Say you want a folderish collection, if the collection functionality
(fields and widgets) is a behavior, the only thing you have to do is
create a folderish type (that can replace the default collection type)
with the collection-behavior and you are done. You can even do this TTW.

(To make this really work within Plone we have to make sure the other
Plone parts know and use the interfaces of these types of course.)

I don't know enough about the dexterity internals but I would guess that
the base classes can't be factored out as a behavior. After all
behaviors need a base class they can be adapted to.

Timo

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
AnthonyG AnthonyG
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by Matt Barkau (public)
Yes working copies don't really work for folderish types right now.  We switch off working-copy behaviour for all folderish types in all our Plone implementations.

In a Dexterity implementation we worked around this by having folderish types associated with a specific "data" type using a standardised id for the data type.  e.g. we had a "country" type and a "country data" type and the country data for the country had an id "country-data".  We then switched on working-copy behaviour for "country data".

It's always felt wrong to me that working copy creates a new object.  I have previously worked with Morello, an enterprise level Java CMS.  That combines working copy support with versioning which works more like source control.  You have a published version of an object.  To start editing that you create a new version of the same object that isn't published yet - a bit like creating a branch.  Publishing the working copy is like merging your branch.  I don't know enough about Zope to know whether this is possible with Plone.

I can imagine a use case whereby a content author wants to prepare a set of content changes that span multiple pages and publish all these in one go but in practice I haven't had a request for such a feature.




On 8 January 2013 06:47, Matt Barkau (public) <[hidden email]> wrote:


On Mon, Jan 7, 2013 at 11:45 AM, David Glick (Plone) <[hidden email]> wrote:
I generally like the idea of making everything folderish, but I have a
couple specific concerns:

a. I think someone pointed out that versioning and/or staging doesn't
work as well with folderish items.

Factors in this area include:
 - Working copies (AKA in-place staging) of folders also copy children by default. This preserves default view pages, but wouldn't be needed for an 'everything folderish' Plone.
 - The working-copied children can contain references to original version items like inline images, which can be misleading & breakable.
 - There's no default way to say that you only want to make a working copy of only the parent, and not the children.
 - Working copies of folders just under the site root (containing many children) can be huge, and even time out.
 - Other cousins of folders like form folders probably should copy the children though, so then there has to be clear differentiation between folderish types whose children are working-copied, and those that aren't.  Without a clear differentiation, the current situation is "...prone to generate extreme frustration with users who expect the *other* behavior."

So far, I haven't been able to think of a scenario where it would be necessary to make a working copy of an archetypes Folder including its children.  Even if you were redoing a large section (folder) of the site, you usually would not maintain a 1:1 correspondence between all old and new pages, so there wouldn't be much benefit to checking in a working copy of an entire folder structure at once.  I don't think there would be enough benefit to warrant the performance hit and complexity, even if everything worked without error, so I'm in favor of versioning & working copies being for the parent (container) only.

References:
http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html
http://plone.293351.n2.nabble.com/plone-app-iterate-Why-is-working-copy-support-tied-to-versioning-td7498463.html
http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-td6182294.html
http://stackoverflow.com/questions/6457438/how-to-check-in-a-working-copy-if-the-default-workflow-is-plone-workflow-or-intr
https://dev.plone.org/ticket/7372
http://plone.293351.n2.nabble.com/The-checkout-and-check-in-operation-of-plone-iterate-changes-the-folder-sort-order-td6382589.html
https://dev.plone.org/ticket/12257
https://dev.plone.org/ticket/7529
https://dev.plone.org/ticket/11906 <-- why was this closed?

 
b. Say I have, in current Plone, a folder with a default page and a
whole bunch of contained items. Currently, if I decide I want a
different type to show up when the root of that folder is shown, it's
very easy. If we get rid of the concept of default pages, it would
require creating a new item, moving all the contained items, deleting
the original item, and then renaming the new item. A couple of those
steps would require lengthy reindexing due to the many contained items.

I think that in the 'pages folderish' Plone, you'd teach people a different approach / mental model.  For instance, in the current approach you'd change the default view on /about from /about/our-story to /about/our-mission.  The need could be stated by a user something like, "I originally put all of the success stories under /about/our-story, but now I need to have them under /about/our-mission."  In the 'pages folderish' Plone, you'd instruct the user to select and cut the child pages from under the old location, and paste them into the new location.  The only folks I've seen who don't have an issue learning default view pages are those who've had less experience with something like Wordpress and more experience putting a static index.html in place on a plain web server folder.

Here's a lame attempt to reify this:
The physical analog with folders would be that current Plone folders are like 3-ring binders which let you yank out (or copy) any page and stick it in the clear front cover pocket:
http://mychocolatemoments.com/wp-content/uploads/2012/08/lesson-plan-book.jpg
The proposed change would be to eliminate the binder's clear front cover pocket, and instead give you an erasable front cover surface like a whiteboard:
http://www.hellotrade.com/c-line-products/self-stick-dry-erase-sheets.html
I've seen that people want to edit the whiteboard directly, rather than pulling sheets out to stick them in the cover.  I think that's because the cover is supposed to describe all of the contents, and individual sheets usually only describe a subset of them.  And consumer 'office stores' now only sell the kind with the whiteboard on the cover.  :)

Are there examples out in the wild where people think in terms of swapping out default 'cover' pages from within the folder (which aren't based on having learned the Plone / web server index.html approach)?


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers



------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
yuri-2 yuri-2
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

Il 08/01/2013 12:12, Anthony Gerrard ha scritto:

> Yes working copies don't really work for folderish types right now.
>  We switch off working-copy behaviour for all folderish types in all
> our Plone implementations.
>
> In a Dexterity implementation we worked around this by having
> folderish types associated with a specific "data" type using a
> standardised id for the data type.  e.g. we had a "country" type and a
> "country data" type and the country data for the country had an id
> "country-data".  We then switched on working-copy behaviour for
> "country data".
>
> It's always felt wrong to me that working copy creates a new object.
>  I have previously worked with Morello, an enterprise level Java CMS.
>  That combines working copy support with versioning which works more
> like source control.  You have a published version of an object.  To
> start editing that you create a new version of the same object that
> isn't published yet - a bit like creating a branch.  Publishing the
> working copy is like merging your branch.  I don't know enough about
> Zope to know whether this is possible with Plone.

ZODB had versioning, and being transactional, you could just "mark" a
certain point in the time for the object as a "version". The problem is
to not delete those transaction when packing, I think.

>
> I can imagine a use case whereby a content author wants to prepare a
> set of content changes that span multiple pages and publish all these
> in one go but in practice I haven't had a request for such a feature.
>
>
>
>
> On 8 January 2013 06:47, Matt Barkau (public) <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>     On Mon, Jan 7, 2013 at 11:45 AM, David Glick (Plone)
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I generally like the idea of making everything folderish, but
>         I have a
>         couple specific concerns:
>
>         a. I think someone pointed out that versioning and/or staging
>         doesn't
>         work as well with folderish items.
>
>
>     Factors in this area include:
>      - Working copies (AKA in-place staging) of folders also copy
>     children
>     <http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html>
>     by default. This preserves default view pages, but wouldn't be
>     needed for an 'everything folderish' Plone.
>      - The working-copied children can contain references to original
>     version items
>     <http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-tp6182294p6183056.html>
>     like inline images, which can be misleading & breakable.
>      - There's no default way to say that you only want to make a
>     working copy of only the parent, and not the children
>     <http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html>.
>      - Working copies of folders just under the site root (containing
>     many children) can be huge, and even time out.
>     <http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-td6182294.html>
>      - Other cousins of folders like form folders probably should copy
>     the children though, so then there has to be clear differentiation
>     between folderish types whose children are working-copied, and
>     those that aren't. Without a clear differentiation, the current
>     situation is
>     <http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html>
>     "...prone to generate extreme frustration with users who expect
>     the *other* behavior."
>
>     So far, I haven't been able to think of a scenario where it would
>     be necessary to make a working copy of an archetypes Folder
>     including its children.  Even if you were redoing a large section
>     (folder) of the site, you usually would not maintain a 1:1
>     correspondence between all old and new pages, so there wouldn't be
>     much benefit to checking in a working copy of an entire folder
>     structure at once.  I don't think there would be enough benefit to
>     warrant the performance hit and complexity, even if everything
>     worked without error, so I'm in favor of versioning & working
>     copies being for the parent (container) only.
>
>     References:
>     http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html
>     http://plone.293351.n2.nabble.com/plone-app-iterate-Why-is-working-copy-support-tied-to-versioning-td7498463.html
>
>     http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-td6182294.html
>
>     http://stackoverflow.com/questions/6457438/how-to-check-in-a-working-copy-if-the-default-workflow-is-plone-workflow-or-intr
>
>     https://dev.plone.org/ticket/7372
>     http://plone.293351.n2.nabble.com/The-checkout-and-check-in-operation-of-plone-iterate-changes-the-folder-sort-order-td6382589.html
>
>     https://dev.plone.org/ticket/12257
>     https://dev.plone.org/ticket/7529
>     https://dev.plone.org/ticket/11906 <-- why was this closed?
>
>         b. Say I have, in current Plone, a folder with a default page
>         and a
>         whole bunch of contained items. Currently, if I decide I want a
>         different type to show up when the root of that folder is
>         shown, it's
>         very easy. If we get rid of the concept of default pages, it would
>         require creating a new item, moving all the contained items,
>         deleting
>         the original item, and then renaming the new item. A couple of
>         those
>         steps would require lengthy reindexing due to the many
>         contained items.
>
>
>     I think that in the 'pages folderish' Plone, you'd teach people a
>     different approach / mental model.  For instance, in the current
>     approach you'd change the default view on /about from
>     /about/our-story to /about/our-mission.  The need could be stated
>     by a user something like, "I originally put all of the success
>     stories under /about/our-story, but now I need to have them under
>     /about/our-mission."  In the 'pages folderish' Plone, you'd
>     instruct the user to select and cut the child pages from under the
>     old location, and paste them into the new location.  The only
>     folks I've seen who don't have an issue learning default view
>     pages are those who've had less experience with something like
>     Wordpress and more experience putting a static index.html in place
>     on a plain web server folder.
>
>     Here's a lame attempt to reify this:
>     The physical analog with folders would be that current Plone
>     folders are like 3-ring binders which let you yank out (or copy)
>     any page and stick it in the clear front cover pocket:
>     http://mychocolatemoments.com/wp-content/uploads/2012/08/lesson-plan-book.jpg
>     The proposed change would be to eliminate the binder's clear front
>     cover pocket, and instead give you an erasable front cover surface
>     like a whiteboard:
>     http://www.hellotrade.com/c-line-products/self-stick-dry-erase-sheets.html
>     I've seen that people want to edit the whiteboard directly, rather
>     than pulling sheets out to stick them in the cover.  I think
>     that's because the cover is supposed to describe all of the
>     contents, and individual sheets usually only describe a subset of
>     them.  And consumer 'office stores' now only sell the kind with
>     the whiteboard on the cover.  :)
>
>     Are there examples out in the wild where people think in terms of
>     swapping out default 'cover' pages from within the folder (which
>     aren't based on having learned the Plone / web server index.html
>     approach)?
>
>
>     ------------------------------------------------------------------------------
>     Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
>     and more. Get SQL Server skills now (including 2012) with
>     LearnDevNow -
>     200+ hours of step-by-step video tutorials by Microsoft MVPs and
>     experts.
>     SALE $99.99 this month only - learn more at:
>     http://p.sf.net/sfu/learnmore_122512
>     _______________________________________________
>     Plone-developers mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/plone-developers
>
>
>
>
> ------------------------------------------------------------------------------
> Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
> and more. Get SQL Server skills now (including 2012) with LearnDevNow -
> 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
> SALE $99.99 this month only - learn more at:
> http://p.sf.net/sfu/learnmore_122512
>
>
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
c.ledermann c.ledermann
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

I think  the gist of this discussion is:

> I think most people feel the same way and the plan is to make everything folderish with deco.

1) folderish content types is generally thought of as a good idea

>
> see https://github.com/plone/buildout.deco/blob/master/docs/faq.rst#what-happens-to-content-types
>
> The deco concepts are elegant and simplify many things, not just folders.
> I think that given any major UI change takes a lot of effort and testing deco
> is better bang for our buck than just introducing the everything-folderish part by itself.
>

The UI for folderish content types should be the same as the classical
content types we have now. Additional views for folder listings for these types
can be left to 3rd party add ons.


> When Deco is installed, it adds a new type in portal_types called, simply, page.
> This is a Dexterity content type that uses the ILayoutAware behaviour to manage
> page- and section-specific site layouts as well as the Deco page layout itself.
>
> File, which should handle both files and images, making image operations and
> behaviours available when dealing with a binary of an image MIME type.

 2) With Deco all content will be folderish, the Deco Page is a
Dexterity content type.

>>      - Working copies (AKA in-place staging) of folders also copy
>>     children

>> Yes working copies don't really work for folderish types right now.
>>  We switch off working-copy behaviour for all folderish types in all
>> our Plone implementations.

3) Working copies don't work well for folderish types right now.

>>     I think that in the 'pages folderish' Plone, you'd teach people a
>>     different approach / mental model.

4) Folderish contentypes are a different approach from a content
managers perspective, It requires a certain amount of learning,
unlearning, relearning

My conclusion:

People like the idea (1)
With Deco content will be folderish anyway (2)

There are some challanges which have to be solved to make
'everything folderish' mainly (3) on the technical side and (4) for
the end user.

I think all of the above make a good point to start now with the
transition from Archetypes to Dexterity contentypes to make all
types folderish.

My reasoning:

If (3) is not tackled now it will be left until the advent of deco
where it might turn out to be a major hold up. Not to be able
to have working copies in certain situations will be a deal breaker
for many people when it comes to the adoption of deco

End users will get used to (4) so the learning
curve to deco will be easier


As an aside:
Maybe the transition ATCT to Dexterity CT would also
be an opportunity to to unify the Image and File implementation
so that has not to be done when Deco arrives

> There is work underway in finishing deco but it needs more time and people.
>

Yes I understand this fully and I see the move to folderish
content types more as a stepping stone into the direction of deco
than taking resources away from it


--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
Dylan Jay Dylan Jay
Reply | Threaded
Open this post in threaded view
|

Re: folderish collections, contenttypes and dexterity

In reply to this post by AnthonyG


On 09/01/2013, at 12:12 AM, Anthony Gerrard <[hidden email]> wrote:

Yes working copies don't really work for folderish types right now.  We switch off working-copy behaviour for all folderish types in all our Plone implementations.

In a Dexterity implementation we worked around this by having folderish types associated with a specific "data" type using a standardised id for the data type.  e.g. we had a "country" type and a "country data" type and the country data for the country had an id "country-data".  We then switched on working-copy behaviour for "country data".

It's always felt wrong to me that working copy creates a new object.  I have previously worked with Morello, an enterprise level Java CMS.  That combines working copy support with versioning which works more like source control.  You have a published version of an object.  To start editing that you create a new version of the same object that isn't published yet - a bit like creating a branch.  Publishing the working copy is like merging your branch.  I don't know enough about Zope to know whether this is possible with Plone.

I can imagine a use case whereby a content author wants to prepare a set of content changes that span multiple pages and publish all these in one go but in practice I haven't had a request for such a feature.

We've had a request for such a feature. 






On 8 January 2013 06:47, Matt Barkau (public) <[hidden email]> wrote:


On Mon, Jan 7, 2013 at 11:45 AM, David Glick (Plone) <[hidden email]> wrote:
I generally like the idea of making everything folderish, but I have a
couple specific concerns:

a. I think someone pointed out that versioning and/or staging doesn't
work as well with folderish items.

Factors in this area include:
 - Working copies (AKA in-place staging) of folders also copy children by default. This preserves default view pages, but wouldn't be needed for an 'everything folderish' Plone.
 - The working-copied children can contain references to original version items like inline images, which can be misleading & breakable.
 - There's no default way to say that you only want to make a working copy of only the parent, and not the children.
 - Working copies of folders just under the site root (containing many children) can be huge, and even time out.
 - Other cousins of folders like form folders probably should copy the children though, so then there has to be clear differentiation between folderish types whose children are working-copied, and those that aren't.  Without a clear differentiation, the current situation is "...prone to generate extreme frustration with users who expect the *other* behavior."

So far, I haven't been able to think of a scenario where it would be necessary to make a working copy of an archetypes Folder including its children.  Even if you were redoing a large section (folder) of the site, you usually would not maintain a 1:1 correspondence between all old and new pages, so there wouldn't be much benefit to checking in a working copy of an entire folder structure at once.  I don't think there would be enough benefit to warrant the performance hit and complexity, even if everything worked without error, so I'm in favor of versioning & working copies being for the parent (container) only.

References:
http://plone.293351.n2.nabble.com/RFC-plone-app-iterate-copier-behaviour-for-folders-td2522621.html
http://plone.293351.n2.nabble.com/plone-app-iterate-Why-is-working-copy-support-tied-to-versioning-td7498463.html
http://plone.293351.n2.nabble.com/Iterate-check-out-large-folder-has-painful-performace-td6182294.html
http://stackoverflow.com/questions/6457438/how-to-check-in-a-working-copy-if-the-default-workflow-is-plone-workflow-or-intr
https://dev.plone.org/ticket/7372
http://plone.293351.n2.nabble.com/The-checkout-and-check-in-operation-of-plone-iterate-changes-the-folder-sort-order-td6382589.html
https://dev.plone.org/ticket/12257
https://dev.plone.org/ticket/7529
https://dev.plone.org/ticket/11906 <-- why was this closed?

 
b. Say I have, in current Plone, a folder with a default page and a
whole bunch of contained items. Currently, if I decide I want a
different type to show up when the root of that folder is shown, it's
very easy. If we get rid of the concept of default pages, it would
require creating a new item, moving all the contained items, deleting
the original item, and then renaming the new item. A couple of those
steps would require lengthy reindexing due to the many contained items.

I think that in the 'pages folderish' Plone, you'd teach people a different approach / mental model.  For instance, in the current approach you'd change the default view on /about from /about/our-story to /about/our-mission.  The need could be stated by a user something like, "I originally put all of the success stories under /about/our-story, but now I need to have them under /about/our-mission."  In the 'pages folderish' Plone, you'd instruct the user to select and cut the child pages from under the old location, and paste them into the new location.  The only folks I've seen who don't have an issue learning default view pages are those who've had less experience with something like Wordpress and more experience putting a static index.html in place on a plain web server folder.

Here's a lame attempt to reify this:
The physical analog with folders would be that current Plone folders are like 3-ring binders which let you yank out (or copy) any page and stick it in the clear front cover pocket:
http://mychocolatemoments.com/wp-content/uploads/2012/08/lesson-plan-book.jpg
The proposed change would be to eliminate the binder's clear front cover pocket, and instead give you an erasable front cover surface like a whiteboard:
http://www.hellotrade.com/c-line-products/self-stick-dry-erase-sheets.html
I've seen that people want to edit the whiteboard directly, rather than pulling sheets out to stick them in the cover.  I think that's because the cover is supposed to describe all of the contents, and individual sheets usually only describe a subset of them.  And consumer 'office stores' now only sell the kind with the whiteboard on the cover.  :)

Are there examples out in the wild where people think in terms of swapping out default 'cover' pages from within the folder (which aren't based on having learned the Plone / web server index.html approach)?


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers


------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
12