Hi @antraxis
I’m working on something similar, so your post title jumped off the page at me. I like your ideas.
I am very new to meteor but the more I learn the more I like it.
I have used Drupal and Wordpress and I don’t like either of them:
In biological evolution, bad ‘code’ dies, in evolving software it lives on and creates monsters.
I think I am coming at the problem from a different angle to you, but maybe there is useful cross-over between our approaches/ideas. I’ll explain my ideas so you know where I’m coming from, and then address your expected features list.
My current project is to create a simple information website with a few pages, a contact form, and maybe a search facility. In my experience this is a typical minimum requirement. Having begun the layout design using meteor (nemo64:bootstrap), I began to wonder if I could continue to use meteor to create the whole thing…
My thoughts began by re-imagining the CMS concept:
At the simplest, administrators create content which is displayed to viewers using pre-defined layout.
Content:
- Text – paragraphs, lists
- Other stuff that fits into rectangular area – images, video.
- Stuff that takes up no visual space but maybe requires control – sound files
- Form input – text boxes, check boxes, radio buttons, …
- Tags, and other meta-data, to categorize content.
- What have I forgotten…?
Much content necessarily belongs together. For example, an article with a title, a few paragraphs and an illustrative image. So we need a way to group content. This could be part of the tag system taxonomy from item 5) above.
The view/layout part of the system then uses pre-defined (by the admins) structures to create units of layout, which in turn are inserted into the overall structure.
Meteor is ideal for the back-end admin interface – just look at this forum system – but it isn’t necessarily the best for delivering what the viewer/user sees, given that most websites consist of mostly static content. My current solution is to use meteor to create static pages which are then served by NGINX.
Your feature list:
- add editable tree view of mongo structure, same as in Firebase,
Could we create a basic structure that covers 99% of use cases, so that this feature is deferred to version 2?
- add visual editor for schemas of data, and code snippets, generator to use them in templates (create/view/edit/remove items),
Not sure I quite understand this.
- add users and roles (with permissions for accessing certain schemas / actions),
Yes, definitely. But not crucial for the very first release – one admin can do a lot.
- add visual route editor - for redirecting url’s to specific templates and yields,
Yes, definitely.
- add panel for managing installed meteor packages,
Maybe in version 2…
- including css/js files only to specific routes (for example admin.css only for /admin/*
Yes, definitely.
- generate ready to copy & paste - user forms, such as register, recover, edit data, view profile
Or just let admins create their own. But nothing wrong with a few pre-defined.
- no themes, no bootstraps - pure management system.
How would the user/admin create the viewer-facing bit?
My fantasy is drag-and-drop theming