Development model

[Torsten]

Hi,

I am trying out ror (again) and would like to contribute, but would like to raise that this is technically much harder than needs to be. Dave has always been very open to contribution, i am really just talking about the machinery.

So when I clone ror (as per docs) I am very very quickly (5-15 minutes) in a situation where I have changes for my app (config, ui, later code) in the repository. Before I check anything in, i can still easily make changes to ror and push them (possibly with pull request). But as soon as I work on "my" site/project, this is not really possible anymore. (or would take more git fiddling than me/joe is willing to do)

The solution is off course simple, I would need to create a blank rails app, add ror as a gem and make changes only to my repo. Then if I want to contribute I can clone ror, point bundler to the copy and the changes would be isolated. 

This approach would also simplify working with "versions" of ror (in the future), which off course helps with stability and issue tracking later.

The only place where i am fuzzy is what this actually entails for ror. If it were an engine, I seem to remember some standard rake task to move migrations. Code and templates should be picked up quite easily, but what about routes, and what is the thing that actually makes it an engine?

Apart from Dave's feedback on this I would also be interested to hear how others are actually solving this .

Thanks

Torsten

 

[Torsten Ruger]

Ok, not too opinions on the matter :-)

Having thought about it more I came to the conclusion that the matter is
different for front and backend. What I wrote is true for the backend.

The frontend (I mean mostly the templates /styles /javascript, not even
controllers) is different in that it is invariably and usually heavily
altered.

When trying to keep such a changing frontend in sync with development it
usually is a mess. There is only one way I know how to do this, and that
is with proper version control.
So then we're back to the forking model. So the frontend should be
forked. Then one can try to bring in changes via branches and pulls.

So this would mean a split into (at least) 2 reps. Frontend (templates +
shop related asstes) and backend (models,controllers, everything else).

The frontend should be forked and depend on a specific version (gem/tag)
of the backend.

Thoughts?

Torsten

> --
> You received this message because you are subscribed to the Google
> Groups "ror_ecommerce" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ror_ecommerc...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[David]

I have thought about a 2 repo approach but that means harder setup which also means less adoption. Also when someone will definitely fork their own store they will have custom changes on the frontend and backend.

The controller tests actually render the front end to make sure nothing blows up. If these are two repo how do we ensure the controller tests work?

Sent from my iPhone

[Torsten Ruger]

Hi David,

If people fork the frontend, and then bundle etc, the way to start with it is actually the same as now.

And with ruby being patchable, it is very easy to "configure" the backend by just adding classes to ones own repo that change the behaviour of the backend.

The tests (and controllers) should be in the backend. Just the templates and config is the frontend. It may be that the tests don't work on a persons system that has changes the templates too much, but that may well be considered his problem.
The tests should work on the delivered system off course.

I don't think it is a very difficult thing to do, i just don't know how. But then i haven't even read the engine guide yet.

Torsten

David

3 Dec 2013 16:50

I have thought about a 2 repo approach but that means harder setup which also means less adoption. Also when someone will definitely fork their own store they will have custom changes on the frontend and backend.

The controller tests actually render the front end to make sure nothing blows up. If these are two repo how do we ensure the controller tests work?

Sent from my iPhone

Torsten Ruger

3 Dec 2013 12:52

Ok, not too opinions on the matter :-)

Having thought about it more I came to the conclusion that the matter is different for front and backend. What I wrote is true for the backend.

The frontend (I mean mostly the templates /styles /javascript, not even controllers) is different in that it is invariably and usually heavily altered.

When trying to keep such a changing frontend in sync with development it usually is a mess. There is only one way I know how to do this, and that is with proper version control.
So then we're back to the forking model. So the frontend should be forked. Then one can try to bring in changes via branches and pulls.

So this would mean a split into (at least) 2 reps. Frontend (templates + shop related asstes) and backend (models,controllers, everything else).

The frontend should be forked and depend on a specific version (gem/tag) of the backend.

Thoughts?

Torsten

Torsten

27 Nov 2013 14:11