How to customize views HTML within solidus

[acrolink]

I have noticed that the app/views & app/controllers folders are empty. My question, how to customize HTML of the rendered pages? Which files I need to target? Thanks.

[jasonfb]

this information from the old Spree guides applies to your questions: http://guides.spreecommerce.org/developer/view.html#template-replacements

You might want to seek help on the #support channel of the Solidus Slack room.

[acrolink]

Thanks @jasonfb .. I read the documentation you pointed to .. I think this task should be easier to do than the way it is now, nothing compares to directly editing views and controllers .. What I understood is that modifying the views/controllers files is possible but that would mean editing the global ones. Maybe I can avoid this by installing solidus/spree locally within my app.

[jasonfb]

Actually for views you copy the file from the gem views into your app (thus creating work for yourself when you upgrade and the original file changes --- this is why some people use deface, but deface has its own problems)

For controllers you use class eval and overload methods.

Having said that, for a lot of backend plumbing, many parts of Solidus now have plug-in class components (slightly newer & cleaner approach the community is moving towards. An example is here: https://github.com/solidusio/solidus/blob/master/core/app/models/spree/reimbursement/reimbursement_type_engine.rb#L9 notice that the class attributes that point to other models themselves, and this is designed this way to allow you to swap out certain components with your own objects. More appropriate for, for example, a back-end process that is complex and you want to write your object to represent your business's business logic)

The fundamental problem is that smaller and new stores want the ease of using existing controllers & views but larger Spree/Solidus operations typically outgrow this and write their own frontends and keep Spree/Solidus primarily as back end.

Your mileage may vary.

[acrolink]

@jasonfb Thanks, that made things clearer for me.

[jasonfb]

@acrolink Cool you are welcome. I'd suggest you close this GH issue since it isn't actually an issue, nor is the community going to take on the project of "make a better way to customize" in a Github Issue.

Trust me, lots of people also want "a better way to customize" for Solidus but it it not something that is easily solved or trivial. The pluggable-classes thing described above is one example of the community recognizing a need for a better way and then taking a few baby steps in that direction.

If you want to do some work to think about how you'd approach the problem, a GH issue might be appropriate for a specific proposal to fix or augment in a specific way.

Like, here's what I think we should do and here's what I propose, etc.

But in the absence of that I'm fairly certain there is nothing actionable here as at this point it sounds like you are basically taking Solidus out for a test drive.