krstffr/matryoshka

A GUI for nesting and linking objects inside other objects.

matryoshka's Issues

Rewrite documentation

!!!

Handling for setting <title> when in matryoshka.

Combine fields-loop for both kinds of fields?

Test this. Should work?

Rename package

Nesting-something

Security: Add login-requirement

Don't depend on Accounts package though, should be optional.

Add both on server (methods) and on client (routes mainly).

Protect CSS classes better.

How to do this in a good way? Just add style: none to styles which might "bleed" in to this app from other styles as I detect them? Or is there a better way?

Some kind of global inherit-thing or something?

User handling

How to handle users? Who can do stuff in Matryoshka?

Add som kind of "matyoskhaAdminRole": "editor"/"admin"/"none" property to users?

Who can add users and set previleges? Only "admin" or something?

Security: Make sure it's secure!

Try to break the security, find insecure parts etc.

DB docs: Clean up how much junk gets saved to the DB!

There's a lot of stuff being saved! Stop it!

Depend on msgs instead of it's own messaging methods.

https://github.com/krstffr/meteor-msgs

Remove keyboard shortcuts

Stupid

Nestables: Get the list of available nestables from code, not mongodb doc.

Weird click event bug for .matryoshka__nestable__container__col--left

When clicking on .matryoshka__nestable__container__col--left for triggering the visibility of it's "children", if you've went from:

1. a nestable with nestedNestables to
2. a nestable without nestedNestables and back to a
3. a nestable with nestedNestables

then the click event will fire multipel times! Now protected by a stupid setTimeout. SUPER ANNOYING.

Probably due to Meteor/Blaze itself.

Ability to choose what key from a Collection should be selectable in <select>

Now defaults to the name of the nestable part.

Maybe the best of all would be if you could chose both a value and a name like this: (NAME). That would be pretty fantastic.

Focusing on nestable part from URL: wait for DOM

Now it's stupid setTimeout() which fires in onAfterAction() for the route. This needs to actually wait for the DOM to load and then fire it ASAP.

Not all nestables in a type should be creatable

Maybe set a notCreatable bool?

Keydown/up event is NOT very nice

Maybe: start a time out for maybe 2 seconds on each keydown (and disable currently running ones of course). THEN save the stuff to the session after the two second pause. 2 seconds should be enough for anyone using this package.

Ability to make fields unique

For exampel: I'm building a CMS for a website. I want the pages' "slug" field to be unique, as I don't want multiple live pages with the same slug.

Drag and drop for repositioning

Filter ability

If you've got a lot of nestables and you want to find a specific, scrolling is not always the fastest method. We need a filter/search function!

Documentation on Session vars as data source for select boxes

WRONG NAME OF EVERYTHING: Matryoshka!

DAMN.

Rename all of it.

Integrate pen to be optional for textareas

http://sofish.github.io/pen/

Duplicate part: add part next to this one instead of at the end.

Multiple nesteable types in object: how to handle ordering?

So let's say I can nest two different types of nestables: gridParts and subpageParts. If I want to be able to put:

1. gridPart
2. pagePart
3. gridPart
   then this is right now impossible.
   The solution could be: Should nestables be put in a general nestables container!?

Every "part" field is now assigned to every part.

Like: a pagePart will get a gridPart (with just an empty [] Array as value) even if that's not one of it's nestables. I don't even want to think about how much bigger the DB would get if this was allowed any longer.

Some kind of "main settings" page?

Where user can define global settings for the user to set.

Move array.move() method from Array.

Should not pollute apps using this package.

Numbers: Should they be floats instead of integers?

Probably right? Why have two different? Most ppl would prefer floats?

GUI: "Smaller parts" compared to the ones of today

For example: if we have a tags-nestable with only a tagname field, then maybe those should not fill an entire row etc.

Add a start page for matryoshka

Right now it's not looking very cool.

How to handle deleted fields.

For example:

I create a nestable with a foo-field. I later remove the foo field. The user can now no longer change (or see!) the value of foo, but it will still be saved to the DB for ever.

Maybe show all keys (which are not currently set by the user) in some way?

Maybe like "there are 4 extra field" and a "show" toggle. But how to handle arrays/object?

Ability to hide contents of a nestable part.

Like an eye-icon by the other icons which toggles visibility

Visible/Hidden nestables on remove/move/go-to-new-doc

Example: If the first nestable is visible and then remove, then the next nestable (which is now first) will be visible also.

A bit annoying.

Duplicate nested parts

Let's say I create a nested thing and I want three more which are basically the same. Shouldn't there be a duplicate button for this? Or is it feature overkill?

Login: Create a nicer login view.

"Preview" logic.

For previewing nestables.

Documentation on hideChildren

BUG: Creating new nestable parts sometimes are added to the wrong place

This happened since changing the way the add-part-sub-menu works. Something with matryoshkaId?

Clicking the home button when already "home" shows right menu

:(

Create tests.

Yes, this needs to happen soon.

Extra field describing the selectable collection field.

If you for example select among stored image URLs, then maybe you also want some name field which better describes the image (compared to only the URL).

Both assign type as the name of the object as well as a field?

Can this be removed?

Cleaner way of adding nestables to the Matroyshka object

Right now it's very bare bones. Create a method for adding stuff so we actually can do stuff to the pushes etc.

Create nestablePart from a nested part inside nestable

That sounds complicated, but it shouldn't be. What could be complicated is figuring out the flow. Something like:

1. Create a new nestable from the current part (What should the name be?)
2. Get the ID from the newly created nestable
3. Switch the previously saved nestable for the new linked (the ID mainly)
4. Maybe go to the newly created nestable so the use can give it a proper name?

Ability to limit nestable parts to specific nestables, not just types.

For example, a main menu should only be able to nest menu parts, not all "page" type parts.

Support for custom collections?

Use whatever collection you want, not restricted to MatryoskaNestables?

Ability to choose field for linked nestables (instead of name). Also images!

For example, let's say we have an "image" nestables. Here it would probably make a lot more sense if you could use an <img> instead of the nestable name for the preview.

Look over nestables part design

Kind of a lot to take in/messy right now.

Get nestables from code instead of object

in the actualNestablesInArray helper for examle.