PLEASE give Meteor-CORE a build-in ORM-SUPPORT (Object-Relational Mapping)!

core
21

I think this is a great use case for a form package that abstracts away the ORM and generates forms based on the options it’s given. A thin adapter could allow it to work with many ORMs/Schemas :smile:

There are so many packages in Atmosphere that are severely coupled to their dependancies (the router helpers for IR is a good example).

Packages like FlowRouter decouple the UI so that another package can handle the view concern with ease. Reaktor router composes FlowRouter, ReactLayout, and a thin facade to make an awesome router for React.

1 Like
22

Yeah the CRUD stuff is where I am seeing the first big wins using autoform.

I tried the BS3 package with autoform and it works really well.

Speed is king and it is really important to have a meteor-framework rendering the validation options per field for you - depending on the framwork you use. Doing the manual stuff like is really counter-productive. And it gets much more complex when it comes to selects, multi-selects, date-pickers and more… the way autoform handles this is really well

So having to do something like this is not a productive workflow:

  <div>
    <label for="firstName">First name</label>
    <input id="firstName" type="text" value="{{firstName}}" class="{{#if hasValidationError 'firstName'}}error{{/if}}" />
  </div>
  {{#if hasValidationError 'firstName'}}
    <div class="error">{{getValidationError 'firstName'}}</div>
  {{/if}}
23

@thebarty take a look at https://github.com/aldeed/meteor-autoform/issues/1219#issuecomment-143463954 for a solution I just propsed.

24

On the topic of input validation and forms, I’d like to suggest taking a look at Semantic UIs form validation components and modules - http://semantic-ui.com/behaviors/form.html.
So far it has had answer to everything I’ve asked it to, from optional inputs, to custom validation for complex input combinations and it’s all done in, in my opinion, very clean and easily understandable syntax/format.

This is all of course only client-side so you do have to make sure you take care of input validation server-side manually, for that using SimpleSchema has been great.

25

Hi @serkandurusoy, wow thanks a lot for your quick solution. I’ll try it out asap - that looks really promising as I could manage mongo-style “foreign-key-relationships” (update/insert/delete) just with collection2!?

Do you do it that way yourself (only with collections2)? Or is there still need for the CollectionHooks package for certain use-cases? If yes: what for do you use collectionhooks?

Thanks a lot!!! :grinning:

26

To insert/update fields within the current document, I use autovalues of collection2 (and simple schema).

If I need to modify documents from other collections within the same “operation”, then I use collection hooks.

For example, I keep a log of all my db operations, to do that, I use collection hooks to create a log entry after insert/update of a document in general app collections.

It is also very handy to manage “denormalized” data, do cleanups etc.

There are also creative ways you can use before/after find to modify queries or the returned document.

27

@maxhodges: @theparty has a good point. Are there any substantial real-life Meteor Open Source code bases that can be used as an example? Todos and Microscope will only take you that far.

28

@serkandurusoy and I both suggested https://github.com/wekan/wekan
Also there are many open source packages which could be looked at

1 Like
29

I didn’t read all the answers but I believe you’re looking at this the wrong way. Django and Meteor are not supposed to be used in the same way.
The ORM would suggest an object oriented approach when I really believe a more functional approach works better especially in the front-end.
You’re using mongodb, it’s not a relational database, it’s supposed to be used in a different way when thinking about relations.
I actually like the current data layer. Maybe when there is support for other databases it makes sense to have those things, but with mongo I personally don’t think so.

30

I also agree with this. The more I do functional programming in other languages the more it’s trickling back into my JS (for the better). JS is intrinsically poor at doing OO but excels at the functional paradigm.

I’ve been abstracting away things into a separate model module that has validate pure functions (using Match.test is all I really need) which is dumb to the fact that there is even a DB (useful for forms clientside).

Using this paradigm, if there is a lot of logic that needs to get called at the same time as creating a Post document (like creating an audit record) then you could use a PostsController.create to compose the validate, db insert, and create audit together in one call.

To each their own of course. I haven’t used an ORM too much (just a bit in Rails) so I don’t really miss it I guess :smile:

1 Like
31

Hi guys,

well… don’t they say that mongo is perfect for object-oriented programming?

Functional programming feels like a step backwards to me, for example when using meteor methods.

32

Don’t confuse functional programming with procedural programming. They are very different.

2 Likes
33

Part of the appeal of meteor is being able to create packages to better suite your needs.

A lot of people don’t use an ORM so putting it into core seems like overkill, imho. Just make your own ORM package, or use an existing one.

34

It’s not an overkill and ORM in core will be a must as soon as we will have more than one database option.

1 Like
35

I am quite pleased with the community’s solutions to this problem. I am using aldeed:simple-schema and aldeed:autoform. I haven’t experienced the spaghetti code issues. My model definitions can be rather long, but these packages cleanly abstract these responsibilities out of application-level code.

However, you’d be crazy not to use a package like aldeed:simple-schema– if you want to build an unmaintainable app, that’s the way to go. So I can see the argument for why these types of packages should be absorbed into core. I would say it is pretty essential to have one.

Why not a middle ground, where MDG officially endorses something like simple-schema and we call it a day. Regardless, the best packages will rise to the top as developer’s won’t rely on the ones that aren’t well-tested or production ready.

36

@shcherbin: Thanks for your support! :slight_smile:

@peterm: Simple-Schema is just one simple part of an real ORM. It’s missing the whole part of joining collections automatically for you, managing updates/inserts/removes and automated migration support.

IMO it should all be part of core (of course with the option to skip it) in order to unite the community efforts.