Yes DataObjects are easier for things you may not want to display or search and work nicely with the built in hasmany/manymany/etc, however despite the advantages SilverStripe has some issues with some end uses of pure DataObjects as opposed to pages...

1. They are not searched - AFAIK the default search engine only does pages & files and only Title and Content

2. You can't just display them you have to get into rendering via some other object, usually via a 'show' function in the PageController of some holder object or class.

3. They become pain to edit as they aren't handled by the CMS as a page is - usually the odd wee javascript shadow box which breaks the useful things like the HTMLEditorField and so on.

(O:

defining your own getCMSFields in a decorator: http://doc.silverstripe.org/dataobjectdecorator#modifying_cms_fields

*facepalm* Oh, right, yes I remember now. Worse... I've used the same thing myself in this very module! Too many late nights (O: Thanks. Now I'll have to do something about it.

There we go then... 0.27 with child pages showing the list of the parent's child pages (i.e. its peers) to assist navigation if parent is doing a hidepages.

[[ FILE REMOVED AS LATER (2.4.2 Compatible Checked) VERSION BELOW ]]

Yes it does nest (child of page hiding children also hides its children) but hiding the first level of pages will make creating a new child in the 2nd level a bit tricky without an add button as you don't see the child in the tree to do a Create in the CMS on (O: However that's by the by and the original intention to cut off the CMS tree at that point works fine. Not to mention that, not seeing the tree from the first page you defined hide on makes the second hide a bit redundant except that I suppose it does provide a navigation aid if you are silly enough to have more than one level under the main hide.

Re this last remark (hiding pages below hidden pages) you can define different tab names for the child tab of the current and the child tab of the parent to separate them (i.e. both the default of children) however if they are the same (e.g. both default of 'children') then, in the child page's 'children' tab, it puts both list with the list of this child's own children first.

Would still like to suss the many-many simply because it looks nicer re navigation. I recall doing it successfully in modules created since this one for other pages that have pages as children. Never mind... onwards.

BTW before you give me pointers on the basics of the has/manymanycomplex table field I was referring to above I have used it quite successfully with objects class DataObject, but in early experiments found it a bit awkward to wrangle objects of class SiteTree and its children (Pages, etc) from as I believe there is a need for a reciprocal 'is one of many' in the targeted object. Or perhaps I was a bit confused as to which of the controllers was acting as the reference.

First of all awesome work in trying to tackle this!

It has been a pet peeve of mine pretty much from the get go that administrating news intensive sites gets really hard since the Sitetree fills up so fast. As far as I know complextablefield assumes that there's some kind of relationship involved but if I'm correct, TableListField doesn't so you might be able to use that for a listing.

Getting the admin of pages to work properly might be a huge hassle though, I think alot of assumptions are being made about how/where the page is being administrated. I'll be trying out your code and see if I can help in any way. Getting something like this up and running 100% would be huge.

Thanks much Smurkas, I'll be interested to see what someone who know what they are doing can make of it (O: Oddly enough I'm not too concerned about the functionality of the child pages lists as they do what is needed - edit and view. But it will probably need the bit of filtering code updated at some point - per dio5's updated method or similar.

As I keep saying... the amount of pages generated by news and blogs really inspire a desire to get more Page-like support for DataObjects. IMO DataObjects are definitely a better way to go for this sort of bulk item.

See attached snaps of the admin side of a DataObject based (no HidePages) News and Events module I made up for the Department. As you might imagine from the choices for HidePages it has a reasonably adaptable set of options for display of news in a variety of ways and groupings as well as good support for templates to access articles. If only I could work out why it sometimes orphans the articles (O: It has no calendar display yet despite the checkbox to enable it.

See News and Events in action at at infosci.otago.ac.nz both on the front page (events & recent news) and the News and Events Pages. The only thing it does not have is a proper editor as (previously mentioned) the HTMLEditorField does not work in the javascript pop-up. But it will be nicer to have a form that users can use to Post or Edit news without having to go into the CMS anyway.

Woohoo, and now to break my development site with an upgrade to 2.4.2... I guess I'll soon find out if HidePages works with it... and everything else I've hacked up.

Ouch... should still work with 2.4.0 but have discovered some odd behaviour with 2.4.2 - it creates the bogus ParentID in page... which makes no sense. However I have almost found the cause... in the _config and object::add_extension. Hmmm

And yes the answer is that the add_extension to the Hierarchy object causes SS to create the index. Will sort this and we'll be sweet.

[[ V0.28 REMOVED - V0.27 IS VALID AND ON LATER POST ]]