Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single item apart from list in models #1522

Closed
ivancevich opened this issue Jul 13, 2015 · 25 comments

Comments

Projects
None yet
@ivancevich
Copy link

commented Jul 13, 2015

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:
image

Instead of the list with just one item:
image

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

@jeffreypriebe

This comment has been minimized.

Copy link
Contributor

commented Jul 14, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 17, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

@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

This comment has been minimized.

Copy link
Author

commented Jul 20, 2015

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

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

@ivancevich

This comment has been minimized.

Copy link
Author

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2015

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

@ivancevich

This comment has been minimized.

Copy link
Author

commented Jul 20, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 21, 2015

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

This comment has been minimized.

Copy link
Member

commented Jul 21, 2015

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

This comment has been minimized.

Copy link
Author

commented Jul 21, 2015

Cool. I think it's a good approach.

@JedWatson

This comment has been minimized.

Copy link
Member

commented Jul 21, 2015

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

This comment has been minimized.

Copy link
Author

commented Jul 21, 2015

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

This comment has been minimized.

Copy link

commented Sep 11, 2015

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

@jeffreypriebe

This comment has been minimized.

Copy link
Contributor

commented Nov 20, 2015

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 lib\core\routes.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

This comment has been minimized.

Copy link

commented Apr 10, 2016

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

@mxstbr

This comment has been minimized.

Copy link
Member

commented Apr 10, 2016

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 mxstbr removed the new feature label Apr 29, 2016

@mxstbr

This comment has been minimized.

Copy link
Member

commented Apr 29, 2016

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!

@mxstbr mxstbr closed this Apr 29, 2016

@jjhesk

This comment has been minimized.

Copy link

commented Jun 21, 2016

I hope this feature can be released sooon!

stern-shawn added a commit to stern-shawn/keystone-react-boilerplate that referenced this issue Mar 17, 2017

Enabling About Page in Keystone, updating other schemas 🚧
-Creating a hacky singleton for a client's about page since Keystone doesn't have official support yet, ref: keystonejs/keystone#1522
-Creating update file for AboutPage to initially seed the item in the DB. Needed since users cannot add/delete AboutPage item.
-Requiring aboutpage item in models/index.js so that it's brought into platform schema.
-Updating post schema to make use of cloudinary auto cleanup (deleting image on this end also tells cloudinary to delete from user's account (doesn't seem to be fully working in this beta 4.0 version...)
@benammann

This comment has been minimized.

Copy link

commented May 19, 2017

+1

@s-r-jones

This comment has been minimized.

Copy link

commented Nov 21, 2017

keystone pls

@Twansparant

This comment has been minimized.

Copy link

commented Feb 9, 2018

Yes please! +1

@mitul69

This comment has been minimized.

Copy link

commented Apr 30, 2018

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

@erikvdplas

This comment has been minimized.

Copy link
Contributor

commented Jul 15, 2018

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

@regmeg

This comment has been minimized.

Copy link

commented Jun 1, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.