Default view for CMSMain

[Uncle Cheese]

One of the best things that I thought SS3 was going to deliver was the deprecation of the site tree. But alas, it didn't go through as much as I had hoped, and the site tree is still very much a dominant fixture in CMSMain.

I get tired of having to switch tabs to list view every time. I wonder if we could provide an API for the default view?

Fortunately, there's a very easy workaround. Just override the template and reverse the order of the tabs so that listview is first.

Clean, but not ideal, right?

[Sigurd Magnusson]

Only part of the solution - but what about a cookie setting to remember the last viewed state so that future times in the CMS use the listview by default?

Sig

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/JFydDxisNEIJ.
To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

--

Sigurd Magnusson

Business Relationship Manager

SilverStripe

DDI: +64 4 978 7332

Mobile: (NZ): +64 21 42 12 08

Skype: sigurdmagnusson

twitter.com/SigurdMagnusson

www.silverstripe.com

[Nicolaas Thiemen Francken - Sunny Side Up]

On 22 August 2012 13:52, Sigurd Magnusson <sig...@silverstripe.com> wrote:

Only part of the solution - but what about a cookie setting to remember the last viewed state so that future times in the CMS use the listview by default?

Sig

+1
- personalised

- less work (things to think about) for developers

 

[Sigurd Magnusson]

Other thing to know is that Hamish and I discussed a bug which should be coming soon (3.0.2) which will improve the speed and scalability of trees loading. Also there's a pull request already destined for 3.0.2 to add an [Add New] page while in List view.

@Uncle - what size/structure of trees cause you pain? Can you paint a picture of the number of nodes and how nested they are and how how many direct children on a node you're dealing with? 

Sig

 

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

[Ingo Schommer]

Hey Aaron,

Clientside tab persistence is already implemented,

have a look at saveTabState() and restoreTabState() in LeftAndMain.js.

The problem is just that it's restricted to ajax panel requests,

not full page loads. So if you select the "list" tab in admin/pages,

navigate to a page edit form, then navigate back to admin/pages,

it already reselects the list tab.

So we need to call restoreTabState() on initial rendering (probably in the main redraw() method),

and call saveTabState() whenever a tab is selected, rather than on ajax requests only.

Keen to give it a go?

[Uncle Cheese]

@Sig - In my experience the site tree metaphor doesn't scale beyond simple brochureware. As soon as you have nodes that contain more than 20-30 pages, things get really cumbersome because you're dealing with a single all-inclusive list, and most of the real estate in that narrow panel has already been sold off to parent and peer nodes that you don't care about.

If you have a calendar located at /about-us/company/events, and you have 200 events in the database, it's a punishing experience for the client to go in and add an event, or update an existing one.

The list view mitigates these issues to some extent. There's still a lot of digging to do, but at least it all happens cleanly, one paginated section at a time without all the extra noise. Further, for updates, a client can simply sort the table by last updated, and bring those pages to the top.

A bit off-topic, but an ideal solution to this is to provide a "dashboard" API that would bring common tasks to the top of the CMS. IMO, for a company that uses the CMS mostly for event management, "Create an Event" should never be more than two clicks away, and the inherent problem with the site tree model is that it's just too focused on hierarchy rather than content.

@Ingo - Does the client side storage persist across sessions? I think that's my biggest gripe is that every time I log in, I get the site tree, and for a user like myself, or my clients, it's just a useless view. I'd be happy to take a crack at it either way. Entwine rocks my world.

[Ingo Schommer]

On 22/08/2012, at 4:18 PM, Uncle Cheese <aaronc...@gmail.com> wrote:
>
> @Ingo - Does the client side storage persist across sessions? I think that's my biggest gripe is that every time I log in, I get the site tree, and for a user like myself, or my clients, it's just a useless view. I'd be happy to take a crack at it either way. Entwine rocks my world.

No it doesn't, although that should be as simple as replacing "sessionStorage" with "localStorage" in the JS :)

[Uncle Cheese]

Actually, it's kind of a moot point now because I just realized there's no way to add a page in list view. Why, oh why?

[schellmax]

sorry for the interruption, but unclecheese's thoughts on the sitetree exactly met with what we were recently taking about in my company, when evaluating silverstripe 3 for a big upcoming project.

we've switched to modeladmin wherever possible, but the biggest hurdle there is to allow for some custom sorting (by hand) for the managed objects.

in fact, reordering in the sitetree too is quite cumbersome when dealing with 100+ pages; i've proposed a solution to this here:

http://open.silverstripe.org/ticket/7778

would be interesting to get some feedback on this - i'd be eager to try implementing this (as soon as i'm familiar with all of this git stuff)

[swaiba]

On Wednesday, August 22, 2012 3:18:55 PM UTC+1, Uncle Cheese wrote:

If you have a calendar located at /about-us/company/events, and you have 200 events in the database, it's a punishing experience for the client to go in and add an event, or update an existing one.

I know this isn't the answer you are looking for - but this could be solved by leaving "Page" as "Page" and storing "Event" in a separate DataObject that is managed in ModelAdmin.

I've never followed why people blur what a page is (e.g. event calendar, eCommerce, etc) - I must be missing something because I run across it in other website (custom built) that I migrate into our software - I've always keep "business logic / controller" and associated data in ModelAdmin separate from pages and presentation data in the sitetree.  there are some minor areas where I store some presentation data on the data objects - but this is normally name and brief description only.

[Uncle Cheese]

I try to use ModelAdmin whenever possible, but that approach is challenged by several major shortcomings:

- Versioning

- Creation and rendering of meta tags

- URLSegment generation

In addition, you have to build all the controller logic that ContentController gives you out of the box. It's just way too much work for a client who just wants to write a daily blog without having to fight with a site tree.

[Dan Rye]

UC, to answer your Why, Oh Why... it's coming. Quoted from Sig, "Also there's a pull request already destined for 3.0.2 to add an [Add New] page while in List view."

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/ZsgPak4qU4IJ.

[Uncle Cheese]

Haha... Whoops. Sorry, I swear I didn't mean to TLDR you, Sig.

[Sigurd Magnusson]

1. 

No worries UC, and I'm sure we'd be open to people thinking about and considering how to bring across the batch actions too. It seems to me that we need a half dozen small tweaks, e.g. remembering Listview state across pages, to get us most of the way there. In addition, having an initial screen to "add a page of type X under page Y" would help the bloggers etc vastly, and I wonder if a GET query already supports this? (i.e. psudeocode: /pages/add/?type=X&parent=Y"

2.

An alternative to the dashboard that is more integrated into the current interface would be

a) to provide "Frequently added pages" to /admin/pages/add

and/or

b) to provide a drop down arrow to the right of [Add New] on the tree/list view, which provides a list like [New Blog Post] and [New Staff Biography] and which directly create a page of a certain type in a specific location. 

I can see this being good because then you get the benefit of speed and you don't have to return to the dashboard to repeat the activity. You'd express somehow in code these commonly added page flows.

Example of 2b attached as screenshot.

3. 

@schellmax, regarding http://open.silverstripe.org/ticket/7778: your idea to "Cut" and [paste] "Insert Above" / "Insert Below" (or even Insert Inside) as right click context menu items on pages is a pretty good idea, and from my perspective, the sort of thing we'd accept as a pull request. (It could be a good idea to have Insert greyed out, but visible below Cut so that the user can learn how to use the feature.)

Sig

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/yP4vFNwclUUJ.

[swaiba]

points taken

Even with those reasons it still makes more to seperate them - just because object A has some stuff object B would like it doesn't mean you merge the two objects.

I much dislike the versioning structure for silverstipe - using multiple tables for something that should be within one table - Harder to get under the hood and fix the data when things go wrong (which they do with class names, pages deleted, etc).  

If versioning of data was raised by clients (it hasn't been for 3 years in my case - except for deletions) I plan to implement versioning where all objects have opening and closing effective dates and the objects SQL is augmented with selecting the record for now() in normal cases.  The onafterwrite updates the previous record to be closed now() and the new one to have start now() and close of 1/1/2030.  Currently we have a slightly cruder version of this "versioning" and provide full audit logging on required objects.  Often when things have changed a complete rollback of the data isn't the right solution anyway - normally just one item is set to an older value if changed in error.

Is there a way to find out how many times page rollback has been used? I'd be curious how many times our clients have used it (my guess is very few)  I do get asked to restore pages that are deleted from time to time - .

This may be going off topic and since I don't have the actual code for the versioning replacment suggestion I'll not start a new thread

[Michael van Schaik]

I'm currently building a site with a comparable approach, a GridField to
manage subpage-items which tend to be used more as a database than as
hierarchical pages (e.g. a few hundred subpages under one page). Instead
of DataObject, these pages extend the Page class and thus inherit its
controller logic. I hide them from the sitetree with an extension of the
Hierarchy class.

I just separated the code I wrote/adapted to prevent these pages from
showing up in the sitetree into a module, my first... Looking forward to
any feedback and/or problems people foresee with this approach:

https://github.com/micschk/silverstripe-excludechildren

Oh, if anyone knows of a way to have the page's edit form appear with
the normal Settings & History tab included, that'd be awesome!

> --
> You received this message because you are subscribed to the Google
> Groups "SilverStripe Core Development" group.

> To view this discussion on the web visit

> https://groups.google.com/d/msg/silverstripe-dev/-/ZsgPak4qU4IJ.

[Paul Clarke]

Hey Sig, there is another discussion about your point #2 here and a screen shot of what I proposed which is here, I don't see why this can't be available on the list view as well.