0

I'm writing a web application which allows users to create (and then later, edit) blog-like text posts. Because the page for creating it will be identical to the page for editing it, I'm tempted to use the same page for both.

It seems to me like this would be a good example of DRY(Don't Repeat Yourself). However, using that same page and with some modifications and auto-populations seems a bit dirty and difficult to maintain (e.g. I add a control or feature to the editing page and now I have to make sure that it doesn't show on the creation page or get broken by any javascript I may have written.

This Question asked something similar but all the answers spoke more about HOW to implement it, not whether it was good, maintainable practice

Community
  • 1
  • 1
Austin Philp
  • 94
  • 1
  • 10
  • Partials are your friend. You can keep your code relatively DRY while maintaining enough flexibility to readily address future changes. – MarsAtomic Jul 31 '15 at 23:36

2 Answers2

0

I don't think you can say whether it is a best practice or not as it depends on the factors of your specific application. Specific factors would include:

Is there any difference between the views at all beside maybe a create/update button How many events does your view generate How complex is your page going to grow to be in the future How many users do you expect and is it public facing How long will your app live

In theory your view should be as light as possible and contain no business logic. It will simply report events up to your controller. With this in mind, you are not violating any best practice reusing it (except maybe separation of concerns) but I'd more go with not duplicating the wheel. I have done it both ways in the past, usually depending on how big the end app is going to be and how long I expect it to live.

Just my two cents.

darmbre
  • 116
  • 1
  • 6
0

Depends on whether or not you are using javascript or not. But even if you used the same view, you'd might as well use object oriented methods in your controller for different stages of the process. After all, they're callable just like any normal method, not just for serving a particular view.

boulder_ruby
  • 38,457
  • 9
  • 79
  • 100