Scorpiusjs Planning and Community Discussion

[rwatts3]

Open Discussion regarding Features and Planning for Scorpius

[ogermann]

Important for us would be the following:

• ssr
• customization (to get an admin panel that has a great usability in every usecase)
• template support (like pages in orion)
• relationships

For sure this list can be longer, but these are the most important points to us.

[Ajaxsoap]

Hi @rwatts3 ,

Thanks for this initiative!

I know that a lot of work to be done here.

I would like to ask, how would you attack the front-end side of things? I guess scorpius is gearing toward apollo on the backend side?

I agree about the points @ogermann pointed out. I have a lot of pain in orion relationship that I ended up dropping it and doing it manually.

It's nice to have this kind of discussion on the early days to decide which stack or approach should be taken.

Thanks

[rwatts3]

Thank you for sharing your thoughts.

Certainly SSR is a critical part of the vision. Frankly SSR is a needed in a great deal of apps I've seen from the meteor community as a whole. So that will certainly be top priority.

As for template support I'm thinking more along the lines of a centralized config. Where you can define the schema or several collections and tie them together with relational joins. Maybe it would be better to use Apollo for this type of thing. Ideally. That type of decision wouldn't get into the way of the developer.

In the config their may be a key for modules or collections where the user could define those . so building a page module would be simple and if provide an example.

The high level idea is that the config file drives everything. A user could clone or copy a module as a boilerplate and drop it in their directory. That module would then be defined within the config and used later in the application. This is simply an early thought if how to go about it. Ideally i would like for scorpius to be very un-opinionated to the developer. If you want to use it to control your mobile app go for it. If you want it as an api where you'll be writing your front end in some php that's fine as well.

This has also given the thought if defining collections within the admin area on the fly. Or having them dynamically defined based on the config or module approach.

[rwatts3]

As for the front end. It may come as a module or plugin addition where there would be a set of tools and up tools to build a website. Maybe scorpius ui or scoroius front end tools

[ogermann]

This has also given the thought if defining collections within the admin area on the fly. Or having them dynamically defined based on the config or module approach.

Thats a thing that we tried to simulate in orionjs (well its not working that auotmated but it looks like that for the user). I think it's important, that scorpius will have the ability to be customized for a great usability and fast working steps.

What i'm also a bit anxious about is that i cannot imagine that such a piece of work can be done in a short time. I just hope that orionjs wont get too outdated to use it with meteor until scorpious will come out.

[rwatts3]

Another thought also is to completely rent and orion to scorpius as a fork and provide support as the discussed features are rolled out and built overtime. The main problem I'm having with orion is the fact that I cannot publish package releases and make updates to orion. Tried reaching out to Nick but haven't heard from him since the day the announcement was made. So essentially my hands are tied to making any updates the project.

[rwatts3]

Ideally. If I am to make the desired improvements and take scorpius to the place we've discussed here it would probably be best to fork. And incrementally roll or convert orion / scorpius to the new concept.

[rwatts3]

After much thought, in regards to what would work best for the community, I've decided to go with a fork, and make improvements. This means Blaze will remain at the core of Scorpius.

Before Scorpius will be production ready. I will be updating the packages to be 1.4.0.1 compliant, and upgrading all packages to ecmascript and modules. An official announcement will be made when you are able to begin transforming existing Orion projects to Scorpius. Also all packages will be published to atmosphere under Scorpius.

Scorpius will start at version 0.1.0 and follow the semantic versioning pattern going forward.

[JeremyIglehart]

What are your thoughts on Simple-Schema? I'm concerned this project is falling behind maintenance as Orion did.

I've found a possible good replacement for validation purposes, but it seams to me that simple-schema was used in Orion for more than just validation.

Here is another one, recommended by aldeed himself.

Any thoughts?

[rwatts3]

@JeremyIglehart

For currently SimpleSchema and Autoform combined suit the needs for Scorpius at least from an initial migration standpoint. However I do believe in the future, it may definitely be necessary to explore other options as Scorpius evolves.

I'm definitely not opposed to testing and researching the latter. But first things first let's get some of the bugs squashed from the Orion repo, and that could be a feature in a later release.

[JeremyIglehart]

@rwatts3 That all sounds good.

One last comment about this and I'll move on. I've done some more research on this topic and ended up posting a question about it on the meteor forums. I'm not so sure I like any of these options. Actually, the one I like the most would be a solution that uses the mongodb validation somehow if possible.

[rwatts3]

Have you looked into mongoose ?

On Thu, Aug 11, 2016, 10:00 AM Jeremy Iglehart notifications@github.com wrote:

@rwatts3 https://github.com/rwatts3 That all sounds good.

One last comment about this and I'll move on. I've done some more research on this topic and ended up posting a question about it on the meteor forums https://forums.meteor.com/t/the-best-way-to-react-to-validation/27892. I'm not so sure I like any of these options. Actually, the one I like the most would be a solution that uses the mongodb validation somehow if possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scorpiusjs/scorpius/issues/5#issuecomment-239223602, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFsSS4F-iY5LYKBLARgTBG9SgMT-GnYks5qe1VCgaJpZM4JUuRX .

[rwatts3]

Not sure if it has validation

On Thu, Aug 11, 2016, 10:03 AM Ryan Watts ryandwatts@gmail.com wrote:

Have you looked into mongoose ?

On Thu, Aug 11, 2016, 10:00 AM Jeremy Iglehart notifications@github.com wrote:

@rwatts3 https://github.com/rwatts3 That all sounds good.

One last comment about this and I'll move on. I've done some more research on this topic and ended up posting a question about it on the meteor forums https://forums.meteor.com/t/the-best-way-to-react-to-validation/27892. I'm not so sure I like any of these options. Actually, the one I like the most would be a solution that uses the mongodb validation somehow if possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scorpiusjs/scorpius/issues/5#issuecomment-239223602, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFsSS4F-iY5LYKBLARgTBG9SgMT-GnYks5qe1VCgaJpZM4JUuRX .

[rwatts3]

Also out of curiosity what issues are you running into with simple schema

On Thu, Aug 11, 2016, 10:04 AM Ryan Watts ryandwatts@gmail.com wrote:

Not sure if it has validation

On Thu, Aug 11, 2016, 10:03 AM Ryan Watts ryandwatts@gmail.com wrote:

Have you looked into mongoose ?

On Thu, Aug 11, 2016, 10:00 AM Jeremy Iglehart notifications@github.com wrote:

@rwatts3 https://github.com/rwatts3 That all sounds good.

One last comment about this and I'll move on. I've done some more research on this topic and ended up posting a question about it on the meteor forums https://forums.meteor.com/t/the-best-way-to-react-to-validation/27892. I'm not so sure I like any of these options. Actually, the one I like the most would be a solution that uses the mongodb validation somehow if possible.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/scorpiusjs/scorpius/issues/5#issuecomment-239223602, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFsSS4F-iY5LYKBLARgTBG9SgMT-GnYks5qe1VCgaJpZM4JUuRX .

[JeremyIglehart]

It's a combination of worries that schema is unmaintained along with curiosity if it's possible to achieve similar results for validation using more "core" code. Specifically, that is, using mongodb's built in features.

I'm asking the question "why is everyone doing it this way" when there seams to be a possible better way.

So, is it even possible to use the new functionality in mongo as an approach to validation for server/client input?

It would require minimongo to support this feature no?

[rwatts3]

I believe your observation is correct in regards to minimongo. But I believe the reason most people may have used or continue to use Simple Schema, is because of the supported version of mongodb at the time. I'm not sure at which version mongodb implemented validation etc. I could be totally wrong here, haven't done research to support this statement so it is purely biased.

But another reason people may continue to use simple schema at the current time dates to the old "If it's not broke don't fix it" saying. It could just be a case that Simple Schema has everything most people need at the current point in time. Doesn't mean that mongodb validation will be direction in the future

[JeremyIglehart]

Just a friendly FYI: MongoDB Version 3.2 -> https://docs.mongodb.com/manual/release-notes/3.2/#document-validation

[krishaamer]

Fork sounds great and you get the built-in audience of everyone who loved Orion. For me it has almost everything I'd need already so I'm just interested in having a package that does not get stuck in limbo like Orion did and keeps working with all the changes that come to Meteor.

[rwatts3]

Certainly, I explored as many options as I could think. And fork seemed like the most reasonable approach in regards to supporting the community with as little overhaul as possible.

I worked with Orion since pre 0.7 and helped get it to 1.0 +. Orion is amazing, Nicolas did a tremendous job.

My vision for Scorpius is to bring more CMS features into core, and to keep it on a steady path with new releases of Meteor.

Some day in the future Scorpius will definitely be the go to platform for CMS / Admin solutions. Mobile, Web, and ... (Spoiler Alert, Desktop) :)

[bogdanrn]

I'd also want to help. For me some useful features would be user roles and translation support.

[krishaamer]

Hey everyone, just wanted to let you know we successfully used Scorpius on a 48h hackhaton with next to no problems. We built a Q&A platform for the Snapchat generation and you can check it out here: http://yah.haam.co

The one question that did arise was if it's possible to use Scorpius together with tap:i18n-db? Both want to initiate collections with their own prefix, for example TAPi18n.Collection and Scorpius.Collection

Is there a way around this in javascript or should one of the packages change for them to work together?

Thanks to everyone for their contributions and hope Scorpius takes off. It's an awesome platform as the past weekend proved!

[rwatts3]

This is awesome I'm great to hear the success. I will look into the i18n question. It may be possible to convert Scorpius.Collection to a class, that way you can extend and create a new class of your own with the same functionality. I'll look further. If you want to open a separate issue, for documentation and discussions.

[krishaamer]

That would be awesome @rwatts3 !

[JulianKingman]

@rwatts3 check out astronomy, I've loved using it in any projects I've had it in. In addition to offering validation, it also creates classes that you can do cool things with. I can't recommend it highly enough. It's also has extensibility built in, if it doesn't do everything needed.

[rwatts3]

Thank you for sharing do you have a link to the repo , or docs ?

[JulianKingman]

docs: http://jagi.github.io/meteor-astronomy/ repo: https://github.com/jagi/meteor-astronomy/

[JulianKingman]

For what it's worth, you'll probably have to swap out simple-schema and collection2, which may be a bigger undertaking than you want. On the other hand, there's this: https://atmospherejs.com/lai/astronomy-simple-schema, which could probably be adapted (it's a bit out-of-date).