Data Lists

126 views
Skip to first unread message

Uncle Cheese

unread,
Mar 3, 2011, 11:51:00 AM3/3/11
to SilverStripe Core Development
We've heard a lot about how SilverStripe 3.0 will use a new way of
handling result sets as stored queries that only execute when needed.
I get the general idea, but it's still pretty enigmatic and abstract
to me, and I'm probably not alone.

Sam, I understand you're the primary architect of the new "DataList"
class. Would you be willing to talk about the specifics of how this
new pattern will be different, both in terms of syntax (if known) and
also performance? Maybe an example of the "old" way versus the "new"
way, and what that means. Thanks!

Ingo Schommer

unread,
Mar 8, 2011, 1:11:48 AM3/8/11
to silverst...@googlegroups.com
Hey Aaron,

sorry for the lack of replies, its easy to lose the overview on the mailinglist these days! :)
The new ORM approach was specced out a while ago at http://open.silverstripe.org/wiki/development/NewDataMapper
Have a look at the Django implementation to see some real world examples: http://docs.djangoproject.com/en/dev/topics/db/queries/

In terms of how this affects the DataGrid API (the main UI for editing a DataList), we'll most likely start this from scratch,
as it'll be too hard to refactor the existing APIs in a backwards compatible fashion.
Obviously you're a big stakeholder in this with the DataObjectManager extension,
so we're hoping to involve you early in this process. To date, we've *just today*
started doing some designs around the data list UI, but haven't even written
up requirements of what this new field should do.

In broad terms, the new field won't have methods like setSourceItems() or setLimit()
any longer, as all of these data/collection related bits of information are encapsulated
in the DataList definition.

Uncle Cheese

unread,
Mar 8, 2011, 10:43:34 AM3/8/11
to SilverStripe Core Development
Hey, Ingo,

Thanks for the reply! I'm starting to get it now.

In terms of how this affects my stuff, just based on the new designs
alone, I've conceded that DOM will be rendered obsolete, and I'm OK
with that. It's getting to be a tired old beast. The funny thing is,
for about a year I've been talking about redoing DOM to decouple it
from TableListField et. al., and clean it up to make it more efficient
and more feature complete. The UI that I'm seeing in SS 3.0 is almost
exactly how I pictured doing it.

I know you're looking for contributors for SS 3.0, and as author of
DOM, I would absolutely love the opportunity to be involved in the
DataGrid part of the CMS and work with you guys to peer review my code
along the way. I would definitely make time for something like that,
and I have a lot of ideas based on all of my work with
DataObjectManager. So, please do keep me in mind. I would love that!!




On Mar 8, 1:11 am, Ingo Schommer <i...@silverstripe.com> wrote:
> Hey Aaron,
>
> sorry for the lack of replies, its easy to lose the overview on the
> mailinglist these days! :)
> The new ORM approach was specced out a while ago
> athttp://open.silverstripe.org/wiki/development/NewDataMapper

Dan Rye

unread,
Mar 14, 2011, 10:58:43 PM3/14/11
to silverst...@googlegroups.com, Uncle Cheese
I think having Aaron's experience helping with the new DataGrid would be ideal.  This will also be a nice feather in the community contributions cap!  Has any of the DataGrid work begun?

--
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.


Ingo Schommer

unread,
Mar 28, 2011, 4:58:02 PM3/28/11
to silverst...@googlegroups.com, Uncle Cheese, Dan Rye
Hey Aaron, Dan,

Sam is about to merge back his first draft of the new ORM back to master (see https://github.com/silverstripe/sapphire/tree/new-orm for a preview).
This will enable us to start the data grid UI component.

The first step will be documenting requirements on the field, similiar to http://open.silverstripe.org/wiki/development/validation-new
and http://open.silverstripe.org/wiki/development/NewDataMapper. Do you guys want to start a wiki page for this?
Once we have a list of requirements (e.g. "pagination", "export into multiple formats", "column sorting"),
we can try to define the API.

Here's a list of pending issues (probably too low level):

Thanks
Ingo
Reply all
Reply to author
Forward
0 new messages