Keystone-classic: Single item apart from list in models

[ivancevich]

May be this was asked before, but I couldn't find any issue related to this.
What I'm trying to do is to have only one item instead of having a list of items for a certain model.
I've found a workaround (see below) but it doesn't look nice having a table with only one item on it.
What I mean is having something like this:

var Home = new keystone.Item('Home');

Instead of this workaround:

var Home = new keystone.List('Home', {
  nocreate: true,
  nodelete: true
});

Also, in the Admin UI it would be nice to show directly this:

Instead of the list with just one item:

If you agree on having such feature, let me know and I'll be happy to submit a PR.
Thanks :)

[jeffreypriebe]

Seems like that fits with the way that search behaves: single result, don't show the list, redirect straight to the editing the item.

[stfnsr]

Mhm, the item view doesn't have a Download Button, also the Button for creating new entries is different from the list view. I could imagine a lot of confusion when a user deletes one of two items, and suddenly can't reach the list view anymore.

But it could be great to be able to set this behaviour in the model - for situations where a model isn't supposed to have more than one item anyway :)

[jeffreypriebe]

@stosorio Very good point about "deleted a single item" and you end up with just one. That would be confusing and likely annoying.
If a particular model should be a class of one, it makes sense.

[ivancevich]

Ok, if everyone agree I'll implementing something like the following, and then sending a PR.

var Home = new keystone.Item('Home');

[jeffreypriebe]

@ivancevich Is that completely separate from the list APIs? (keystone.list)

[ivancevich]

I'm not sure how the implementation will look like, but I think it has to be a new type of model Item since the name List doesn't apply with what we want to achieve. What do you think?

[stfnsr]

The advantage over an option that simply let's you skip the listview would be the more semantic name?

[ivancevich]

I think we can add an option to List and also create a shortcut called Item which behind the scenes is creating a List with the pre-configured options. What do you guys think?

[JedWatson]

I don't think we should create a separate class to List, there would be too much in common. This is really just a simplification wrapper over it (we could also fairly easily abstract the queries necessary for dealing with it) + an alternative top-level view in the Admin UI.

Unless we go a completely different route and store all single-item lists in a common collection (there are pros and cons to this) List fundamentally maps to a Collection in the database, having two objects that map to collections and contain Fields is probably not a good idea.

I like @ivancevich's idea about creating a wrapper for setting the appropriate options (I think). Would be good to see how much of the code is branched if we implement single-item editing mode using the List class.

[JedWatson]

To clarify;

var Settings = Keystone.Item('Settings');
// Settings is a List with several options preset, you add fields to it as usual
Settings.add({ option: String });
Settings.register();

[ivancevich]

Cool. I think it's a good approach.

[JedWatson]

I've had an idea for a while now, that we would alternatively create an entirely new Class in Keystone for dealing with single items.

Will have to go back through my notes to remember exactly what I had in mind, but basically you'd create something _like_ a List, it would implement its own Schema though (rather than using a Mongoose Model + Schema) and _all_ of these items would be stored in a single Collection.

That neatens up the database a little: there's no harm in storing these in a single collection because you don't need to index any of the custom paths, and then you're not creating a new collection per single item type.

It would also expose a much simpler API for loading and updating the single items, because you really don't need 98% of what Mongoose provides to achieve this. Having filtering / sorting / pagination etc. available on a single item List is an artefact of using a square hole to store a round peg :)

If you want to start working on this (using either approach) I'd be happy with that, work should be done for 0.4 though as we're getting close to merging that back into master from the elemental-integration branch.

[ivancevich]

Yes, I agree on having only 1 collection to store this kind of items. In that case I think Item shouldn't be a pre-configured List since the code behind it will be much different from the List one. We can certainly use the regular MongoDB driver to manage that collection.

[nateschilling]

Was this ever settled and/or implemented? I find myself wanting a similar "Item" declaration as well.

[jeffreypriebe]

Until there is a better option, here is a hack that works.

1. Route for the list (Settings), look up desired single item and set it as the current one.
2. Route for :item, redirect to route for list.

For a settings page where I wanted this behavior of a single item not a list of items, I cobbled in some lines to the keystone at libcoreroutes.js as seen in a gist here.

This is in addition to the no create & no delete on the model. (And using an updates file to create the first item of the model.)

[gorillatron]

Yes I am also looking to set a singelton like structure in the database. Is this comming in 0.4?

[mxstbr]

Highly likely not in 0.4, but it's definitely one of the main features we have to have before a 1.0 release!

[mxstbr]

We're closing all feature requests to keep the issue tracker unpolluted. I've moved this to ProductPains, upvote it there if this is important to you: https://productpains.com/post/keystonejs/content-management-ie-singletons-like-pages!

[jjhesk]

I hope this feature can be released sooon!

[benammann]

+1

[s-r-jones]

keystone pls

[Twansparant]

Yes please! +1

[mitul69]

@ivancevich Can you please help me to create Item instead of list ?

[erikvdplas]

Any updates? The nocreate nodelete hack is kinda ugly (both implementation-wise as well as for CMS users).

[regmeg]

any progress guys? I want people who manage the content to be able to edit single page content too, having to explain to them that it's a list, but effectively just only with one item is kind of ugly.