ss3 // Data Grid

[Ingo Schommer]

Hello everybody,

The SilverStripe 3 design relies heavily on list and gallery views to manage

data efficiently, for example in a new "Pages" list, ModelAdmin, or the "Files" area.

Here's a selection of our designs to illustrate this:

https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_files-manager-list-view.jpg

https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_files-manager-gallery-collapsed.jpg

https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_model-admin.jpg

https://github.com/silverstripe/silverstripe-design/blob/master/Design/ss3-ui_pages-list-view.jpg

In the past, we've handled these views through TableField, TableListField, ComplexTableField,

HasManyComplexTableField, ManyManyComplexTableField etc., 

with specialized subclasses like AssetTableField or MemberTableField.

Many of you have also extended this featureset through third party modules like DataObjectManager.

Since these core UI components were created in 2.1 and 2.2, SilverStripe has evolved:

We now have field scaffolding (used in ModelAdmin), a more flexible ORM,

and a built-in abstraction for searching. In addition, other web infrastructure has evolved as well:

Webservices are widely available, and new clientside libraries allow for sophisticated UI controls.

We've also learned a bit about API design, and think we can do better than half a dozen subclasses

but across fairly arbitrary feature concerns. The result of this API redesign will be a new base field called "DataGrid", 

existing classes will be removed from core. They might be useable in 3.0 as a module.

Sam has already started to clean up the fields in the "new-orm" branch:

https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableListField.php

https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableField.php

https://github.com/silverstripe/sapphire/blob/new-orm/forms/ComplexTableField.php

To get the discussion going, I've started a wiki page which outlines 

some highlevel goals, as well as potential features.

http://open.silverstripe.org/wiki/development/DataGrid

This is a massive chunk of work, and a crucial component in getting SilverStripe 3 out of the door.

I'll be in touch with Aaron Carlino, the author of DataObjectManager, 

to draw on his experience with extending the existing core components,

and providing feedback as a deeply involved community member.

Of course we're also looking to others in the community for help -

please let us know what aspect of the development you'd be most interested in.

Grüße

Ingo

---

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

in...@silverstripe.com

Phone: +64 4 978 7330 x 42

Skype: chillu23

[Uncle Cheese]

Thanks for getting this started, Ingo.

The CMS Expo was a great kickoff to the DataGrid pre-production
process. We talked about a lot of different ideas and challenges.
Ultimately we want something very clean, extensible, and re-usable.
The key challenge is that DataGrid will be used in so many different
contexts..

- The "list view" for pages
- ModelAdmin
- For managing components on pages
- AssetAdmin
- SecurityAdmin

What we don't want is another massive and unmanageable inheritance
chain, like we have with CTF and DOM. Ideally, the DataGrid component
is flexible enough to take on different contexts without needing
heroic levels of overloading and subclassing.

In terms of features, here's what we came up with in our meetings:

1) To popup or not to popup?

- Popup has limitations. If managing a big record, you have very
limited real estate and it can get dodgy. It's also pretty slow for
editing multiple records.

- Proposed alternative: Swiping the grid to the left to expose an edit
form for the detail view, and providing breadcrumbs for getting back
to list view. This will be especially useful for nested DataGrids,
since it will allow unlimited traversal of relationships without the
UI constraints (popup in a popup in a popup ??!?!?!?)

- Inline editing is a must. Will be defined on the column as an
option.

- Proposed solution: There are three interfaces for editing/creating a
record.
1) Inline -- for small records.
2) Popup -- for medium sized records
3) Swipe -- for large records

We propose the DataGrid make this decision intelligently by
introspecting its source class. It will be an override in the API, as
well. Inline editing should always be an option, because even on large
records, sometimes you just want to update one field really quickly.


2) Columns

Drag-and-drop will be available on only small data sets, because you
don't have to deal with the page fold. (Question: How do we do this?
Does every dataobject have a Sort field now? Or do we continue with
the decorator pattern, i.e. SortableDataObject?)

No column sorting when drag-and-drop is on.

Columns should be intelligent objects, rather than dumb arrays as they
are now. Columns can take on widths, toggle their sort, render an
inline edit form, etc.


3) Filters

- All filters need a "reset" button. "Reset all" is not enough. When a
user gets a null set, that is a huge point of frustration, so we want
to give them a quick "out" by opening up their filters. We used
priceme.co.nz as an example.

- Filter by tag seems over-engineered. It looks like this UI is
creating and managing tags, but searching by tag is just a keyword
search. It appears that this widget does not belong in the UI for
DataGrid.

- There should be a global search for the whole grid.

- "Add" button does not need to be context aware since the grid has a
title. (In DOM we had setAddTitle() to customize the "add" button
display)


4) Actions

- Top checkbox should ask whether you want all on the page, or all
records in the unlimited set.

- We need to allow custom actions. I should be able to create a
DataGridAction for, say, "Import to my CRM" which would hit a user-
created controller that handles the post of all the selected IDs and
returns custom messaging on success or error

- "Edit" should be a bulk action. There are two ways to handle this:

a) Edit "stack" would function like iTunes. Make an update to one
record (e.g. change the album name) and it affects all records
selected.

b) Edit "queue" would queue up all the records for edit and walk you
through them in the edit view. Clicking "save" would advance you to
the next record in your queue.



That's all I got for now!

On May 6, 11:49 pm, Ingo Schommer <i...@silverstripe.com> wrote:
> Hello everybody,
>
> The SilverStripe 3 design relies heavily on list and gallery views to manage
> data efficiently, for example in a new "Pages" list, ModelAdmin, or the "Files" area.

> Here's a selection of our designs to illustrate this:https://github.com/silverstripe/silverstripe-design/blob/master/Desig...https://github.com/silverstripe/silverstripe-design/blob/master/Desig...https://github.com/silverstripe/silverstripe-design/blob/master/Desig...https://github.com/silverstripe/silverstripe-design/blob/master/Desig...

>
> In the past, we've handled these views through TableField, TableListField, ComplexTableField,
> HasManyComplexTableField, ManyManyComplexTableField etc.,
> with specialized subclasses like AssetTableField or MemberTableField.
> Many of you have also extended this featureset through third party modules like DataObjectManager.
>
> Since these core UI components were created in 2.1 and 2.2, SilverStripe has evolved:
> We now have field scaffolding (used in ModelAdmin), a more flexible ORM,
> and a built-in abstraction for searching. In addition, other web infrastructure has evolved as well:
> Webservices are widely available, and new clientside libraries allow for sophisticated UI controls.
>
> We've also learned a bit about API design, and think we can do better than half a dozen subclasses
> but across fairly arbitrary feature concerns. The result of this API redesign will be a new base field called "DataGrid",
> existing classes will be removed from core. They might be useable in 3.0 as a module.
>

> Sam has already started to clean up the fields in the "new-orm" branch:https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableList...https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableFiel...https://github.com/silverstripe/sapphire/blob/new-orm/forms/ComplexTa...

>
> To get the discussion going, I've started a wiki page which outlines

> some highlevel goals, as well as potential features.http://open.silverstripe.org/wiki/development/DataGrid

>
> This is a massive chunk of work, and a crucial component in getting SilverStripe 3 out of the door.
> I'll be in touch with Aaron Carlino, the author of DataObjectManager,
> to draw on his experience with extending the existing core components,
> and providing feedback as a deeply involved community member.
> Of course we're also looking to others in the community for help -
> please let us know what aspect of the development you'd be most interested in.
>
> Grüße
> Ingo
>
> ---
> Ingo Schommer | Senior Developer
> SilverStripehttp://silverstripe.com

> i...@silverstripe.com

[netefx - Alexander Klein]

Hi,

I edited a SS3 screenshot to explain what i would like to see in the
datagrid.
2 kinds of custom actions and an idea how to display the edit form.
http://www.tiikoni.com/tis/view/?id=8ba4fab

Regards,
lx

2) Columns

3) Filters

4) Actions

--
You received this message because you are subscribed to the Google Groups
"SilverStripe Core Development" group.
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.

[Uncle Cheese]

Thanks, Alexander!

For the inline actions, I was imagining this as well, but I think I
overlooked it because it's already part of DOM, so it's not really in
my head. Have you had a chance to look at the API for adding custom
actions to DOM? I kind of like the way it's designed, and it's one of
the few things I'm somewhat proud of in the DOM codebase. Each action
is an object and can take a variety of popup behaviours and connect to
arbitrary controllers.

The edit form below the table does not seem very usable to me. All of
that scrolling seems like far too much work, and it just seems a
little awkward, but I'd be curious to hear what others think.

On May 9, 7:42 am, "netefx - Alexander Klein" <al...@netefx.de> wrote:
> Hi,
>
> I edited a SS3 screenshot to explain what i would like to see in the
> datagrid.

> 2 kinds of custom actions and an idea how to display the edit form.http://www.tiikoni.com/tis/view/?id=8ba4fab

> ps://github.com/silverstripe/silverstripe-design/blob/master/Desig...https://github.com/silverstripe/silverstripe-design/blob/master/Desig...

>
> > In the past, we've handled these views through TableField,
> > TableListField, ComplexTableField, HasManyComplexTableField,
> > ManyManyComplexTableField etc., with specialized subclasses like
> AssetTableField or MemberTableField.
> > Many of you have also extended this featureset through third party modules
> like DataObjectManager.
>
> > Since these core UI components were created in 2.1 and 2.2, SilverStripe
> has evolved:
> > We now have field scaffolding (used in ModelAdmin), a more flexible
> > ORM, and a built-in abstraction for searching. In addition, other web
> infrastructure has evolved as well:
> > Webservices are widely available, and new clientside libraries allow for
> sophisticated UI controls.
>
> > We've also learned a bit about API design, and think we can do better
> > than half a dozen subclasses but across fairly arbitrary feature
> > concerns. The result of this API redesign will be a new base field called
> "DataGrid", existing classes will be removed from core. They might be
> useable in 3.0 as a module.
>
> > Sam has already started to clean up the fields in the "new-orm"
> branch:https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableList
> ...https://github.com/silverstripe/sapphire/blob/new-orm/forms/TableFiel...

[Hamish Friedlander]

Hi Guys,

Some good discussion here. Just some comments:

---------- Design ----------

- The base level needs to work without javascript so it can be used in the front-end

- The DataGrid field component isn't just used in ModelAdmin, and it's important to seperate the concept of the DataGrid field from how it's used in ModelAdmin - it's also used in other places in the CMS (the page list view for eg), and in the front end too. This probably boils down to: don't specify what the actions are or how they work in DataGrid, that's up to whatever uses it.

- I disagree that inline editing is a must - do you have a use-case where it's required? If we do add it, it'd have to be for very simple types only - no HTMLText fields or images or relationships. Additionally, a lot of the columns in many *TableField instances are calculated (summaries, etc) so it wouldn't be possible to edit them.

- I think / agree that the action should be able to configure the mode switch itself, because depending on the action you might want:

  * No new form, just a message saying the action was performed (for eg delete)

  * Popup form, for where you need to collect some information prior to performing an action (but hard limit: no DataGrids inside popups)

  * New edit form with back button in place

  * Go somewhere else entirely, possibly with a back button to take you back to the DataGrid

- Something that's handled very badly by the current *TableField fields is relationship management. Specifically, adding an existing item into a relationship and creating a new item to add to a relationship are different things. Sometimes when adding an existing item we just want checkboxes, sometimes there's enough items to need a search box

This is also another point where DataGrid needs to be separate from ModelAdmin. In ModelAdmin you're just editing _all_ the records of a certain type, but the *TableFIelds are also used heavily for this sort of has_many / many_many editing interface

- (CMS specific) In the page list view, the actions will take you to another location in the CMS (the content edit form), and when Felipe and I were discussing it, we think that generally clicking a link should take you to another place that it's ideally possible to navigate to directly.

A specific example of this might be where you've got pages that show information derived from some particular model (a Forum member profile for example) - ideally, you'd be able to edit this the same was as editing the content of a page, navigating to the page in the front end, then clicking the "edit this member" button to popup the edit form for that particular record. It'd also be good 

There's a lot more of the "tie preview into admin nicely" that we're probably better off thinking about later to keep things simple. This is things like: should a model admin default to filtering to the contents of the relationship of a page (HomePage has_many PromoNuggets, browsing to homepage in front end then clicking the "PromoNuggets Admin" edit button on the left starts by showing a list of all the PromoNuggets)

- It's important to make sure Felipe agrees with any UI decisions we make - he's the guy who ultimately is in charge of keeping the backend UI both user focused and coherent

---------- Backend architecture ----------

It'd like to consider using jsonpath or maybe even jsonquery as the interface between DataGrid and PHP. It should be fairly possible to convert it to SQL, and it gives us a good "serializable state" of the DataGrid so that we can easily manage history navigation, etc.

The "no javascript in the base" rule means that results needs to be returnable as an html lump (probably a whole page so we can stick the field in an iframe) , but we could use a header to indicate we want it returned as json instead for the javascript enhancement layer.

Hamish Friedlander

[Chris Bull]

Hamish, why no javascript? As far as I'm aware the number of people
browsing without JS these days is quite minmal (from my own sites,
which are hardly high traffic). It seems like going down that route
would be a lot of hassle and would miss out the opportunity to use
current JS and front-end best practices?

Chris.

On May 10, 9:20 am, Hamish Friedlander <ham...@silverstripe.com>
wrote:

[Hamish Friedlander]

No javascript _requirement_. We'd like to have as much as practical work without javascript, and then have additional features layered on top.

The primary reason is to avoid library lock-in. If all our form fields require jQuery to operate you have to have jQuery included in your front end to use the form system. We're in exactly that situation now with 2.4, where most of our projects use jQuery on the front end but if we use many of the form fields prototype ends up getting included too, which for bandwidth and styling consistency reasons is pretty ugly.

So the plan is to keep all the jQuery specific form field code in a submodule. It should be possible to remove that submodule and have the form fields still work (although in a reduced state - a date picker would become a straight text field for example). Some form fields and/or features will simply not work without javascript, but keeping the separation as clean as possible will make moving to some different third party library much less difficult. 

We also do have clients that require their sites to operate without javascript - either for regulatory, accessibility, internal policy or personal taste reasons. We'd like the front end to not preclude any browser or device (IE6, mobiles, no javascript, etc) as much as possible. For example it'd ideally be possible to replace the jquery form field support layer with a jquery-mobile one. That's not something we're looking at including in 3.0, but it is an item on the future version wishlist.

In the case of the data grid, probably the basics will work (filtering, sorting, actions), but most of the more complex stuff won't (reordering of items, forms in pop-ups, inline editing, etc). Where exactly the line lies depends on technical constraint and time considerations

Hamish Friedlander

[netefx - Alexander Klein]

Sorry that i didnt answer earlier.
Good that different kinds of custom actions will be available!

To be honest, i checked the DOM in an early version and had some problems to
get it running properly. I also noticed, that the editing form is always in
a popup and the tinyMCE isnt available. So thats why i decided not to use
the DOM.
Maybe i should have given him a second chance. :)

Anyway, i just noticed a shortcoming in ModelAdmin, which could be improved
in DataGrid. ModelAdmin can export your data to csv by default. But the
fields are always the same that are defined as columns in CMS. Both are
defined with $summary_fields. But it should be possible to export more or
different fields. (maybe a $export_summary_fields).

[Zauberfisch]

blubb

I use DOM and ModelAdmin a lot and often in a very advanced way.

some problems I have been facing so far without finding a clean
solution.
So let me just throw in some ideas that I had, and things I would love
to see in the data grid:

- option to set how to filter or search
lets say, I have a function that returns a string from an external
API.
I can easily display it by giving the function name to the headings
array of the CTF/DOM, but when it gets to filtering or sorting, I have
not found a solution to go around sub classing and hacking yet.
so my idea would be, a option to set how the sort/filter should be
performed.
idk, something like this:
$ctf->setDefautSortAndFilterMethod($method);
$method could be "sql", meaning the CTF will perform it by simple
WHERE and ORDER BY
or it could be "php", and it will loop through the objects in php
maybe even "js" to have it done in the browser, in case it is needed/
wanted to have it done without touching the server again

- search/filter by relations (yes I am aware of $DOM->setFilter(), but
it should be possible to search in relations and such)

- actions on multiple rows (check box and a "do something with
selected rows" button)

- actions on single row
I used DOM and the featured UC talked about, well, I got it working
with a lot of hacking.
it was a pain getting different actions to do different things (open a
different pop-up and such)


- in-line edit, should be in it, and more then a basic text field
(drop-down, date-field, check box, ... shouldn't be to hard)
some clients don't like the huge pop-up, so maybe the simple fields in-
line, fields like HTMLEditorField in a small pop-up?

- edit in the row by sliding down a edit field below the row (as we
know it from userforms)

- to most clients, it is rather confusing how the CTF/DOM saves.
they are used to pressing the save button, and then it is saved.
pressing the publish button, then it is published.
but then there comes the CTF managing a has_many ...
would it be to much to store the created entry's temporary until the
page gets really saved?
(yes, I know that this is a hard one, and I don't see a solution to
this at the moment, I just wanted to throw this thought in)

one final note, please don't mind any mistakes in the text, its quiet
late here in Europe and it has been a hard day ;)
cheers and good night

[John Milmine]

Just a quick note which is also in discussion over here:
http://groups.google.com/group/silverstripe-dev/browse_thread/thread/7aeef3e67c8d8772/8f5c793f27509b9c?lnk=gst&q=ajax+upload#8f5c793f27509b9c

I would love a ajax file uploader to come standard as part of the
datagrid.

Would also love it if it didn't use flash (uploadify). The js script
mentioned in the link above seems a good bet.

[Ingo Schommer]

Forwarding this for Zauberfisch (mistakenly only sent to my email address instead of the group):

another thing that just poped in my head.
There should be an easy to access JS API on the DataGrid providing
things like "reload the datagrid", "sort it by column 2", "only
display entries with has one CategoryID = 42" and so on
Also, it should be possible to send some info to the form that is used
to create a new Entry, so far I had to subclass DataObjectManager and
overwrite the addLink() function to add some params to the link which
I then accessed in the getCMSFields of the new Entry
use cases:
Page to manage Things and Categories
1 DataGrid manages Categories
In another tab there is another DataGrid to manage Things, above that
DataGrid is a Dropdown to select a Category.
JS onChange of that Dropdown, I want to tell the DataGrid to filter
now.
When I click add on that DataGrid, I want that the Category ID is
passed to the CreateForm so I can automaticly put the new Thing in the
correct group.

[swaiba]

"in-line edit, should be in it, and more then a basic text field
(drop-down, date-field, check box, ... shouldn't be to hard)"

+1

it would be great to expand this to allow inline editting of all
fields on a "page", not just a single row
also I override the "page size" to allow more data to be seen, but
this would be very useful to have in the "search" fields

this would then mean it was close to... spreadsheet data editting!
it may not sound very exciting but I also use the ModelAdmin as a
conerstone and I have 80% of Zauberfisch points coverd but the area of
having a large amount of updates to perform across relating rows is
terrible.
simple spreadsheet (http://www.simple-groupware.de/demo/
simple_spreadsheet/spreadsheet.php?lang=en) has been added into a
leftandmain with things like show dataobjectset and then save the
results - is still is far from ideal and very hacky.

Excel, like it or not, is the most common database format out there
and everyone is used to creating something in excel so as close to
this as possible would be ideal, especially the import that takes a
delimted file, allows you to map the fields to columns (now I am
switching to access data import) would be amazing. This would provide
a more secure replacement for the csv import that either works or
doesn't and is hard to provide feedback about multiple impost errors.

lastly a "context menu" might work well for providing the individual
record operations (instead of using up space with more and more
operations) a single item that popups up a menu of indiviual
operations, for eaxmple this would be a great default option - print
http://www.silverstripe.org/customising-the-cms/show/18565